John Vine

Password Security

Est. Reading Time: 6 minutes

With all the sites I’ve worked on and the databases I’ve seen, one of the most troubling trends I’ve found is a lack of understanding about password security. I’ve been startled to find that many sites use two way encoding algorithms (meaning the algorithm supports decoding the generated encoded hash into the clear text human readable password) and even directly storing passwords as clear text in the database. I’ve seen a clear misunderstanding of what passes for secure password requirements and I’ve seen passwords that are limited to a fixed number of characters. In light of all the recent cyber attacks that have successfully accessed and retrieved data from even the most seemingly secure databases, I think it’s important to put some fresh information out there about password

I’ll start by stating what should be the obvious: under no circumstances should you ever design a system that stores a user’s password anywhere in clear text. When I say ‘clear text’ what I mean is without encryption making the stored value look as if someone had just typed it. If someone sets their password to “P@ssword1″ before storing that value in any form of permanent or semi-permanent storage the password should be encrypted. There are a number of secure ways to encrypt passwords. This article is not meant to help you choose which algorithmic approach is best as that depends largely on your application environment. What is important is that you choose a one way algorithm. The reason for this is that it requires any brute force attack on the encrypted password to first identify what kind of encryption algorithm you use, then try to repeatedly encrypt their own password guesses and compare them against your value. With a two way encryption all they need to do is identify your algorithm and run the decryption algorithm to access all your users’ passwords. Many of the arguments I hear against these stricter and more robust practices focus on customer support such as “If my user forgets their password how will I remind them what it is?” The answer to that is simple. YOU CANNOT! Under no circumstances should anyone, including the user, not even a system administrator be capable of retrieving the user’s password. If a password is forgotten, reset their password and inform them what the new temporary password is and encourage them to reset their password as soon as they can assuming your system can’t force them to do so upon their next login. I cannot stress this enough: if anyone in your company can recover a user’s password, be it a system admin, or a set of logic in your application’s code, then any hackers who gain access to your database will also be able to recover your user’s passwords as well.

Another misconception I’ve seen proliferating around the industry is that passwords are more secure if they contain special characters. While this is true, it isn’t enough to ensure your users create unique and complex passwords. Over the years society, especially in IT communities, have been led down a password generation path that makes passwords harder and harder for people to guess, and easier and easier for computers to guess. Replacing your ‘L’s with ’1′s and your ‘A’s with ‘@’s will likely keep your little sister from guessing your password, but it only adds a few additional test cases for computers to guess before successfully cracking the code. It’s important to add these additional test cases for computers by allowing special characters in your password requirements, but it’s not enough. Similarly, most encryption algorithms worth their salt will already be case sensitive. This means that the computers will have roughly twice as many test cases to check in order to brute force your passwords, and while the variety in uppercase and lowercase characters in passwords won’t hinder computers in their brute force attacks (which already have to execute the additional test case) , do so will add complexity for human attempts to guess passwords. These steps will help protect your users from malicious cyber attacks (and improve your credibility as a trustworthy provider) but the most effective way of increasing password security is not only often overlooked, it is frequently prohibited by password “strength” metrics. Too often I have come across passwords that only require 8 characters or worse stile 6 characters. If you allow uppercase characters, lowercase characters, numbers, and the standard 10 special characters you have a total of 72 possible characters per character in the password. With a password 8 characters long that means there are exactly 722,204,136,308,736 possible password combinations a computer has to test. Before you go thinking that’s a lot, you should know that there are processors widely available capable of processing 10 billion combinations a second. If you don’t want to do the math I’ll go ahead and tell you that means a computer can guess each password in your database in 20 hours or less. If it uses a randomly generated password each time, it’s likely your passwords will be cracked in an average of 10 hours per password. By simply increasing your minimum password length to 10 characters you increase the computation time to guess all the passwords to 11 years per password. That’s right, 11 years. over a decade per password. By increasing your minimum to 11 characters the time it takes the most advanced computers to guess and compute your passwords increases to excess of 500 years. Three characters. Three additional characters is all it takes to increase the amount of time it takes to calculate a password well beyond the conceivable life of both your users and the hackers. The payoff is astronomical. By adding a few extra characters to your minimum password length, you ensure your user’s passwords well beyond the standard which banks adhere to (8 alphanumeric and special characters characters with at least one uppercase lowercase, and special character). The very worst practice I’ve ever seen is a length limit on passwords. If your user wishes to use a password that is 20, 30, or even 50 characters long your system should make no effort to stop them as it decreases their confidence in your security and to be candid it’s just rude.

I’ve covered a lot here but the two things that should be apparent if you intend to store passwords for your users is this: never use a bi-directional encryption algorithm, and the more characters you require for passwords, the more secure those passwords will become.