1

I have big database with user and passwords in sha256 hash. Now I write new version and I want to use sha256+salt. Is there a way to convert same passwords with sha256 to sha256+salt and have no trouble with login?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Keepd
  • 21
  • 1
  • 1
  • 5
  • 1
    Just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iIterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use functions such as `PBKDF2`, `Rfc2898DeriveBytes`, `password_hash`, `Bcrypt` and similar functions. The point is to make the attacker spend a lot of time finding passwords by brute force. – zaph Mar 19 '17 at 20:38

2 Answers2

4

Surely it is a good idea to make your password hashes more safe, but using a salted SHA-256 is the wrong way to go.

Best practise is to use a password hash function with a cost factor, which allows to control the necessary time to calculate a hash. Good algorithms are BCrypt, SCrypt, Argon2 and PBKDF2. In another answer I tried to explain how the switch to a new algorithm could be done.

The problem with the fast hashes like SHA-256 is the unbelievable speed of GPUs, one can brute-force about 3 Giga SHA-256 per second with affordable hardware.

Arsenal
  • 333
  • 3
  • 15
martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
1

The way to salt and hash a password is to take the plaintext password, add the salt to it and THEN hash it. When you have an existing password database already sha256-hashed you don't have the plaintext passwords, and you can't easily get them back in plaintext once hashed (which is a good thing).

What you could do instead would be to take the passwords in their current form, sha256 hashed, add the salt and then hash them a second time - or better: many times, with better hashing algorithms.

The function to verify the password would then repeat those steps to check that the password is correct. Assuming the second hash is just sha256-hashing once to make the example clearer, though it's not sufficiently secure:

  1. step1 = sha256(plaintext_password)
  2. password = sha256(step1 + salt)

If you really want to avoid working on top of your existing hash you could create a new table of users where you process passwords in the new way from the beginning, and then gradually migrate user's passwords over to the new table as they log in with their plaintext passwords, and remove them from the old table.

A third solution could be to deactivate all the old accounts and require them to change their passwords before they can sign in again, via fx. e-mailing them a link to change their passwords.

Makes sense?

That said you will get more qualified answers at https://security.stackexchange.com . For instance I just found this question on why salt->sha256 hashing once is insufficiently secure, and another one here on how to process passwords for more secure storage.

miyalys
  • 433
  • 9
  • 20
  • Glad to help. I accidentally wrote `sha1` but I meant `sha256`, so updated my answer with that. Maybe I would've combined the first two solutions, so all the old users' passwords are better protected even if they don't login for a while, while gradually moving the user base to the new table as they log in, where the password is only hashed once. – miyalys Mar 19 '17 at 17:08
  • By the way you will probably get better answers at https://security.stackexchange.com . Fx. I just found [this question](https://security.stackexchange.com/questions/90064/how-secure-are-sha256-salt-hashes-for-password-storage) on how secure/not secure sha256 + hashing alone is, and [and another one here](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords?noredirect=1&lq=1) on how to securely hash passwords. – miyalys Mar 19 '17 at 17:23
  • 1
    The comment links and information would be better in the a answer along with a brief description of why just hashing passwords, even with a salt or twice is **not secure and should not be done**. – zaph Mar 19 '17 at 20:43
  • Good point. I've at least edited the reply to make it a bit more general to apply to better password processing for storage as well, while advising doing more than just sha256 + salt. Finally I suggest security.stackexchange.com in the answer itself now. – miyalys Mar 19 '17 at 21:49