在将密码发送到服务器端之前，我应该散列密码吗？
我注意到大多数网站都通过HTTPS将密码作为纯文本发送到服务器。 如果不是我将密码的散列发送到服务器，是否有任何优势？ 它会更安全吗？
这是一个古老的问题，但我觉得有必要就这个重要问题提供我的看法。 这里有太多的错误信息
OP从未提及通过HTTP发送密码 - 只有HTTPS，但很多人似乎都回应了由于某种原因通过HTTP发送密码的问题。 这就是说：
我相信密码不应该以纯文本保留（更不用说传输了）。 这意味着不保存在磁盘上，甚至不在内存中。
在这里回应的人们似乎认为HTTPS是一颗银弹，事实并非如此。 然而，它肯定有很大帮助，并且应该用于任何经过验证的会话中。
真的不需要知道原始密码是什么。 所有这些都是基于用户选择的原始文本生成（并可靠地重新生成）认证“密钥”的可靠方法。 在理想世界中，本文应立即通过使用不可逆的盐对其进行哈希来产生“关键”。 此salt对于生成的用户凭证应该是唯一的。 这个“钥匙”将是你的系统用作密码的东西。 这样，如果您的系统将来会遭到入侵，这些证书只会对您自己的组织有用，而在其他任何地方用户都懒惰并且使用相同的密码。
所以我们有一把钥匙。 现在我们需要清理客户端设备上任何密码的痕迹。
接下来，我们需要将您的系统获得该密钥。 “绝对不应该传输密钥或密码”。 甚至没有通过HTTPS。 HTTPS并非不可阻挡。 实际上，许多组织可以成为可信的MITM--不是从攻击的角度来看，而是对流量进行检查以实施自己的安全策略。 这会削弱HTTPS，并不是它发生的唯一方式（例如重定向到HTTP MITM攻击）。 永远不要认为它是安全的。
为了解决这个问题，我们使用一次随机数散列密钥。 如果您需要多次发送密钥，则此次数对于系统中每次提交密钥都是唯一的，即使是在同一会话期间也是如此。 一旦它到达您自己的系统以恢复身份验证密钥并对请求进行身份验证，您就可以将其颠倒过来。
在这一点上，我永远不会将它永久存储在你自己的系统中，最后一次散列它。 通过这种方式，您可以与SSO等伙伴组织共享凭据，同时能够证明您自己的组织不能冒充用户。 这种方法最好的部分是你永远不会分享用户未经授权而产生的任何东西。
做更多的研究，因为它比甚至我泄露了更多，但如果你想为你的用户提供真正的安全，我认为这种方法是目前最完整的答案。
TL; DR：
使用HTTPS。 不可逆转地安全散列密码，每个密码都有独特的salt。 在客户端上执行此操作 - 不要传输其实际密码。 将用户原始密码传输到您的服务器永远不会“正常”或“良好”。 清理原始密码的任何痕迹。 无论HTTP / HTTPS如何，都使用一个随机数。 它在许多层面上更安全。 （对OP的答复）。
由于它是通过HTTPS传递的，因此发送密码而不使用散列（通过HTTPS它不是纯文本）绝对没问题。 此外，如果您的应用程序依赖于HTTPS来保证其内容安全，那么在通过HTTPS发送密码之前散列密码是没有用处的（例如，如果攻击者可以解密网络上的数据，则无论如何都会被拧紧）
不，实际上这会是一个漏洞。 如果攻击者能够从数据库中获取哈希值，那么他可以使用它进行身份验证而无需破解它。 在任何情况下，用户或攻击者都无法获得哈希密码。
散列密码的重点在于添加额外的安全层。 如果攻击者能够使用SQL注入或不安全的备份从数据库中获取哈希和盐，那么他必须通过暴力破解来找到纯文本。 John The Ripper通常用于打破腌制密码哈希。
不使用https是违反了OWASP Top 10：A9-传输层保护不足的情况
编辑：如果在你的实现中，你计算一个sha256(client_salt+plain_text_password) ，然后计算服务器端sha256(server_salt+client_hash) sha256(client_salt+plain_text_password)上的另一个散列，那么这不是一个严重的漏洞。 但是，它仍然容易被窃听并重播请求。 因此这仍然明显违反了WASP A9。 但是，这仍然将消息摘要用作安全层。
对于https的客户端替代者，我所看到的最接近的是JavaScript中的密钥交换中的diffie-hellman。 但是，这确实可以防止主动的MITM攻击，因此直到技术性违反OWASP A9。 代码的作者同意这不是HTTPS的完全替代，但是它比没有比客户端哈希系统更好，更好。
链接地址: http://www.djcxy.com/p/21559.html上一篇: Should I hash the password before sending it to the server side?