As one of our resident security guys, I thought I might write up a quick guide about what not to do with password management. As long as you build a website or web service, at some point you’re most likely going to have to store a password. Unfortunately for many developers out there (in organizations big and small), they are building a password management system that lends itself to become quickly and easily compromised.
So let’s talk about what not to do…
Storing a Password in Clear Text
This is probably the simplest approach to develop and so still actively used in a lot of different organizations by lazy or just plain naive developers. A user enters their username and password into the web interface. For the example below I’m using the username “alan.crouch@coveros.com” and the password “password123“.
[alertbox type=”error” ]On a side note: don’t ever use password123 as your password.[/alertbox]
On the backend, the developer stores the password in clear-text in a database, potentially setting up a database that looks something like this:
Advantages:
- Passwords are easy to check against.
- Very simple to develop.
- Giving a user their password is a simple task.
Don’t Do This Because:
If a malicious insider or an outsider can access your database using a security vulnerability, all the users’ usernames and passwords are now at their disposal.
Before you say this doesn’t happen anymore and no one does this… look here or better yet here.
[alertbox type=”notice” ]If a website can provide you your password in cleartext (either over the phone or via email) they may be using this strategy.[/alertbox]
Encrypting a Password
This is probably the next easiest approach to develop and you will find it being used by lots of well known organizations, like Adobe. In this situation we would take our password and encrypt it with a key we know. All passwords would get encrypted with a common key and stored in the database. At any time we can use that key to decrypt the data. So our database begins to look something like this:
Advantages:
- This is more secure than clear-text passwords.
- Moderately simple to develop.
- Passwords can be decrypted and given back to the user.
Don’t Do This Because:
If someone gets your key, or leaks it…well, you’re screwed.
This strategy also easily identifies which users have the same password which can help you determine which users are using fairly common passwords, because the same password is encrypted with the same key. Crack one, crack them all.
Unfortunately, even large, well known corporations are using this strategy.
[alertbox type=”error” ]Adobe also kept their password hints in clear text in the same table as their passwords. Not such a great strategy. Separate your password hints in a different table, at a minimum. [/alertbox]
[alertbox type=”notice” ]If a website can provide you your password in cleartext (either over the phone or via email) they may be using this strategy.[/alertbox]
Storing a Password Using a Hash
This is probably the next moderately easy approach to develop and you will find it being used by a ton of organizations. Hashing simply takes a password entered and converts it to a set of random characters. For example, using our example of “password123” would become “482c811da5d5b4bc6d497ffa98491e38” using a well-known hashing algorithm like md5. So our database begins to look something like this:
Advantages:
- This is more secure than clear-text or encrypting passwords.
- Moderately simple to develop.
- Passwords can’t be decrypted.
Don’t Do This Because:
Using tools like rainbow tables, a malicious person can find your password by simply typing comparing the hashed string to the known passwords. Since we know that users tend to use bad passwords, a malicious person can typically find a common bad password pretty easily.
Another reason you wouldn’t want to do this strategy is that you can tell which users have the same password or fairly common passwords since all the hashes for one password come out the same. So if you find a common password in your rainbow table, you’ve compromised more than just one account.
Lastly, many hashing algorithms have been cracked and can take a matter of seconds to crack any password using that hash. Make sure you do your research and choose a strong hashing algorithm that hasn’t been compromised.
People don’t do this right? Think again.
[alertbox type=”error” ]Don’t use SHA-1 or MD5 hashing algorithms, unless you are trying to make it easy for a hacker to compromise your password database.[/alertbox]
So What Should You Do?
Well, the current best strategy is to use Hashing and Salting to create an un-decryptable one time hash of a password plus some random string, known as a salt, to create unique hash strings for each password (even if the passwords are identical). This way the only way to crack your user’s password is by brute force.
[important]Check out a recent, reputable tutorial to find the best strategy if you need to implement a password database on your system.[/important]
