将用户名和密码从客户端发送到服务器的正确方法
这个问题不是特定于语言的。 我很好奇如何正确地将用户名和密码从网站登录表单发送到服务器。
我的猜测是对密码进行哈希处理，将用户名/密码放入 POST 正文中并通过 发送HTTPS。有什么更好的办法呢？
为了更好地衡量，我将提到一个不太理想的方法：
http://www.somesite.com/login?un=myplaintextusername&pw=myplaintextpassword
This question is not language specific. I'm curious how to properly send username and password from a website login form to a server.
My guess is to hash the password, put username/password in the POST body and send it over HTTPS. What's a better way?
For good measure I'll mention a less than ideal method:
http://www.somesite.com/login?un=myplaintextusername&pw=myplaintextpassword
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
重要的部分是您在 POST 正文中传输表单数据（这样它不会缓存在任何地方，通常也不存储在任何日志文件中）并使用 HTTPS（这样，如果您有一个好的 SSL/TLS 证书，没有人可以嗅出）通过观察您的网络流量获得的密码）。如果您这样做，则对密码进行散列处理不会带来太大的额外好处，至少在传输过程中不会。
那么为什么人们谈论哈希密码呢？因为通常您不希望将用户的密码以明文形式存储在服务器端数据库中（否则受感染的服务器的影响比其他情况更严重）。相反，您通常存储加盐/散列表单，然后将相同的盐/散列应用于通过表单数据接收的密码，以便您可以比较两者。
有关加盐的更多信息，请参阅http://en.wikipedia.org/wiki/Salt_(cryptography)（以及那里的链接）。
The important parts are that you transmit the form data in the POST body (that way it's not cached anywhere, nor normally stored in any logfiles) and use HTTPS (that way, if you have a good SSL/TLS certificate, nobody can sniff out the password from observing your network traffic). If you do that, there is no big extra benefit in hashing the password, at least not during the transmission.
Why do people talk about hashing passwords, then? Because normally you don't want to store the user's password in plaintext form in your server-side database (otherwise the impact of a compromised server is even worse than it would be otherwise). Instead, you usually store a salted/hashed form, and then apply the same salt/hash to the password received via the form data, so that you can compare the two.
For more information on salting, see http://en.wikipedia.org/wiki/Salt_(cryptography) (and the links there).
如果您使用 HTTPS，则可以在 POST 正文中发送名称和密码，这样可以防止窃听（假设您信任 SSL）。您不需要对密码进行哈希处理，如果您这样做，那么密码哈希值与密码本身一样有用，因此它不会为您带来任何好处。
一个更重要的问题是如何在服务器端存储密码。仅当您使用良好的算法（例如 scrypt）时，才可以存储哈希密码。但这仍然不如 SRP 等高级协议。
If you're using HTTPS, then you can send the name and password in a POST body which will be secure from eavesdroppers (assuming you trust SSL). You don't need to hash the password, if you do then the password hash is just as useful as the password itself, so it doesn't buy you anything.
A more important question is how you store the password on the server side. Storing a hashed password is only acceptable if you use a good algorithm such as scrypt. But that's still not as good as an advanced protocol such as SRP.
您应该始终使用 HTTPS 并避免自制代码。 SSL 将负责散列和加密。加密。这是唯一安全的方法。
还要确保您在服务器端对密码进行哈希处理并存储哈希值，而不是原始密码。然后比较哈希值以检查登录情况。如果数据库遭到破坏，这将防止攻击者直接从数据库中读取明文密码。
You should always use HTTPS and avoid homebrewed code. SSL will take care of hashing & encryption. That is the ONLY secure method.
Also ensure you're hashing passwords on the server end and storing the hash, not the original password. Then compare the hashes to check logins. This will prevent attackers reading plaintext passwords straight out of your db if its compromised.