In Depth: Rehashing Passwords
[InDepth#5] It sounds easy to rehash passwords, but is it really that easy?
![In Depth: Rehashing Passwords](/content/images/size/w1200/image/fetch/w_2000,h_2000,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https-3a-2f-2fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com-2fpublic-2fimages-2fb5d5cc72-1060-4390-b388-4c2fa06909ce_928x680.jpg)
The most secure way to store a password is to hash it and store only the hashed password. This ensures the original password can’t be easily extracted, while still allowing you to compare a password provided at login time with a stored hash to see if it matches. Modern password hashing algorithms also include a salt and a work factor, which add extra layers of security to protect the original password from being extracted and compromised.
If you’ve ever worked on a legacy application, you’ll know the database is full of legacy data structures1, and passwords are no exception. Many legacy apps (and even some modern ones 😡) store passwords in plain-text, directly in the database. The next step after plain-text was to use MD5 and SHA1 to hash the passwords, which adds some obfuscation, but doesn’t offer much protection. Then we added salts in, to make it a bit harder to extract the passwords, and thus a multitude of custom variants of salted-hashed password algorithms. And now we’re up to algorithms like bcrypt and Argon2, which offer excellent password security with the right configuration.