关于数据库密码哈希存储后应用认证连接流程的技术咨询

核心前提先明确 #

哈希是单向不可逆的算法，要是数据库只认明文密码，你绝对没法用哈希后的字符串直接连接。别想着逆向破解哈希——那既不安全也不可靠，生产环境绝对不能碰。下面说几种合规的解决思路：

1. 用加密存储替代哈希，解密后用明文连接 #

把明文密码做可逆加密（比如AES），加密后的密文存在配置文件里，密钥单独存在安全的地方：

• 运维先拿AES密钥加密数据库明文密码，把密文写到应用配置里
• 应用启动时，从专门的密钥管理工具（比如本地密钥库、云KMS）读取AES密钥
• 用密钥解密配置里的密文，拿到明文密码后再发起数据库连接
• 好处是避免明文直接暴露，密钥和密文分开存储，降低泄露风险

2. 切换到数据库支持的无密码认证方式 #

很多主流数据库都支持不用密码的认证，比如：

• SSL证书认证：给应用发客户端证书，数据库配置信任这个证书，应用连接时带证书就能过认证，全程不用密码
• IAM令牌认证：云环境里，应用通过IAM角色获取临时令牌，用令牌替代密码连数据库（比如云厂商的RDS服务大多支持）
• 操作系统用户认证：比如PostgreSQL的peer认证，应用进程的系统用户和数据库用户名匹配就直接通过

3. 用系统级安全存储存明文密码 #

把明文密码存在操作系统的安全存储里，比如：

• Linux用libsecret或者keyctl
• Windows用凭据管理器
• macOS用钥匙串
  应用启动时通过系统API读取这些存储里的明文密码，再用于数据库连接，避免明文写在配置或代码里

顺便说下：哈希密码的正确认证流程（数据库支持的情况） #

要是数据库本身支持哈希认证（比如PostgreSQL的scram-sha-256），流程是这样的：

1. 数据库端自己生成用户密码的哈希值并存储，不是应用提前哈希
2. 应用发起连接时，还是传明文密码（当然得走SSL加密通道）
3. 数据库用存的哈希值和应用传的密码做哈希比对，验证身份
   这种场景下，应用还是得持有明文密码，只是数据库不存明文而已——和你之前想的“应用存哈希再发给数据库”完全是两回事

内容的提问来源于stack exchange，提问作者Leo