必须手动绑定并验证密码校验函数是否生效，查 dba_profiles 确认 password_verify_function 是否为 null，再查 dba_objects 确保函数存在且状态为 valid，并授予 public execute 权限。
oracle 19c 默认启用的 ora12c_verify_function 已比旧版更严格，但直接用它仍可能漏掉业务特需的规则（比如禁止用户名倒序、禁用常见弱口令子串），必须手动绑定并验证是否生效。
怎么确认当前密码校验函数是否已启用
别猜，直接查。很多 DBA 改完 profile 就以为成了，结果新密码还是能设成 oracle123 —— 因为 PASSWORD_VERIFY_FUNCTION 还是 NULL。
- 执行
SELECT limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'PASSWORD_VERIFY_FUNCTION';，返回NULL或空值说明没启用 - 如果返回函数名（如
ORA12C_VERIFY_FUNCTION），再查它是否存在：SELECT owner, object_name, status FROM dba_objects WHERE object_name IN ('ORA12C_VERIFY_FUNCTION', 'ORA_STIG_VERIFY_FUNCTION') AND object_type = 'FUNCTION'; - 注意：函数必须在
SYSschema 下且状态为VALID，否则绑定后改密码会报ORA-28003且不提示具体原因
运行 utlpwdmg.sql 后为什么密码还是能设得很弱
脚本执行成功 ≠ 策略生效。常见断点在 profile 绑定和权限上。
-
@?/rdbms/admin/utlpwdmg.sql只创建函数并修改DEFAULTprofile 的PASSWORD_VERIFY_FUNCTION参数，但不会自动把已有用户从DEFAULT切换过去 —— 检查SELECT username, profile FROM dba_users WHERE username NOT IN ('SYS','SYSTEM'); - 函数创建后必须显式授权：
GRANT EXECUTE ON ORA12C_VERIFY_FUNCTION TO PUBLIC;，否则非 SYS 用户调用时静默失败 - 19c 中
ORA12C_VERIFY_FUNCTION默认要求至少 8 位、含大小写字母+数字+特殊字符，但若数据库字符集是AL32UTF8，某些 Unicode 特殊字符（如中文标点）会被忽略校验，实际只按 ASCII 范围判断
自定义 verify_function 函数最容易踩的三个坑
想加“禁止密码包含用户名拼音”或“禁用近三个月用过的密码哈希”？手写函数时，以下三点错一个，ALTER USER ... IDENTIFIED BY 就直接报 ORA-28003 不给提示。
- 签名必须严格为：
FUNCTION my_verify (username IN VARCHAR2, password IN VARCHAR2, old_password IN VARCHAR2) RETURN BOOLEAN—— 多一个参数、少一个IN、返回NUMBER都会编译通过但运行时失效 - 函数体内不能出现
INSERT/UPDATE/DBMS_OUTPUT.PUT_LINE；调试时可用CREATE OR REPLACE PROCEDURE debug_log(p_msg VARCHAR2) AS BEGIN NULL; END;占位，避免误触副作用 - 长度检查必须放最前：
IF LENGTH(password) ，否则后续 <code>REGEXP_LIKE在空密码或超短密码下可能抛异常中断校验流程
生产环境启用前必须验证的边界场景
别只测 Abc123!@# 这种理想密码。真实用户会输各种奇怪组合，而 Oracle 的校验函数对这些输入的处理很“直男”。
- 密码含前导/尾随空格：
' Abc123!@# '——LENGTH返回 13，但 Oracle 实际存储时会 trim，导致校验通过后真实密码变短 - 用户名全小写但密码用大写开头：
username='scott'，password='SCOTT123'—— 内置函数默认不校验大小写敏感匹配，需在自定义函数里加INSTR(UPPER(username), UPPER(password)) > 0 - 使用
ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_MAX 5后，用户改密码时若旧密码哈希未存够 5 条（如之前没开过该策略），首次修改会绕过重用检查
真正麻烦的不是写函数，而是验证它在所有用户、所有客户端（SQL*Plus、JDBC、OCI）、所有字符集下都稳定触发 —— 建议在测试库用脚本批量跑 100+ 种弱密码样本，比看文档靠谱得多。
