这个认证方案有什么问题？答案

【问题标题】：What's wrong with this authentication scheme?这个认证方案有什么问题？
【发布时间】：2014-01-26 04:09:45
【问题描述】：

我不是安全专家，只是一个充满激情的开发人员。在The definitive guide to form-based website authentication 中非常明确地指出，只有 SSL 或奇怪而复杂的算法对于保护登录数据不被窃听是实用的。因此，在我完全不了解计算机安全的情况下，我不明白为什么以下身份验证方案不安全：

按下登录按钮后，客户端通过 javascript 向服务器请求一个足够长的随机字符串
客户端对随机消息和密码（尚未传输）进行哈希处理。
客户端使用密码散列加密（通过河豚或您最喜欢的算法）随机消息散列。
客户端将生成的 blob 发送到服务器
服务器使用存储在数据库中的密码哈希解密消息（因为我们自己保留哈希而不是密码；）
如果生成的哈希与原始消息哈希匹配，则客户端通过身份验证。

我没看到的陷阱在哪里？密码永远不会通过网络发送，也不是哈希。服务器只保留密码哈希...

【问题讨论】：

这比使用 TLS 更“奇怪和复杂”吗？TLS 根本不涉及客户端上的编码？
好吧，SRP 肯定要复杂得多 :) 我并不是说我不会使用 TLS，我只是想不明白这有什么问题。
也许这个问题应该放在security.stackexchange.com

标签： javascript authentication login client-side

【解决方案1】：

你不需要密码来通过这个方案进行身份验证，只需要密码的哈希值。因此，从加密方面来看，密码哈希实际上是一个普通密码。所以：

Salt 和 hash(pass+salt) 可能会被窃听，pass 是一个 de-hash 即可
服务器存储纯密码

这还没有考虑到未加密的连接总是容易受到 MITM 的攻击

【讨论】：

密码哈希如何被窃听？它仅用作加密发送到服务器的随机字符串的密钥。密码哈希永远不会离开客户端电脑。
@AlfaOmega08 将 encrypt(pass,data) 视为 hash(pass,salt)
哦，我明白了，“随机消息”只是散列函数的盐。但是，鉴于攻击者读取了“hash(pass, salt)”或“encrypt(pass, data)”消息，他仍然需要巨大的计算能力才能将其分解为原始部分，对吧？
@AlfaOmega08 对于攻击者来说，就像他在传统方案中获得了服务器存储的哈希一样。需要多少计算能力取决于哈希函数和密码强度。
@AlfaOmega08 因为盐会在未加密的情况下发送，唯一的区别是需要计算较长字符串的哈希