Salted password hashes

 

I am trying to create a login system for a web application, but I am stuck on a couple of points. I am storing the password in my database using a sha2-512 hash with a 128 bit random salt.

However I currently have the password posted in plain text to my application using a html form, both when the account is created and when the user logs in. I know this is wrong.

Do I need to hash the password in the client? If so how do I take into account the salt which is currently generated and stored on the database?

NOTE: I am doing this to learn not to use in a production system

Hashing the password on the client would require the use of the salt on the client. This also exposes your algorithm for very easy hacking on the client side. The best thing to do is to perform this action over SSL (HTTPS) so that the entire transaction is encrypted and the authentication only happens on the server.

Ie: Your user ID and password are transmitted encrypted from the client. The web server decrypts the data and passes it to your server-side authentication function where you look up the user and associated salt, perform password + salt + hash and compare it to the stored hash for a match. This means that the hash and then salt never need to be transmitted from the server at all.

The best bet is generally just to use SSL. If you did need to hash on the client side, this is how I'd do it:

  • When you first store the password, hash the password with a stored salt as is commonly done.
  • When someone needs to login, send them the stored salt, along with a second, randomly generated salt.
  • The client will hash the plaintext password with the stored salt, then the random salt and send the hash to the server.
  • The server will hash the stored password with the random used in that request salt and compare.

    • This is secure because it ensures that the hash being transmitted is unique to the request (it uses a single-request random salt), so a login cannot be faked in the future simply by sending the hash again. It is not dangerous to send the client their stored salt, as it is assumed that password crackers will have access to the stored salt (if they get access to the db). Two hashes are required to prevent you from ever having to store the password as plaintext.

    You should be using SSL to transmit the passwords encrypted so that a man-in-the-middle can't intercept the packets and read off what ever credential is being sent. Even if you pre-hash the password in the client, a man-in-the-middle can still just use that value to fake identity.

    What really concerns me, though, is the use of SHA-512. A lot of people use cryptographic hashes for password storage, but popular opinion misses a very important point: These hashes were designed to be fast. That is, one of the requirements to become an SHA (or similar) hash is to be able to quickly hash large documents on embedded hardware.

    This is the exact opposite of what you want for password storage, as it allows specialized routines on high performance GPUs to brute force passwords at a surprising and scary speed!

    This is why some purpose built password storage hashes have been developed. The one I have been using is Bcrypt, which is slow enough to keep out brute force attacks, adjustable to couneract faster hardware in the future, and has the added bonus of handling the salting for you.

    链接地址: http://www.djcxy.com/p/17880.html

    上一篇: 为什么我们在char数组而不是String中从控制台读取密码？

    下一篇: 腌制密码哈希