使用带盐的密码散列的协议
我试图了解网络应用程序中需要发送哪些信息。基本上我有一个在网络服务器上运行的网络应用程序，一个数据库，其中有一个带有散列密码和盐的用户表，当然还有启用了javascript的网络客户端。
当用户在登录处登录时，在客户端输入用户名和密码。我想知道发送了什么信息。 Web 客户端是否以纯文本形式发送密码，还是使用 javascript 对密码进行哈希处理（不加盐）并发送哈希结果？或者客户端是否从服务器以纯文本形式获取盐，然后客户端发送已加密的密码+盐？
散列和加盐散列的最佳方法是什么？ MD5 可以作为哈希值吗？ hash(password_plain_text + salt) 与 hash(hash(password_plain_text) + salt) 如何比较，其中 + 是字符串连接？
I am trying to understand what information are needed to be sent in a web application . Basically I have a web app running on a web server , a database which has a user table with hashed password and salt , and of course the web client with javascript enabled.
When a user login at the login , the user name and password are entered on the client side. I want to know what information are sent . Does the web client sent the password in plain text ,or does it use javascript to hash the password WITHOUT the salt and sent the hased result ? Or does the client fetch the salt in plain text from the server , and then the client sent the hased password+salt ?
What is the best way to hash , and to hash with salt ?
Is MD5 ok as a hash ? How does hash( password_plain_text + salt ) vs. hash(hash( password_plain_text ) + salt ) , where + is a string concatenation ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当浏览器发送您提供的数据时，它发送的格式很可能符合与服务器通信的协议的 RFC 要求。
在 HTTP 连接的情况下，用户名和密码会以明文（即纯文本）发送到您的网络服务器。
在 HTTPS 连接的情况下，客户端发送到启用 HTTPS 的服务器（握手后）的所有内容都会被加密 - 一旦到达服务器就会被解密。无论您在服务器端使用什么软件堆栈，都应该透明地为您处理此问题 - 因此您将再次以明文方式处理数据。
无论哪种情况，您都应该始终对您存储的密码进行哈希处理。原因是在密码通过线路（即客户端和服务器之间）传输时不保留密码。原因是为了将密码安全地保存在数据库中——保守秘密的最安全方法就是不保留密码。
客户端上的散列根本不安全，因为它不仅暴露了您选择的散列方法，而且暴露了您的加盐机制（对于受损的客户端，还暴露了实际的盐值。）
至于散列的最佳方法......选择一种相当安全的散列算法（SHA 系列中的一种应该可以很好地实现这一点）和动态盐（每个用户都不同的盐，例如加入日期及其电子邮件地址的每个其他字母）。如果您想让它更安全，将哈希值哈希几次（数千次）。这样，即使您的整个数据库被盗，也需要花费大量的工作才能暴露哪怕一小部分密码，从而为重复使用密码的人带来一些严重的麻烦。
When the browser sends over the data you provided it sends it over in a format which most likely matches the requirements of the RFC(s) for the protocol it is communicating with the server over.
In the case of an HTTP connection, the user name and password are sent in the clear (that is, in plain text) to your webserver.
In the case of an HTTPS connection, everything sent to the HTTPS-enabled server by the client (after the handshake) is encrypted - once it arrives at the server it is decrypted. Whatever software stack you are using on the server side should handle this transparently for you - so you will be dealing with data in the clear again.
In either case, you should always hash passwords that you are storing. The reason is not to keep the password as it goes over the wire (i.e. between the client and the server). The reason is to keep the password safe in your database -- the safest way to keep a secret is to not have one to keep.
Hashing on the client side is not safe at all, as it exposes not only your chosen hash method, but also your salting mechanism (and, for a compromised client, the actual salt value.)
As to the best way to hash ... choose a decently secure hashing algorithm (one of the SHA family should do the trick nicely) and a dynamic salt (one that is different for each user, such as date of join and every other letter of their email address). If you want to make it more secure, hash the hash a few (thousand) times. This way, even if you should have your entire database stolen, it will take a significant amount of work to expose even a small percentage of your passwords, thus saving people who reuse passwords some serious headaches.
JavaScript 发送您告诉它发送的任何内容。如果您没有通过 JavaScript 显式对密码进行哈希处理，那么它们将以明文形式发送到对它们进行哈希处理的服务器。
不过，我认为在客户端进行散列并不是一个好主意，因为这会向任何查看您的 JavaScript 的人泄露您的盐。此外，未启用 JavaScript 的用户将无法登录。
服务器端的哈希值。
至于安全性，这没有什么区别。第二种解决方案使暴力黑客找到您的密码的难度增加了一倍（因为他们必须生成两个哈希值而不是一个），但只要没有人知道您的哈希值，您就不必担心这一点。
但如果您确实担心安全性，请使用 SHA256 进行哈希处理。 Google“md5 冲突”了解为什么 MD5 不是最好使用的哈希函数（它是最快的哈希函数之一）。
JavaScript sends whatever you tell it to send. If you aren't explicitly hashing the passwords via JavaScript, then they are being sent in plaintext to the server which is hashing them.
I don't think it would be a great idea to hash on the client side, though, as that would be revealing your salt to anyone who looks at your JavaScript. Also, users without JavaScript enabled won't be able to log in.
Hash on the serverside.
As for the security, it doesn't make a difference. The second solution makes it twice as hard for a bruteforce hacker to find your passwords (as they would have to generate two hashes instead of one), but as long as nobody knows your hashes, you don't have to worry about that.
But if you are really worried about security, hash with SHA256. Google "md5 collisions" to see why MD5 is not the best hashing function to use (it is one of the fastest).
如果您希望连接真正安全，请使用 SSL。如果您的数据不重要，请在服务器上散列您的密码。您可以在客户端上对其进行哈希处理，但您的哈希密码和盐无论如何都可能会受到损害，因此简单的密码可能会被破解。
If you want your connection really secure use SSL. If your data isn't critical hash your password on the server. You can hash it on client but your hashed password and salt might be compromised anyway, so easy password can be bruted.