RFC 3112：密码匹配不等于完成认证

摘要

RFC 3112 把口令派生值写成区分大小写的三部分：方案、方案信息和认证值。匹配规则可以返回 TRUE、FALSE 或 Undefined，但这些只是比对结论，不是 LDAP 关联的认证结果。
RFC 明确要求使用 Bind 完成目录认证。属性又允许保存多个值，因此获得写权限的人可以添加第二个可用密码，而不必让用户原有密码失效。

一个真实答案，属于另一个状态机

客户端把密码交给 LDAP 匹配规则。服务器找到目录值，读取方案与盐，计算应得结果，最后返回真。密码确实匹配了，但客户端还没有向目录完成认证。

这不是文字游戏，而是 RFC 3112 最重要的控制边界。2001 年 5 月，以 Informational 发布的《LDAP Authentication Password Schema》试图让目录保存从密码派生的信息，而不是当时 userPassword 用法所预期的实际密码。它定义了语法、两条匹配规则、根 DSE 能力属性和辅助对象类。设计完便捷的密码测试后，文档随即提醒客户端：无论通过 Compare 还是 Search 得到成功的 authPasswordMatch，都不足以取得目录访问；认证必须使用 Bind。

两个操作回答了不同问题。匹配规则判断一段输入是否按照声明方案与至少一个存储值相符。Bind 判断服务器是否接受某个认证身份，把它绑定到当前 LDAP 关联。之后，访问控制才决定由此形成的授权身份能执行什么操作。目录之外的应用还要对自己的业务动作作出决定。

若日志只留下“登录成功”，证据链就被压扁了。匹配可以在没有 Bind 时发生；Bind 成功后，某项写操作仍可能被拒绝；目录读取成功，也不能证明应用内的付款、变更或下载已经完成。

存储值随身携带计算方法

authPasswordSyntax 由美元符号分隔的三个区分大小写部分组成：scheme、authInfo 和 authValue。第一部分命名机制；第二部分通常存放 base64 编码的盐；第三部分通常存放由密码派生并编码后的值。

这种自描述格式让同一目录能并存不同方案，也让服务器说明自己理解哪些方案。RFC 3112 定义了 MD5 与 SHA1。私有实现要使用 X- 前缀或对象标识符。只允许出现在根 DSE 的 supportedAuthPasswordSchemes，负责公布服务器声称支持的方案名称。

公布支持不等于证明执行。根 DSE 没有说明某次认证实际选了什么方案、哪个条目保存了哪些值、盐是否唯一、谁写入了它、操作是否经过保密信道，更没有说明 Bind 是否成功。它是能力声明，不是运行轨迹。

历史距离也必须保留。RFC 3112 中的 MD5 与 SHA-1 方案，把密码与盐拼接后求摘要；盐至少 64 位，实现必须支持最长 128 位。这是 2001 年的规范事实，不是当代密码存储建议。后来 RFC 8018 把盐与迭代次数作为口令密码学的显式参数；RFC 9106 规定了内存困难函数 Argon2，并推荐 Argon2id 用于密码散列和密钥派生。后来的文档不能倒改旧 RFC，却说明了为什么证据必须保留精确方案和成本参数，而不能只写一句“已安全散列”。

编码相等、密码匹配与认证不是一回事

authPasswordExactMatch 比较已经编码的三个组成部分。若某个存储值的方案、authInfo 与 authValue 都相同，结果为真；没有任何相同值则为假；其他情况为不确定。这是表示形式之间的相等。

authPasswordMatch 则通过扩展匹配过滤器接收一段待测密码。服务器依照每个存储值自己的方案进行计算。一个值匹配就可返回真；全部不匹配才返回假；无法完成判断则返回 Undefined。

三种结果都没有识别键盘前的人。真不能证明谁控制信道，也不能证明请求者有权测试该属性。假不能证明条目选对了、方案选对了，或者外部认证库中没有其他凭据。不确定更不是“密码错误”，它专门保留了“服务器没有得出结论”这一事实。

RFC 3112 坚持必须 Bind，正是为了阻止比对结果越权。后来的 RFC 4511 在修订版 LDAP 协议中描述 Bind 结果；RFC 4513 又进一步区分认证身份与授权身份。授权身份可以由认证身份推导，也可以在合适机制下另行提出，但服务器必须确认客户端有权代表那个身份。

因此，Bind 成功也不是无限授权。认证只说明服务器在这条关联上接受了谁；授权要回答该身份能否对当前对象执行当前操作；使用 LDAP 的业务系统仍负责自己的最终行为。

多个值，意味着多个可能入口

authPassword 没有限制为单值。针对选定方案，服务器应检查所有相关值；其中任何一个匹配，都可能让待测密码有效。它可以用于方案迁移、凭据重叠或管理策略，也让每一次写权限都可能变成新增入口的权限。

RFC 3112 直接写出了攻击方式：取得属性写权限的人，可以加入一个额外值，而无需让用户真正的密码失效。受害者仍能照常登录，没有明显的重置或锁定异常；第二扇门却能长期存在。

条目的最终快照无法还原过程。两个值只能证明当前有两个值，不能证明谁分别添加、哪条政策批准、是否经过口令修改操作、原本该淘汰哪一个。证据必须追踪添加、替换与删除，连同写入身份、授权结果、值指纹、方案、参数、复制过程与退役时间。

RFC 3062 在此之前已经定义 LDAP Password Modify 扩展操作。服务器可以在受控规则下确认目标、接受或生成新密码，并选择存储方式，不必把普通属性写入当成口令生命周期的全部。RFC 3112 可以与它配合，却不能仅凭一个字段承担完整账号控制。

服务器还可以把 authPassword 与 userPassword 或外部口令库组合使用。看到一个属性不等于看见了全部认证决策面；移除一个值也不一定撤销所有入口。

派生值仍要按秘密保护

RFC 3112 拒绝“单向散列即可公开”的安慰。它建议把派生值当作明文密码一样保护：算法缺陷、实现错误与离线攻击都可能把泄露变成访问能力。底层传输无法保证机密性时，强烈不建议传递这些值。

authPasswordMatch 中提交的密码同样敏感。它把一次在线猜测送到服务器；未保护的信道会泄露密码，开放过度的匹配规则会变成口令测试预言机。服务器必须为此设置访问控制与抗攻击措施。

计算成本又带来可用性问题。昂贵方案能提高攻击者的试错成本，也能让不受信客户端消耗服务器 CPU。速率限制、并发预算、超时和谁有权发起比较，都是机制的实际安全含义。方案名再强，也不能证明部署没有拒绝服务缺口。

旧上下文改变了，边界没有消失

RFC 3112 以 1997 年 RFC 2251、RFC 2252 与 RFC 2256 的 LDAP 模型为背景，强调 userPassword 所面对的明文口令问题。这个对比不能被写成永久事实。后来的 RFC 4519 明确说，userPassword 的值不要求是明文，也不要求一定可供 Bind 使用；实现还发展出自己的带标签形式。

RFC 3112 的 Informational 身份也限制了结论。RFC Editor 与 IETF Datatracker 记录证明文档曾发布及其历史，不证明广泛部署。RFC 2829 与 RFC 4513 给出更大的认证安全框架；RFC 4511、RFC 4517 与 RFC 4519 展示协议、匹配规则和用户模式的后续修订。它们都不能证明某个具体目录启用了 authPassword。

真正持久的是分层方法。结构化值不等于已执行政策；匹配成功不等于关联认证；关联认证不等于全面授权；LDAP 授权更不等于用户已经观察到业务成功。

若要证明“某人登录了”，应分别保留：条目及其变更历史；方案、盐与参数；谁被允许 Compare 或 Search；信道保护；请求和真、假、不确定结果；实际测试了哪些值；Bind 请求、机制与响应；产生的认证身份与授权身份；后续目录操作、访问控制结果以及应用端最终表现。

密码可以完全匹配。RFC 3112 的成熟之处，是知道这个真实答案必须停在 Bind 门外。

密码匹配了，用户仍未完成认证：RFC 3112

为何重要

摘要

一个真实答案，属于另一个状态机

存储值随身携带计算方法

编码相等、密码匹配与认证不是一回事

多个值，意味着多个可能入口

派生值仍要按秘密保护

旧上下文改变了，边界没有消失

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报