If you store your users’ passwords in plain text, life is easy for you, and its equally easy for someone to steal them. If someone manages to login to your database; if someone makes a successful SQL-injection attack; if the next developer on the project, or that contractor you hired for a week to optimize the database, are less trustworthy than you…any of these scenarios could compromise every one of your users’ accounts. And maybe users can’t hurt anything on your site, but unfortunately, people often use the same password for your site that they use for their e-mail account, etc. So, if someone gains access to your users’ usernames and passwords, they can potentially access those users’ e-mail, bank accounts, amazon accounts, facebook accounts, etc. So, just don’t do it. This is the first and most sacred rule in handling your users’ passwords. You should treat passwords as carefully as you would credit card details and social security numbers. I don’t care what your reason is for storing passwords in plain text…your reason is not worth the risk to your users, and there is always another way to do what you are trying to do. There is NO valid reason to store a password in plain text.
Additionally, you should ALWAYS store the password using a ONE-WAY hash, and that hash must be salted as pointed out in Why You MUST Salt Your Hashes. A one-way hash is NOT “encryption”. A password that is encrypted can also be decrypted. If you store a password using the very secure AES-512 encryption with a key that is stored carefully in your source code in a protected folder that can’t even be accessed from the web at all…it may seem like the passwords are safe, but they aren’t. Ask yourself, would YOU, the developer, be able to decrypt the passwords? If YOU can do it, then so can someone else. Remember, the next developer, or that contractor, may not be as honest as you are. My goal, and your goal, should be to make it impossible for anyone, including yourself, from being able to access the passwords.
I can hear the comments rolling in before I’ve even posted this about how you NEED to have the password encrypted so you can decrypt it, because you have to use the password to login to some other legacy system from your system, and that other system requires the password. Well, okay, if you don’t control another system, and that system was designed poorly, then maybe–just maybe–there is a valid reason…but that’s about the only reason I can think of. And there is still no excuse to store it in plain text.
Now, there is a lot of information out there saying to not use MD5 and use SHA256 instead. This is only mediocre advice. SHA256 is definitely safer than MD5. However, SHA256 is still a “fast” algorithm. While my quick tests show that it would take my computer hundreds of years to crack an 8 character password through random brute-force methods, I have heard reports of a custom 25 GPU system that is able to do 22 billion hashes per second with SHA256, which means an 8 character password could be brute-forced in a few hours. So, it is important to use a “slow” hashing algorithm.
Based on some quick, incomplete research it appears that the most common or talked about algorithms that do “slow” hashing are:
Among these, it seems that bcrypt is the most trusted, while scrypt might have some good future promise but doesn’t have as much software support from what I could find. These algorithms work by hashing the password thousands of times with configuration options to increase the number of rounds as computer processing speeds up. Forcing the password to be hashed thousands of times to get the end-result will only take a couple-hundred milliseconds when the user types in a valid password, so it’s barely noticeable to the user. However, to the person trying to brute-force the password, it becomes expensive in terms of time and financial cost of processing power.
So, pick a slow hashing algorithm and hash your passwords with a salt. It’s the only way to truly protect your users’ information to the best of your ability. Your users will never know how grateful they really are, but you’ll also never have to tell them about a compromised password if your database table gets leaked.
Kevin Nelson February 6th, 2015
Posted In: Security