应用发送已哈希密码时，如何适配LDAP服务器的明文哈希认证逻辑？

当前LDAP服务器的验证逻辑是：接收明文密码→计算哈希值→与存储的哈希值比对完成验证。但你的应用发送的是已哈希后的密码，导致服务器对这个哈希值再次计算哈希，最终结果和存储的原密码哈希值不匹配，验证失败。

实际示例：

• 原密码：abc
• 原密码哈希值：ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
• 正常流程：LDAP接收明文abc，计算哈希后与存储值一致，验证通过
• 你的场景：应用发送哈希值ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad，LDAP再次哈希得到b6291ce396cb2fd46f4a5410b4f9a739ae89e182fc0bd0fc7f8d064e5bfe35e9，和存储的原哈希值不符，验证失败

方案1：修改应用逻辑，发送明文密码（推荐） #

这是最符合LDAP标准验证流程的方式：

• 应用直接收集用户输入的明文密码，通过**加密通道（如LDAPS/TLS）**发送给LDAP服务器
• 由LDAP服务器完成哈希计算和比对，避免应用层面处理密码哈希的风险

方案2：配置LDAP服务器支持预哈希密码验证 #

部分LDAP服务器（如OpenLDAP）支持配置允许客户端发送预哈希密码，此时服务器会直接比对接收的哈希值和存储值，不再二次哈希：

• 对于OpenLDAP，可配置pwdHash属性或启用ppolicy模块的相关参数，具体需参考服务器文档调整配置
• 注意：此方式需要确保应用生成的哈希算法、盐值（如果有）与LDAP服务器存储的完全一致（包括哈希类型、编码格式）

方案3：调整应用哈希逻辑，模拟LDAP的哈希过程（不推荐） #

如果无法修改应用发送明文的逻辑，可让应用按照LDAP服务器的哈希规则，直接生成和存储值完全一致的哈希结果，但这种方式存在以下问题：

• 需完全对齐LDAP服务器的哈希算法（如SHA-256、加盐规则等），一旦服务器配置变更，应用需同步修改
• 应用层面处理密码哈希，增加了密码泄露的风险

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