如何配置Oracle密码复杂度验证_utlpwdmg.sql脚本应用

Oracle密码复杂度验证默认不生效，是因为utlpwdmg.sql仅创建验证函数而未绑定到profile；必须手动执行ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function才能启用。

Oracle密码复杂度验证为什么默认不生效

许多Oracle数据库管理员（DBA）在配置密码策略时都会遇到一个典型问题：已经成功运行了 @?/rdbms/admin/utlpwdmg.sql 脚本，但在创建新用户或修改密码时，系统仍然允许设置如 '123456' 这类简单密码。这背后的核心原因在于，该脚本的主要作用仅仅是创建密码复杂度验证函数（例如 verify_function 或 ora12c_strong_verify_function），而并未自动将其关联到任何用户配置文件（Profile）。Oracle出于安全与灵活性的考虑，不会自动应用此函数，必须由管理员手动执行绑定操作。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

• 最关键的一步是，必须显式地修改目标Profile（通常是 DEFAULT 默认配置文件）的 PASSWORD_VERIFY_FUNCTION 参数。
• 对于Oracle 12c及以上版本，官方推荐使用 ora12c_strong_verify_function。该函数比旧版的 verify_function 提供了更严格的安全检查，强制要求密码包含大小写字母、数字及特殊字符的组合。
• 此外，在Oracle 19c或更高版本中，如果启用了统一审计（Unified Auditing）功能，还需确保执行操作的用户具备 ADMINISTER KEY MANAGEMENT 系统权限，否则在调用验证函数时可能触发 ORA-28031 权限不足错误。

如何正确启用utlpwdmg.sql脚本的密码验证功能

要使Oracle密码复杂度策略真正生效，主要分为两个步骤：首先确认验证函数已成功安装，其次将其正确关联到指定的Profile。切勿忽略前期检查，许多配置失败都源于函数名错误或Schema不正确。

• 验证函数是否存在：执行SQL查询 SELECT object_name FROM dba_objects WHERE object_type = 'FUNCTION' AND object_name LIKE '%VERIFY%'; 以确认函数已创建。
• 绑定至默认Profile：执行命令 ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function; 完成关联。
• 若计划使用自定义的密码验证函数（例如基于业务需求修改过逻辑），请确保该函数在 SYS 模式下编译无误，且声明方式为 AUTHID DEFINER（定义者权限）。
• 重要提示：对Profile的修改仅对后续的 CREATE USER（创建用户）或 ALTER USER ... IDENTIFIED BY（修改用户密码）操作生效，不会追溯影响现有用户的当前密码。

ORA-28003密码验证失败的常见原因与解决方法

当遇到ORA-28003“密码验证失败”错误时，不应简单归咎于脚本安装问题。更多情况下，这是由于密码策略参数与实际业务需求发生冲突所致。例如，在开发测试环境中临时禁用策略后，生产上线前忘记重新启用，导致应用程序批量创建用户时全部失败。

• 密码内容若包含用户名本身、用户名的倒序排列，或存在连续重复字符（如 aaaaaa），验证函数将直接拒绝。
• Oracle 12c及之后的强验证函数强制要求密码长度至少8位，且必须包含至少1个大写字母、1个小写字母、1个数字和1个特殊字符。许多遗留系统的脚本中硬编码了6位纯数字密码，一旦启用策略便会触发此错误。
• 如果在Profile中配置了 PASSWORD_REUSE_MAX（密码最大重用次数）和 PASSWORD_REUSE_TIME（密码重用时间）参数，当用户尝试重用近期使用过的密码时，也会被验证函数拦截并报出 ORA-28003 错误。
• 还有一种较为隐蔽的情况：若验证函数内部调用了 DBMS_RANDOM.STRING 等包来生成随机盐值，但执行用户权限不足，可能导致函数静默失败，从而引发验证逻辑异常。其表象就是“密码明明符合规则，系统却依然报错”。

Oracle 19c后继续使用VERIFY_FUNCTION是否安全

答案是不推荐。Oracle官方在19c的文档中已明确将 verify_function 标记为“已弃用”（Deprecated）。这个旧版本函数存在多处安全短板：不支持Unicode字符校验、缺乏有效的防字典攻击机制，且其规则硬编码在PL/SQL代码中，难以进行审计和灵活调整。

• 应优先采用 ora12c_strong_verify_function。其优势在于，可以通过查询 DBA_PROFILES 数据字典视图来动态调整密码最小长度、所需字符类型数量等策略参数，管理更为灵活。
• 若需要实现更细粒度的控制（例如禁止使用手机号、生日或常见邮箱格式作为密码），则需要编写自定义验证函数。关键点在于：自定义函数应继承并调用 ora12c_strong_verify_function 的基础校验逻辑，否则可能绕过核心安全检查，引入安全漏洞。
• 特别注意：在自定义函数中，应避免使用 UTL_HTTP、UTL_FILE 等可能进行外部调用的包。因为在密码验证阶段，Oracle会限制此类外部调用，使用它们可能导致 ORA-06512 程序包错误，进而使得整个 ALTER USER 操作失败。

总而言之，真正的挑战往往不在于执行安装脚本本身，而在于启用密码验证函数后所带来的连锁影响。所有自动化建库流程、CI/CD流水线中的用户初始化脚本，乃至使用Oracle Data Pump（数据泵）进行数据导入时的密码重置操作，都将受到其约束。因此，在生产环境部署前，务必在测试环境中使用真实的建库与用户管理脚本进行全流程验证，这能有效规避大量潜在问题与运维风险。