问题描述
我注意到，大多数网站发送密码作为服务器的纯文本通过HTTPS。是否有任何优势，如果不是那我发送的密码的哈希到服务器？难道是更安全？
I noticed that most sites send the passwords as plain text over HTTPS to the server. Is there any advantage if instead of that I sent the hash of the password to the server? Would it be more secure?
推荐答案
这是一个老问题，但我觉得有必要提供有关这个重要问题我的看法。有如此多的误传这里
This is an old question, but I felt the need to provide my opinion on this important matter. There is so much misinformation here
在OP从未提及在明确通过HTTP发送密码 - 仅HTTPS，但很多人似乎响应通过HTTP发送密码出于某种原因的问题。这就是说：
The OP never mentioned sending the password in clear over HTTP - only HTTPS, yet many seem to be responding to the question of sending a password over HTTP for some reason. That said:
我相信密码不应该以纯文本被保留（更不用说发送）。也就是说，不能保留在磁盘上，甚至是在内存中。
I believe passwords should never be retained (let alone transmitted) in plain text. That means not kept on disk, or even in memory.
在这里回应人们似乎认为HTTPS是灵丹妙药，它不是。这当然大大有助于然而，并且应该以任何身份验证的会话使用。
People responding here seem to think HTTPS is a silver bullet, which it is not. It certainly helps greatly however, and should be used in any authenticated session.
实在是没有必要知道原来的密码是什么。所有需要的是一个可靠的方法来生成（和可靠的重新生成）基于原文认证钥匙由用户选择。在一个理想的世界中，这文本应立即生成一个钥匙通过不可逆的盐哈希处理。到正在生成用户凭证该盐应该是唯一的。这把钥匙将是你的系统作为密码使用。如果这样，你的系统曾经在未来得到妥协，这些凭证将永远只能是对自己的组织有用的，无处其中用户已经懒惰和使用相同的密码。
There is really no need to know what an original password is. All that is required is a reliable way to generate (and reliably re-generate) an authentication "key" based on the original text chosen by the user. In an ideal world this text should immediately generate a "key" by hashing it using irreversible salt. This salt should be unique to the user credential being generated. This "key" will be what your systems use as a password. This way if your systems ever get compromised in the future, these credentials will only ever be useful against your own organisation, and nowhere else where the user has been lazy and used the same password.
因此，我们有一个键。现在，我们需要清理的客户端设备上的密码的任何踪迹。
So we have a key. Now we need to clean up any trace of the password on the clients device.
接下来，我们需要拿到钥匙到您的系统。你不应该发送中明确一个密钥或密码。即使不通过HTTPS。 HTTPS是不是坚不可摧。事实上，许多组织可以成为值得信赖的中间人 - 而不是从攻击的角度来看，但对交通进行检查，以实施自己的安全策略。这削弱HTTPS，以及（如重定向到例如HTTP MITM攻击等），这不是它发生的唯一方法。永远不要认为它是安全的。
Next we need to get that key to your systems. You should never transmit a key or password "in the clear". Not even over HTTPS. HTTPS is not impenetrable. In fact, many organisations can become a trusted MITM - not from an attack perspective, but to perform inspections on the traffic to implement their own security policies. This weakens HTTPS, and it is not the only way it happens (such as redirects to HTTP MITM attacks for example). Never assume it is secure.
要解决这个问题，我们用哈希一次过现时的关键。这个随机数是每一个提交关键是你的系统的独一无二的 - 即使是在同一会话期间相同的凭据，如果你需要多次发送。您可以扭转这种随机数，一旦到达自己的系统恢复验证密钥和验证请求。
To get around this, we hash the key with a once off nonce. This nonce is unique for every submission of a key to your systems - even for the same credential during the same session if you need to send it multiple times. You can reverse this nonce once it arrives in your own systems to recover the authentication key, and authenticate the request.
在这一点上我不可逆的哈希它最后一次前被永久地保存在自己的系统。这样，你可以与伙伴组织为SSO的目的之类的共享凭证的盐，同时能够证明自己的组织无法模拟用户。这种方法的最好的部分是你永远分享由用户产生的任何未经其授权。
At this point I would irreversibly hash it one last time before it is permanently stored in your own systems. That way you can share the credential's salt with partner organisations for the purposes of SSO and the like, whilst being able to prove your own organisation cannot impersonate the user. The best part of this approach is you are never sharing anything generated by the user without their authorisation.
做更多的研究，因为有更多的比连我都透露，但如果你想向用户提供真正的安全，我觉得这个方法目前这里最完整的答复。
Do more research, as there is more to it than even I have divulged, but if you want to provide true security to your users, I think this method is currently the most complete response here.
TL; DR：
使用HTTPS。
安全散列的口令，不可逆，每个密码独特的盐。执行此操作在客户端上 - 不传输实际密码。传送用户原始密码到你的服务器是从来没有OK或很好。清理原始密码的任何踪迹。
无论HTTP / HTTPS的使用一个随机数。这是很多在许多层面上更安全。 （答案OP）。
Use HTTPS.Securely hash passwords, irreversibly, with a unique salt per password. Do this on the client - do not transmit their actual password. Transmitting the users original password to your servers is never "OK" or "Fine". Clean up any trace of the original password.Use a nonce regardless of HTTP/HTTPS. It is much more secure on many levels. (Answer to OP).
这篇关于我应该把它发送到服务器端之前散列密码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！