SCRAM-SHA256及SCRAM模型注册阶段密码处理方式咨询

1. 密码哈希的处理位置：客户端还是服务器？ #

首先得明确：SCRAM是认证协议，RFC确实没定义注册流程——这给了你设计空间，但也需要紧扣SCRAM的安全模型。

如果你的核心目标是客户端绝不向服务器泄露明文密码，那客户端必须承担PBKDF2（SCRAM指定的密钥派生算法）的计算工作。但这里有个关键细节：SCRAM的盐值和迭代次数，在标准认证流程里是服务器提供的（用来验证客户端身份）。放到注册场景里，你有两种可行选择：

• 方案A：服务器先生成随机盐和符合安全标准的迭代次数，返回给客户端；客户端用这些参数+明文密码计算PBKDF2结果，再进一步算出SCRAM所需的storedKey和serverKey，最后把这些值（加上盐和迭代次数）发给服务器存储。
• 方案B：客户端自行生成盐和迭代次数，完成PBKDF2、storedKey、serverKey的计算后，把所有组件发给服务器存储。

两种方案都能避免明文密码传输，但方案A能让服务器控制关键安全参数，安全性更可控。

2. 注册时客户端应发送明文还是PBKDF2哈希？ #

答案很明确：绝不发送明文密码——这是你设定的核心安全目标，必须坚守。但也不是直接发PBKDF2哈希，而是要发送SCRAM协议要求的完整存储组件：盐、迭代次数、storedKey、serverKey。因为单独的PBKDF2哈希无法支撑SCRAM后续的挑战-响应认证流程，必须生成协议指定的密钥对才能完成认证逻辑。

3. 客户端不泄露明文的弊端：服务器无法验证密码强度、参数控制 #

这确实是一个实际问题，会带来几个具体影响：

核心弊端： #

• 密码强度无法核验：服务器看不到明文，没法检查密码长度、复杂度（比如是否包含大小写/特殊字符、是否在常见密码字典中）。弱密码哪怕经过哈希，也容易被彩虹表或暴力破解，直接降低整体安全性。
• 参数失控风险：如果客户端自行决定迭代次数或盐值，可能出现客户端为了性能选用过低的迭代次数，或者生成的盐不够随机（比如用固定值或弱随机源），直接削弱PBKDF2的抗暴力破解能力。
• 后续参数更新困难：如果以后需要提高迭代次数（比如硬件性能提升，需要更强的哈希防护），服务器没法直接处理——旧的storedKey和serverKey是基于旧参数生成的，除非用户再次输入密码，客户端重新计算新参数下的密钥对。

折中解决方案： #

• 客户端侧前置校验：在客户端先做密码强度检查（比如用前端正则、本地字典匹配），通过后再进行哈希计算。虽然没法完全避免客户端篡改校验逻辑，但能覆盖大部分普通用户的场景。
• 服务器强制参数标准：采用上面的方案A，由服务器生成盐和迭代次数并下发，确保参数符合安全要求，客户端只能基于这些参数计算，避免参数失控。
• 登录时静默更新参数：在用户下次登录时，服务器可以要求客户端用新的迭代次数重新计算storedKey和serverKey，更新存储值——这样不用用户特意重置密码，就能逐步提升安全性。

4. 其他利弊总结 #

优势： #

• 彻底规避明文泄露风险：哪怕传输过程被窃听，攻击者也得不到能直接破解的明文密码，大大降低中间人攻击的危害。
• 减轻服务器计算负载：PBKDF2是计算密集型操作，客户端计算能分散服务器压力，尤其在用户量较大时更明显。

额外弊端： #

• 客户端实现复杂度提升：需要在客户端正确实现PBKDF2和SCRAM的哈希逻辑，一旦出现实现错误（比如哈希算法用错、迭代次数计算偏差），会导致认证失败或安全漏洞。
• 调试难度增加：如果出现认证失败问题，很难排查是客户端计算错误还是服务器存储/校验错误，因为服务器看不到原始密码。

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