Oracle 19c中如何配置强化的密码校验函数来提高安全性

必须手动绑定并验证密码校验函数是否生效，查 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';
• 注意：函数必须在 SYS schema 下且状态为 VALID，否则绑定后改密码会报 ORA-28003 且不提示具体原因

运行 utlpwdmg.sql 后为什么密码还是能设得很弱

脚本执行成功 ≠ 策略生效。常见断点在 profile 绑定和权限上。

• @?/rdbms/admin/utlpwdmg.sql 只创建函数并修改 DEFAULT profile 的 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+ 种弱密码样本，比看文档靠谱得多。