启用Oracle密码复杂度验证需运行utlpwdmg.sql脚本创建验证函数，并显式将其绑定到用户profile的PASSWORD_VERIFY_FUNCTION参数，否则不生效；CREATE USER语句不触发该验证。
Oracle密码复杂度验证怎么启用
直接改用 utlpwdmg.sql 脚本是最稳妥的方式，它不是“配置项”，而是通过创建一个密码验证函数并绑定到 profile 实现的。oracle 自带的这个脚本默认不启用，需要 dba 手动运行一次，且必须在 sys 用户下执行。
常见错误是：把脚本复制粘贴进 SQL*Plus 后没注意当前用户、没连上 SYSDBA 权限，或者运行后忘了把函数挂到具体用户的 profile 上——这时候改密码依然不会校验。
- 确保以
SYS AS SYSDBA连接（不是普通SYS，也不是SYSTEM） - 脚本路径通常在
$ORACLE_HOME/rdbms/admin/utlpwdmg.sql，直接@$ORACLE_HOME/rdbms/admin/utlpwdmg.sql运行 - 运行成功后会创建函数
verify_function（11g）或ora12c_strong_verify_function（12c+），但不会自动生效
怎么让密码规则真正起作用
脚本只建了验证函数，真正控制密码行为的是 profile。Oracle 默认的 DEFAULT profile 不调用任何密码函数，必须显式修改或新建 profile 并指定 PASSWORD_VERIFY_FUNCTION 参数。
容易踩的坑是：给用户改了 profile，但没检查该 profile 是否真被用户使用；或者误以为改了 DEFAULT profile 就全局生效，其实已有用户可能仍绑定旧 profile。
- 查看用户当前 profile：
SELECT username, profile FROM dba_users WHERE username = 'YOUR_USER'; - 修改 DEFAULT profile：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function;（12c+） - 或为特定用户新建 profile：
CREATE PROFILE strong_pwd LIMIT PASSWORD_VERIFY_FUNCTION verify_function;，再ALTER USER scott PROFILE strong_pwd;
不同 Oracle 版本的函数名和行为差异
11g 和 12c+ 的 utlpwdmg.sql 内容不同，生成的函数名、默认规则强度、甚至参数都变了。硬编码函数名或照搬老文档会报 ORA-00904: "VERIFY_FUNCTION": invalid identifier。
12c+ 默认启用了大小写、特殊字符、历史密码检查等，而 11g 的 verify_function 默认不强制特殊字符，也不检查密码历史——这些不是 bug，是脚本本身写的逻辑。
- 11g 脚本创建
verify_function，可接受 1 个参数（用户名） - 12c+ 脚本创建
ora12c_strong_verify_function，接受 3 个参数（用户名、密码、旧密码），且内置更严规则 - 若需自定义（比如放宽长度要求），得基于原函数重写，不能直接 ALTER FUNCTION ——要先
DROP再CREATE OR REPLACE
为什么改了 profile 还能设弱密码
最常被忽略的一点：密码验证函数只在 ALTER USER ... IDENTIFIED BY 或 PASSWORD 命令时触发，**不用于 CREATE USER 语句中的初始密码**。也就是说，用 CREATE USER u IDENTIFIED BY '123' 仍能成功，哪怕 profile 已绑定强校验函数。
这是 Oracle 的设计行为，不是配置遗漏。想堵住这个口子，只能靠流程管控（比如禁止直接 CREATE USER）、或用 DDL 触发器拦截，但后者有性能和维护成本。
- 验证是否生效：用已存在用户执行
ALTER USER scott IDENTIFIED BY 'a';，看是否报ORA-28003: password verification for the specified password failed -
CREATE USER不走验证函数，ALTER USER ... IDENTIFIED EXTERNALLY也不走 - 如果应用用 JDBC 连接串带密码初始化用户，同样绕过验证——得在应用层或部署脚本里加检查
密码验证函数不是开关，是嵌入在 profile 里的钩子；profile 不是全局策略，是按用户绑定的；而 CREATE USER 是唯一明确被 Oracle 排除在校验之外的操作——这三个点串起来，才是生产环境里密码策略“看似生效实则漏风”的真实原因。
