How passwords are stored securely
Password Storage
We’ve all been there, you need to type in your password to a website you haven’t used in three years and now you can’t remember what your password was. Then you have to go through some tedious process of clicking “forgot password” and then waiting for an email.
When you submit your password to a website, they need to store that text somewhere to allow you to log in again in the future.
You are wondering why the company does not simply email you back the password. After all, if they are storing it, they must be able to send it back instead of forcing you to create a new one.
Plain Text Passwords
Suppose a company stores all their users’ passwords in plaintext. If they ever were to suffer a data breach or if a rogue employee decided to take a peek at the database, all the passwords would be just there for them to take, even if you created the strongest password in the world.
If a website ever emails your password to you when you forget it, you should immediately stop using their services as they are not following basic security guidlines and you should that you are not using that password anywhere else.
The Solution — Hashing
“So how do they know I typed in the correct password?”
The answer is simple, they use a process called hashing to obfuscate the password before storing it. This is a process of using an algorithm to convert a message (in this case, a password) to a hash (a fixed length of random characters). Hashing is a one-way algorithm meaning it is impossible to figure out the original input message using just the output hash. There are many different hashing algorithms such as SHA1, MD5, SHA256, SHA512. The current standard is SHA256, Secure Hash Algorithm — 256 bits. For a 256 bit algorithm, the output hash is 64 characters long. Theoretically, having a longer hash would make for a more secure algorithm.
Here is an example of a password being hashed using SHA256:
Take the below modification and compare with the above:
Every time you run the hash algorithm on an input it will produce the same exact output hash; however, making the smallest change to the input message can result in a dramatic change to the output hash.
You can try this out yourself at any SHA256 Hash Generator
Why Hashing is Insufficient
Unfortunately, while this sounds like a perfectly good solution, there is an issue. Imagine if this person had access to the whole database and saw 500 accounts who had the same hash; same hash — same password.
Rainbow Table Attack
An attacker can use something called a rainbow table, a database of pre-computed hashes mapped to their corresponding input strings. They can simply search through this database and find the desired hash, pointing them to the original password. This is one reason that using common, simple, unoriginal passwords such as “12345678” and “password1” is unadvisable.
Hashing + Salting
So we know that hashing on its own is insufficient, and that’s where salting comes in. A salt is a randomly generated, fixed-length string that is unique for each user. Now, the salt is appended to the end of the password and fed to the hashing algorithm, producing a unique hash every time a new password is created. This means that if even if two users have the same password, the hashed outputs would be different.
The next time you go to log in to that website, the website can simply re-hash the inputted password with salt, then compare the output hash to the one stored in their database, and if the two match you will be granted access.
Conclusion
I hope this post serves as a good point of understanding for the underlying techniques used in securely storing passwords.
Look out for another blog post where I will explain everything you need to know about passwords in general.
