Password Hashing vs Encryption for long term viability

Hi there,
I currently store all of our users passwords in our database using AES encryption with unique salt per user combined with a site specific encryption key.

I'm looking at increasing our security by implementing password hashing so that the users passwords are not stored in our database in a way that they can be retrieved if the database becomes compromised.

The issue that I am slowly realising is that once I implement password hashing I will most likely be unable to change algorithms in the future.

For example :
Originally people were told to use MD5 hashing on their passwords.

That became compromised/easily cracked so they started using SHA hashing.

That again changed and people were told to use the more secure SHA128, SHA256, SHA512 algorithms etc etc

If my users passwords were originally stored as an MD5 hash am I stuck using that forever?  Without access to the original password I'm unable to change to a newer hashing algorithm.

Before I hash my passwords and delete my encrypted passwords I would like to know how people handle the task of upgrading hashing algorithms?

Or should I stick to using encryption?
LVL 5
SoLostAsked:
Who is Participating?
 
Olaf DoschkeConnect With a Mentor Software DeveloperCommented:
A change of hashing means you have a grace period of allowing old and new hash checks. Since you have the password at time of login you can hash it with a stronger hash algorithm and then mark that users record to using the new hash.

Here's how that's ideally implemented in a situation with compromised user data: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Design_password_storage_assuming_eventual_compromise

One part of it says you better only allow the old hash login with a 2nd factor or secret question answer as in a password recovery process. You don't need that in case you're not recovering from a hack of the data, but it's a good idea to start implementing such mechanisms for future cases. You can make the transition quite secretly, but if you wish to accelerate the transition you may mail users to log in to make that transition, you obviously can't make it without their login, as you don't store the password.

With users logging in rarely, you might suspend their account and enforce them to go through password recovery. That could be done perhaps one week/month after the new hash is rolled out and the users still didn't re login.

Bye, Olaf.
0
 
btanExec ConsultantCommented:
It should be straightforward as long as you keep to security practices that
1) no password are stored in plain
2) no weak hash is used
3) strong passphrase enforced
4) second factor authentication used
5) password recovery and revocation verified regularly.
6) policy to govern the account and access right are checked and reviewed regularly
7) audit trail for account changes esp privileged user like admin is verified and available to alert on anomalous activities

Use of salt is good for hmac hashed password like the use of PKCS#5.

Use of SHA2 family is the Secure hash (there is already Sha3) as other has surface been very susceptible to bruteforce scheme.

You should stick with keeping strong passphrase, Sha2 family and ultimately second factor authentication will give you high assurance and deterrence against adversories.

You can check an EE article on atrong passphrase
https://www.experts-exchange.com/articles/18309/Choosing-an-easy-to-remember-strong-password.html
0
 
SoLostAuthor Commented:
Thank you, exactly what I was looking for.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.