Postgres采用SCRAM-SHA-256认证时连接初始化阶段是否加密密码

首先给出明确结论：使用SCRAM-SHA-256认证时，客户端全程不会在网络中传输明文密码、甚至密码的直接哈希值，协议本身的设计就可以避免密码被传输窃听获取，不需要额外依赖传输层加密就能保障密码本身的认证安全。

核心认证流程的安全逻辑 #

SCRAM-SHA-256是基于挑战-响应模型的认证协议，整个交互过程没有任何一步需要客户端提交密码本体：

• 连接初始化后，服务端首先向客户端发送随机生成的认证挑战参数，包含专属随机盐、约定的哈希迭代次数、服务端单次连接随机数
• 客户端收到挑战后，所有密码相关的运算全部在本地内存完成：用用户输入的明文密码、收到的盐和迭代次数，按照标准SCRAM算法分层计算多组校验值，最终仅向服务端发送客户端生成的单次连接随机数、第一阶段客户端身份证明值，原始密码不会离开客户端本地
• 服务端存储的也不是用户明文密码，而是提前计算好的SCRAM衍生密钥，收到客户端证明值后，用本地存储的密钥做运算比对，校验通过后再生成服务端侧的身份证明发回给客户端
• 客户端校验服务端返回的证明，确认服务端确实持有合法的对应密钥后，整个认证流程才正式完成

防窃听的实际效果 #

• 即使攻击者完全窃听了整个认证过程的所有网络报文，也只能拿到单次连接有效的随机数、临时哈希证明值，既无法通过这些值反推出用户的原始密码，也无法通过重放截获的报文伪造登录——每次新连接生成的随机参数完全不同，历史截获的认证凭证没有复用价值。
• 该安全能力是SCRAM-SHA-256协议原生自带的，和是否启用TLS/SSL传输加密没有绑定关系：即使未开启SSL连接，SCRAM认证阶段也不会泄露密码。不过生产环境仍建议开启TLS，用来保护认证完成后的业务查询、结果返回等后续传输内容的安全。

注意不要把SCRAM的机制和旧的md5认证混淆：PostgreSQL旧的MD5认证虽然也不直接发明文密码，但存在盐值固定、可被离线爆破的风险，安全强度远低于SCRAM-SHA-256。

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