这是一个简单的想法，基于一些阅读。
服务器存储（明文+盐）的哈希版本。这可以避免看到密码，只要哈希难以反转。
当客户端尝试登录时，服务器会发送它（salt，random），即一个常量salt和一个新生成的随机字符串。
客户端发回哈希（哈希（明文+盐）+随机），即客户端附加盐，哈希，然后追加随机，然后再次哈希。
服务器检查哈希值是否与它自己的H（H（pwd + salt）+ rnd）相同。
我对此没有多少经验，所以我可以问一下潜在的问题是什么？另外，通常用盐做什么？你真的可以使用同样的盐吗？
答案 0 :(得分：2)
您建议的方案不会为检查密码添加任何安全性，只会增加使用SSL进行登录的复杂性。使用SSL，您可以安全地将明文密码从浏览器传输到服务器，使用salt散列它，然后检查存储的散列。这消除了对复杂方案的需要。在这个时候，只有国家组织才能以系统的方式切实破坏SSL连接，尽管一些真正有进取心的黑客已经发现了一些有趣的漏洞。
您描述的方案听起来非常像Diffie-Helman零知识密钥交换，它比ssl安全得多，因为它在最初设置服务器之后从未真正传输密码。今天这种密钥交换的问题在于它必须在客户端用Javascript编写，因此，将实际工作暴露给每个关心的攻击者。然后攻击者可以用其他东西替换你的Javascript，或者如果你不使用SSL，只需点击它来收集初始密码，所以你再次只是从客户端到服务器的SSL连接的安全性只有一个一堆增加的复杂性和失败点。有一些方法可以使用ActiveX，Java或其他项来创建浏览器插件来处理所有密钥交换内容，但这又为用户增加了一个不明显的故障点，为用户增加了额外的步骤。网站不需要（安装附加组件或书签），并且让您在开发过程中花费更长时间而无需真正的好处。
Firefox一直致力于在浏览器级别为密码实现Diffie-Helman密钥交换，如果它起飞，它将允许大量增加的安全性并使这种密码方案可行。