首页 > 数据库 >Oracle修改密码提示历史密码重复的解决方法

Oracle修改密码提示历史密码重复的解决方法

来源：互联网 2026-07-09 12:26:01

oracle资讯合集

遇到ORA-28007报错时，直接改回原密码会失败，因Oracle校验的是哈希值而非明文。解决方法有：通过IDENTIFIEDBYVALUES直接写入原哈希值；将PASSWORD_REUSE_TIME和PASSWORD_REUSE_MAX同时设为UNLIMITED；DBA可创建临时用户获取哈希后更新目标用户。修改profile后需执行一次ALTERUSER。

遇到ORA-28007报错时，很多人第一反应就是直接改回原来的密码——毕竟密码没变，理论上应该能通过。但现实很残酷：ALTER USER user IDENTIFIED BY "old_password" 会触发校验，即便原封不动地输入原密码，同样会被阻止。Oracle不会比对明文是否一致，而是检查历史哈希记录是否落在 PASSWORD_REUSE_TIME 和 PASSWORD_REUSE_MAX 这两个约束范围内。只要策略开启，这条路就被堵死了。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

ORA-28007报错时直接改回原密码是否可行？

答案很明确——不可行。核心在于Oracle的密码重用校验机制：它不会判断明文是否重复，而是检查新设密码的哈希值是否在历史记录中，并且是否在时间或次数限制内。只要profile配置了重用约束，直接改原密码必然报错。

绕过重用限制的三种实操路径

既然直接改明文走不通，就需要换思路。核心原则是避开明文校验逻辑，根据场景选择对应方法：

知道原密码且只想“重置为相同值”：使用 IDENTIFIED BY VALUES 直接写入哈希值。先查询目标用户的哈希：SELECT spare4 FROM user$ WHERE name = 'USER_NAME'，获取类似 S:ABC... 或 T:DEF... 的字符串，然后执行 ALTER USER user IDENTIFIED BY VALUES 'S:ABC...'。简单来说，就是告诉Oracle：“密码就是这个哈希值对应的密码，无需检查历史记录”。
想彻底禁用重用限制：修改profile，将 PASSWORD_REUSE_TIME 和 PASSWORD_REUSE_MAX 都设置为 UNLIMITED。注意一个经典陷阱：这两个参数必须同时设为 UNLIMITED，只改其中一个反而会导致密码永远无法重置——Oracle会认为“时间无限但次数有限”或“次数无限但时间有限”，结果无论如何都通不过。
临时绕过（仅限DBA操作）：使用 CREATE USER temp_user IDENTIFIED BY "desired_password" 创建一个临时用户，查询其 spare4 哈希，再用这个哈希去更新目标用户。这种方法不依赖profile修改，但需要 SELECT ANY TABLE 权限才能访问 user$ 表。

profile修改后为何仍需执行一次ALTER USER？

不少用户修改profile后以为万事大吉，结果JDBC连接仍然报错。原因在于Oracle对密码有效期和重用策略的生效机制是“惰性”的——只有在真正执行 ALTER USER ... IDENTIFIED BY 时才会刷新内部状态。即便新旧密码完全相同，也必须触发一次显式修改，否则连接层仍按旧策略进行校验。因此修改profile后务必手动执行一遍密码修改，即使密码没有变化。

容易被忽略的兼容性坑

哈希值格式必须匹配客户端版本。12c及以后版本默认使用 T: 开头的新哈希格式，但老应用（如11g客户端）只认 S: 开头的旧格式。如果从 spare4 查询得到的是 T: 哈希，而客户端是11g，那么 IDENTIFIED BY VALUES 可能会静默失败，或登录时报 ORA-01017。此时需要确认 SQLNET.ALLOWED_LOGON_VERSION_SERVER 的设置，必要时考虑降级哈希生成方式——例如使用11g实例导出用户再导入到12c中。

侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述