1

We have a user table where we store the user passwords. Now what we do is that we have a static salt, that we append to plaintext password and do a SHA-256 of the complete text and store in DB.

We have created this approach 5 yrs back. But now with so much computing power, is it safe to use SHA-256(With the approach I mentioned).

Or should I use any other approach? like HMAC? or anything else

Ankit Bansal
  • 157
  • 1
  • 9

2 Answers2

2

I had to do exactly this same migration some months ago on a production database.

We did that in two steps.

  • we added an extra password column that would contain the PKDBF2 hash in Crypt format
  • then we modified the login logic so that when a user logged in (and we received their plaintext password), if the PKDBF2 field was not NULL, the routine would verify against that. Otherwise, it would check against the old hash column, and - if the plaintext hash matched - insert the information into the PKDBF2 field.

Our users did not notice anything. After maybe a week we also sent a mailing to customers that had not an updated PKDBF2 hash requesting they log in, and update their information while they were at it.

What was noticed was that we also added updated password strength checks (if your password was not strong enough, or its hash had leaked and was available on online databases, a warning would be given and a password change was strongly suggested. If the password was not policy compliant, the change was not an option). Due to a mistake, the checks were added later, so the most assiduous users were able to slip by a potentially unsecure password. Nonetheless, they got hit with the update at the next mandatory password change six months later... the last ones are being processed now, I think.

After, if I recall correctly, six or seven weeks, at the end of July, about 70% of our customers were updated. At that point the logic was changed again and the old hash was disabled, the column dropped. People trying to log received a message that their password was not correct, or had been obsoleted, and they needed to apply for the "Recover password" button.

Then about 10% of customers, more or less, turned out to be "dead" -- they are currently scheduled for removal in accordance with privacy regulations. Those with no business recorded were deleted immediately.

LSerni
  • 22,521
  • 4
  • 51
  • 60
0

The purpose of salt is to make sure two users with the same password don't have the same hashed password. Never use fast cryptographic hash functions such as MD5, SHA1, SHA256, SHA512, etc. Stick with key derivation functions: Argon2, bcrypt, scrypt, or PBKDF2. There is no way you can recover old password then hash them again. Try forcing old users to change their password so you can hash them with PBKDF2 or Argon2.

QuynhVir
  • 1
  • 1
  • What about algorithm. Is SHA-256 fine or should we use SHA-512 or something else – Ankit Bansal Oct 23 '20 at 09:15
  • Salted SHA-256 is fine. What I would change is make the salt random every single time. – Áron Pop Adorján Oct 23 '20 at 09:45
  • "_Try forcing old users to change their password so you can hash them with PBKDF2 or Argon2_" as LSerni says in [their answer](https://security.stackexchange.com/a/239934/61744), you don't need to force them to change the password, you can re-encrypt the next time they log in. – TripeHound Oct 23 '20 at 11:21