业务用户默认可改密，禁用须显式回收alter user权限，profile限制无效；代理用户、dba用户及password命令均受此权限控制影响。
业务用户默认能改自己密码，想禁用必须显式收回权限，不能只靠 profile 限制。
ALTER USER … IDENTIFIED BY 是唯一允许用户改密的途径
Oracle 中用户修改自身密码的底层动作，本质是执行了一条 ALTER USER username IDENTIFIED BY newpass 语句。只要该用户拥有 ALTER USER 系统权限（哪怕只是针对自己），就能成功执行——PASSWORD_LIFE_TIME 或 PASSWORD_VERIFY_FUNCTION 这类 profile 设置，只管“新密码合不合格”，不管“能不能改”。
- 默认情况下，
CONNECT角色不包含ALTER USER，但很多 DBA 会额外授予，或用户被直接 GRANT 过 - 检查方法：
SELECT * FROM dba_sys_privs WHERE grantee = 'HFXF' AND privilege = 'ALTER USER'; - 回收命令：
REVOKE ALTER USER FROM hfxf;（注意：这也会禁止该用户修改其他用户的配额、默认表空间等）
代理用户（proxy）场景下仍可改密，需额外拦截
当应用通过代理连接（如 CONNECT appuser[proxyuser]/pwd@db），实际会话属 appuser，但权限上下文含 proxyuser 的部分能力。此时若 proxyuser 拥有 ALTER USER，它仍可能执行 ALTER USER appuser IDENTIFIED BY ...。
- 验证是否启用代理认证：
SELECT username, proxy FROM dba_proxies WHERE client = 'APPUSER'; - 禁止代理用户操作目标用户密码：确保
proxyuser没有ALTER USER，且不要在创建代理时加WITH ADMIN OPTION - 更彻底的方式：用 Database Vault 创建 realm，把
ALTER USER操作纳入保护范围（需额外许可）
自定义密码验证函数无法阻止改密动作本身
像 my_password_verify 这类函数，只在密码变更时被调用校验逻辑，返回 FALSE 或抛错只会让 ALTER USER … IDENTIFIED BY 失败，但不会阻止用户发起该语句——错误信息仍是 ORA-28003: password verification for the specified password failed，而非权限拒绝。
- 函数里写
raise_application_error(-20001, 'not allowed')无效，它只影响密码合规性判断 - 真正拦截必须靠权限控制层，不是密码策略层
- 如果硬要“伪装禁止”，可在函数中查
sys_context('USERENV','SESSION_USER')，对特定用户直接返回FALSE，但这是绕过设计意图的 hack
DBA 用户无法被 profile 或 revoke 完全限制
拥有 DBA 角色的用户，天然具备 ALTER USER 权限，且 profile 限制对其基本失效（例如 FAILED_LOGIN_ATTEMPTS 仍生效，但密码过期、复杂度等可被绕过）。这类账户的密码管理只能靠流程管控或 Database Vault。
-
SELECT * FROM session_roles;可快速确认当前会话是否含DBA - 不要给业务账号赋予
DBA；若必须，拆分出最小权限角色替代 - 高敏环境建议启用 Oracle Unified Directory 或外部认证（如 LDAP），把密码生命周期交给目录服务统一管理
最易被忽略的一点：REVOKE ALTER USER 后，用户仍可通过 SQL*Plus 的 password 命令触发改密——该命令底层就是发 ALTER USER，权限检查照常发生，所以只要权限没了，password 命令也会报 ORA-01031: insufficient privileges。别信“客户端界面能点就代表能改”这种直觉。
