Today I'll be going over a way of how not to store your password, and how you actually should. Data breaches are becoming ever more common, and it can happen to anyone- even adobe had a data breach back in 2013. Unfortunately, they weren't storing passwords very securely, but if you follow how to store them the right way, you should be all good.
How NOT to store password
First off, I really stress. Please do NOT store passwords like this! This is just an example of a naive attempt: Storing the password in an encrypted format.
Although not the dumbest idea, it is certainly not as secure as it sounds. Its actually what adobe did prior to the data breach. What happens with this is you get the users password, encrypt it with the encryption key, and store the result in the database.
There's one fatal flaw with this problem, the private key. The private key is used to encrypt and decrypt all the passwords. Well, if you find it out, you can decrypt the password and all the passwords will magically appear in plaintext. The problem is, encryption is a two-way, reversible process. Good for most things, not for passwords. We want passwords to be unseeable, with an unreversible process. So lets talk about hashing (and salting), the right way to store a password.
Hashing and salting- The right way
Hashing is a one way, irreversible process. It takes a password, applies some special maths to it, then gives you the result. Here's a nifty diagram to show you what's happening.
This is amazing for passwords, as the hashed string can be linked to the original string, but it is impossible to obtain the original, plaintext password. However, just hashing the password isn't enough, so you should also use a salt, a random string. Many hashing algorithms do this for you, like bcrypt. The salt is very important, but why?
If you don't use a salt, you are vulnerable to a rainbow table attack. This is where someone has already worked out the hash for hundreds of thousands of passwords, which can be used to compare the hashes from your database. This essentially makes using hashing useless, which is why we use salts. Because the salts are random, in theory, there will be no rainbow table for the passwords. This means that now, even with a database breach, for example, your users' passwords should stay out of the eyes of an attacker. Below is a diagram to show you how the hash and salt works.
I'm not going to detail how to integrate this hashing and salting into your application today, as there is just so many different languages and algorithms to cover, although I will link a few modules which are commonly used to hash passwords. Please remember to use up to date tutorials, as things might have completely changed since this blog post was written:
There you go, that is how not to and how to store passwords from your users securely. Now if we have a database breach, we know our users' passwords should be safe. Thank you all again for reading. I hope you enjoyed this post. Please feel free to share this with your friends and I have no objections if you wish to reference this post on your site.
Want to get in touch? Go ahead, contact me via the methods on my site. Until then, bye!
Subscribe to The Daniel Gray Blog
Get the latest posts delivered right to your inbox