In Depth: Rehashing Passwords
[InDepth#5] It sounds easy to rehash passwords, but is it?
To finish off our focus on passwords, today we’re going to talk about Rehashing Passwords!
I find this topic fascinating because on face value is sounds so trivial, as evidenced by the fact I tried to write a quick tip on it and quickly realised it needed an In Depth, but it’s really not trivial. The way you handle rehashing passwords depends on a number of factors, and this is something every developer needs to learn about.
How to Rehash Passwords Safely
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.
Before we get stuck into hashing and rehashing, I put up a poll on Twitter asking what sort of hashing people use in their apps. If you’re on Twitter, can you please quickly jump over and add your vote before continuing?
What Is Hashing?
Keep reading with a 7-day free trial
Subscribe to Securing Laravel to keep reading this post and get 7 days of free access to the full post archives.