I recently had a discussion about web app security and we were talking about the not-so-distant past when SQL-injection was the scariest thing since polio.  90% of these attacks didn’t try to return everyone’s credit card information from a database (people knew pretty early to be careful when storing this stuff), they were attempts to simply return a username and password.  

As a result, many people would go to a site that doesn’t need very much security (like a forum), and run some sort of sql-injection to return all username/password combinations from the database.  Then they would spend the whole day going from bank-website to bank-website, trying each and every one of these combinations (not only do most people use ridiculously simple passwords, they also re-use them for multiple sites) and they may get one login from one bank.  This could turn into several thousand dollars by draining that single account.  

Now, I know things have changed quite a bit, and bank websites have stepped up security standards a good deal.  I also realize that convincing people to be smarter about their login passwords would be a major challenge. However, I’m always shocked to find out that some web developers still store passwords in plain text in dB column called “password”.  

That brings us to one of the simplest methods for securing against password retrieval, that many people just don’t do. Now, there are many ways to secure against sql-injection, but let’s pretend for one minute that, somehow, someone gets the information in your database.  It doesn’t matter if it’s through injection, or getting your shared-host login from something, or someone having direct access to your server.  But let’s just say someone has your dB data, and they have all of the stored username/password combinations.  

The easiest thing to do is use a digest or hash for password storage.  You never actually need to retrieve this password, you simply need to compare a password against it.  By comparing the same hash of the input password against the stored hashed password, you are achieving the same thing. Your logins work exactly the same, except you have 4 extra lines of code.  

For another small method to improve security, add some secret letter/number/symbol combination to the word before storing/comparing.  Because most people have terrible passwords, if someone does get the information, they could get the passwords from sites that build dictionaries of MD5, SHA1, etc. combinations.  So by adding a small snippet to the end of the password, not only are you improving security against a dictionary attack, but you are differentiating this password from the user’s password that may be used some where else.

Most developers, I hope, will have learned nothing new from this article and will consider it quite obvious.  That’s a good thing.  But after hearing from a few individuals who still used plaintext storage of passwords, I felt as though this might help someone.