我的一个朋友和我是有关于我们是否应该预先散列我们的web应用程序的用户的密码将其发送到我们的服务器之前的讨论。
我知道，有一个已经处理这个主题相关的多个问题，但他们都了解如何安全转移到服务器。我们的想法是不是对传输安全（我们使用SSL），我们希望哈希客户方，以防止“真正的”密码达到我们的服务器。
这个想法如Twitter宣布了他们的错误，导致密码被打印在明文日志文件。
我们目前正在讨论关于这个概念是否有意义与否以及它如何影响一个密码的安全性（在猜解而言），如果我们将与SHA512散列它。
TL; DR：
我们希望哈希密码的客户端，以防止我们的服务器从让他们以明文（我们使用SSL传输）。
这有道理吗？ 什么算法将是最好用哈希？
散列密码，然后将服务器端被再次bCrypt散列。
这100％是有道理的：事实上，这一概念已经提出了一些人，但难的是在正确实施。有许多的陷阱，如果你这样做不对，最直接的一个易受“传递的哈希值”为@ swa66描述。为了防止这种情况，你需要哈希两侧。客户端的散列应缓慢（bcrypt，scrypt，argon2，或PBKDF2），而在服务器侧散列应该是快速（SHA256）。
编辑：不少人都向下投这种不理解这是如何工作的，所以我现在在这里包括基本信息（以前我只挂这是如何工作）。我们的想法是申请一个缓慢的散列比如bcrypt在客户端，然后快速散列如在服务器端SHA256。快速哈希是为了防止通的哈希攻击。在数据库中的泄漏，攻击者或者散列反转快速散列的情况下（是不可能的 - 违反密码散列函数的单向性），或蛮力原像到快速散列（不可能 - 的大小是从慢散列输出的长度，为bcrypt例如184比特），或蛮力缓慢散列的组合和快速散列 - 这使攻击者背部在同一位置，好像整个计算发生了服务器端。因此，我们不被繁重的计算转移到客户端减少的数据库泄漏事件密码攻击的安全性。
我调查了一些在Method to protect passwords in databases for web applications这样的建议。此外，我分析利弊，找出以前没有（帐户枚举）发现的弱点，并提出安全这样的独特方式。这项研究是建立关闭若干来源，包括：
你引用Twitter的例子，GitHub上做类似的。当我写上面的纸，以防止服务器从看到明文密码的最突出的例子是心脏出血漏洞，这是我在报纸（1.3节的底部）发表评论。
已经有后续跟进其他识别类似的观点研究 - Example: Client-Plus-Server Password Hashing as a Potential Way to Improve Security Against Brute Force Attacks without Overloading the Server。没有一个人值得所有的信贷，但主要的重点是：是的，它是，如果你做一个安全的好主意，但你真的需要理解风险（这很容易，如果你没有看过的研究做不安全）。
没有！
第一个在密码：不要自己发明它，你会做出可怕的错误。
这并不是针对你个人，远远不是：小心翼翼新系统设计时，甚至顶尖的专家犯错误。这就是为什么他们每一个，其他人的工作多次评审的事情之前成为一个标准。通过这样的专家对这种标准的很多提案得到重绘由于这样的同行评审过程中发现的问题。那么，为什么不能我们其余的凡人设计：有没有人不够好，做同行评审的专家们不会动它。
哈希密码客户端
哈希客户端是非常糟糕的哈希值将成为密码，现在你把它存储在清除服务器上。
如何做密码
有您的编程环境 - 预先制作程序-depending，使用它们！
参考：
同时概述了如何安全地管理密码，让我注意，有一个有效的情况下，你可以考虑客户端的密码散列，所以不要只是一味地遵循“最佳实践”，试图先了解它@ swa66。
比方说，我有一个从用户存储数据的标准Web应用程序。在我的威胁模型，我甚至不希望我自己的用户必须信任我，或者换句话说，我希望我的用户数据是安全的，即使在我的服务器的完整妥协的情况下。因此，我让他们选择一个密码，并将其发送到应用程序之前加密客户端上的数据。他们可以用自己的用户ID检索它们的加密数据。嗯，这听起来不是很安全，我可以下载任何人的加密数据和针对它运行脱机攻击。因此，让我们有他们与他们的密码访问自己的加密数据（我不希望他们一定要记住两个不同的密码）。但是，这并不好，因为我有自己的密码，然后以解密他们的数据。所以，一个简单的办法就是将他们的数据与自己的密码进行加密，并将其发送到服务器与他们的哈希密码，因为它在答案正确地指出是新的密码尽可能的服务器而言沿（所以服务器应该存储它再等等）散列一次。但是，服务器无法解密客户端的数据，因为它永远不会有原来的密码，但只有有效的人可以下载甚至其加密的东西，他们只需要记住一个密码。 （请注意，这是一个非常简单的模型，在现实中，更多的是需要的，例如像一个适当的密钥导出函数，不只是简单的哈希值，但这是另一个，更长的故事。）
不要误会我的意思，我不是说你一般应在客户端上散列密码 - 不，对方的回答是正确的在这方面。我只是想表明，正是客户端的密码哈希是一个有效的选项中至少一个使用情况。见著名密码管理器，一些工作类似。