Oracle 11g起dba_users.password字段默认为空，因安全设计主动屏蔽哈希暴露；虽底层改用SHA-1存储，但该算法已过时，需手动重设密码并配置才能升级至更安全算法。
Oracle 11g 起 dba_users.password 字段已为空，不是你查错了
oracle 11g 开始，dba_users 视图中的 password 列默认返回 null（或空字符串），这不是权限不足、视图没刷新，也不是你漏了什么参数——它是 oracle 主动移除的。从安全设计上，连加密哈希都不再暴露，避免攻击者离线暴力破解或重放利用。
- Oracle 10g 及更早版本中，
PASSWORD字段存的是 DES 加密的哈希（如7D55A4DE0D9A4BEB），可被提取后用工具尝试碰撞 - Oracle 11g 引入 SHA-1 哈希算法存储密码（实际写入
user$底层表的password列），但屏蔽了对dba_users的暴露路径 - 即使你有
SELECT ANY DICTIONARY权限，也查不到——这是硬编码限制，非权限控制
想确认密码是否真的“不可见”，直接执行这条 SQL
别依赖文档或记忆，现场验证最可靠：
SELECT username, password FROM dba_users WHERE username IN ('SYS', 'SYSTEM', 'TEST');
在 11g+ 环境中，结果里 PASSWORD 列全是空值；若看到一串十六进制字符，那一定是连接到了 10g 或更老库，或者误用了兼容模式。
- 注意：
dba_users.authentication_type字段仍可用，能区分是PASSWORD还是EXTERNAL认证 -
password_versions字段保留，显示当前用户密码支持的加密版本（如10G 11G 12C），但它不等于密码哈希本身 - 不要试图用
DBMS_METADATA.GET_DDL或user$表绕过——直接查user$需要极高权限且属未公开行为，稳定性与支持性无保障
密码加密机制升级了，但 SHA-1 已不够安全
Oracle 11g 默认用 SHA-1 对密码做哈希，比 10g 的 DES 强，但 SHA-1 在 2017 年已被 NIST 官方弃用。真实风险在于：如果攻击者拿到系统级备份或内存 dump，仍可能恢复弱口令。
-
sec_case_sensitive_logon = TRUE（默认）开启大小写敏感，让Abc和ABC视为不同密码，提升熵值 - 启用密码复杂度函数：
@$ORACLE_HOME/rdbms/admin/utlpwdmg.sql创建verify_function_11G，再绑定到 profile：ALTER PROFILE default PASSWORD_VERIFY_FUNCTION verify_function_11G - 真正加固得靠组合：禁用简单密码 + 启用账户锁定策略（
FAILED_LOGIN_ATTEMPTS）+ 关闭旧协议（如禁用SQLNET.ALLOWED_LOGON_VERSION_SERVER=8）
别指望从数据库里“还原”密码，该换思路了
DBA 不该也不需要知道用户明文密码。任何试图从哈希反推、或用工具爆破的行为，既违反运维规范，也大概率失败——因为现代 Oracle 密码哈希还加了 salt（随机盐值），且每次改密 salt 都变。
- 密码重置应走标准流程：
ALTER USER xxx IDENTIFIED BY newpass，而不是“找回” - 应用连接池配置里硬编码密码？赶紧换成 Oracle Wallet 或外部凭证存储（如 HashiCorp Vault）
- 审计需求请用
unified_audit_trail查登录事件，而非盯住哈希字段——它本就不是为审计设计的
真正容易被忽略的点是：很多人升级到 12c/19c 后，以为 SHA-1 自动升级成 SHA-2 或 PBKDF2，其实没有。直到 12.2 才引入 SEC_CASE_SENSITIVE_LOGON 的扩展支持，而完整密码哈希算法切换仍需手动配置并重设密码。不重设，就永远卡在 SHA-1。
