dba_users_with_defpwd视图是oracle 11g及以后版本唯一官方支持的直接识别默认密码账号的途径，执行select username from dba_users_with_defpwd;即可获取当前仍在使用出厂默认密码的用户列表，结果实时准确、自动更新，且不包含sys和system（需人工核对其默认密码change_on_install和manager）。
dba_users_with_defpwd 视图是唯一能直接列出仍在用默认密码的账号的官方途径，其他方式（比如查 user$ 表里的 password 字段）只能看到加密哈希值，无法还原明文，也不具备可操作性。
怎么快速查出还在用默认密码的账号
Oracle 11g 及以后版本自带 dba_users_with_defpwd 视图，它只收录那些密码仍为出厂默认值的用户。只要执行一条查询就能拉出全部名单：
SELECT username FROM dba_users_with_defpwd;
这个视图不依赖你是否记得任何密码——只要你能以 SYSDBA 身份登录（比如 sqlplus / as sysdba），就能运行。注意：该视图在用户改过密码后会自动移除对应条目，所以结果即代表“当前真实风险账号”。
- 如果返回空集，说明没有账号还在用默认密码
- 如果返回
CTXSYS、MDDATA等，说明这些辅助账户未被加固，属于典型弱口令隐患 - 该视图不包含
SYS和SYSTEM——它们的默认密码（change_on_install、manager）需人工核对，不在该视图中
为什么不能直接查 dba_users.password
dba_users 表里确实有 password 字段，但它存的是加密后的哈希值（如 S:8A5F...B2C9），不是明文。Oracle 从不存储明文密码，也禁止任何形式的逆向还原。试图用 SELECT username, password FROM dba_users 查“密码”只会得到一堆不可读字符串，对定位弱口令毫无帮助。
- 老版本（如 10g）可能用 DES 加密，新版本（11g+）默认用 SHA-1 + salt，强度更高
- 即使你拿到哈希值，也无法通过 SQL 或 PL/SQL 解密——这不是权限问题，是设计使然
- 某些第三方工具声称能“爆破”或“解密”，实际只是拿哈希去比对字典，成功率极低且违反安全规范
哪些默认账号最常被忽略
除了广为人知的 SYS/change_on_install、SYSTEM/manager、SCOTT/tiger，Oracle 安装时还会创建大量内置账户，其中不少保留默认密码且长期无人维护：
-
APPQOSSYS、CTXSYS、EXFSYS、MDDATA、OLAPSYS—— 这些在dba_users_with_defpwd中高频出现 -
ORDSYS、SI_INFORMTN_SCHEMA—— 常因未启用功能模块而被遗忘，但账户仍激活且密码未改 -
DBSNMP—— OEM 监控账户，若未重置密码，极易成为攻击入口
这些账号大多不具备业务逻辑，但拥有高权限包或系统视图访问权，一旦被利用，可横向提权或导出敏感元数据。
修改弱密码时必须避开的坑
用 ALTER USER ... IDENTIFIED BY 改密码看似简单，但几个细节错一步就失败：
- 密码含特殊字符（如
@、#）必须用双引号包裹：ALTER USER ctxsys IDENTIFIED BY "Ctx#2026"; - 密码太短或不符合复杂度策略会报
ORA-28003错误，先查当前 profile：SELECT profile FROM dba_users WHERE username = 'CTXSYS';，再查该 profile 的限制：SELECT * FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name IN ('PASSWORD_VERIFY_FUNCTION', 'PASSWORD_REUSE_TIME'); - 改完密码后，别忘了解锁（如果状态是
LOCKED）：ALTER USER ctxsys ACCOUNT UNLOCK; - 对
SYS用户，不能用普通连接改密码；必须用sqlplus / as sysdba，否则报ORA-01031: insufficient privileges
真正麻烦的不是查不到密码，而是查到之后，发现一堆账号用了相同弱密码、没解锁、或受 profile 限制卡住——这些点串起来才是实际运维中最耗时间的部分。
