I got to thinking about passwords last night because I couldn’t sleep and I wanted to clarify something. Many people have asked me, “If you use numbers and special characters add to the “hardness” of a password?”
Initially I say “No, but it adds to the key space” (key space is the total number of possibilities that an attacker must try). What I actually mean to say is “Yes, it does increase the “hardness” of the password (and increases the key space), but it is not strictly necessary to use.”
One of the tips I like to use is to create a password that is composed of several words that you like or are particularly memorable. For example, you could probably look around your office or home and do this. Looking around me, I could choose projectorchocolateglobemarker (you could choose something else that is easier to remember and I probably would too, but this is just an example).
Consider this: if a password was composed of lower case, upper case, numbers and special characters, that would be 72 characters to chose from. If your mean system administrator said that your password had to be composed of 8 characters combining those 4 types of characters, then the total number of combinations would be ~7.22 x 10^14 (assuming a password length of 8 characters). That’s a lot of possible combinations a cracker/hacker must try!
Now consider the password where I ran the words together (projectorchocolateglobemarker). This would be resistant to a dictionary attack. A dictionary attack uses a targeted technique of successively trying all the words in an exhaustive list called a dictionary (from a pre-arranged list of values). Commonly, these pre-arranged lists are actually words from a dictionary because people are lazy and they will make their password is easy to remember (not through any fault of their own but humans are notoriously bad at remembering things that doesn’t make sense or they have no connection to). While those individual words (projector, chocolate, globe and marker) would all be in the dictionary, the concatenation of them would not. While we have fewer total characters to choose from (26 lower case characters), the total number possible combinations for the password would be orders of magnitude larger. In fact, it would be ~1.052 x 10^41. That is a much larger key space!
Now, if you haven’t glossed over by now, consider a computer that could do 1 key attempt per microsecond (which is certainly not out of the realm of possibilities), that is about 1 million key attempts (to crack) per second. The first password would take 722M seconds (22 years), the second would take ~10^27 years. Clearly, we can see which is more secure (and I didn’t need a lot of characters to do it). These longer, harder passwords, are also more immune to what we call “rainbow table” attacks.
A lot of the password stuff is what is called “security theater.” Security theater is a term that describes security countermeasures intended to provide the feeling of improved security while doing little or nothing to actually improve security. Having a system administrator create policies that don’t make sense (such as the crazy combinations of letters, numbers, special chars) when the password is far less secure is an example of security theater. Bruce Schneier uses it a lot to describe TSA security.
Another way to create a memorable password is to think of a memorable phrase such as “my sister likes to eat juicy orange every day”. Then, take the first letter of each word and combine them to make your password. In this example, your password would be msltejoed.
Lastly, I wanted to mention one last tip. If a user could setup a policy that would lock out after a certain number of failed attempts, such as 3, this is the most secure way to do a pass-worded system because it wouldn’t allow an attacker to do a “brute force” attack where they try all the different types of keys.
« Licensing Module in Java Slides from February Colorado Springs iOS Developer Meetup and Colorado Springs March Cocoaheads »
Besides using a counter of consecutive failed attempts, which would be reset to 0 after a successful login, you may want to use a second counter of total, non-consecutive failed attempts and ask the user to change the password after it reaches a higher threshold, say 30. See Protecting a Multiuser Web Application against On-Line Password-Guessing Attacks.
Francisco, thanks for the tip. I will definitely check out your whitepaper!
A couple of thoughts: One dictionary attack would be simply to try all the words. Pretty easy. If that fails, try all combinations of two words, and so on. With some case variance, that makes for pretty weak passwords–there are more words in the dictionary than letters in the alphabet, but it’s the exponent that counts, and N^x, where x<8 is weak. So you really do need to change the case of a few letters to make this better.
Second, lockouts are good, but one way hackers break passwords is to sneak in and grab the password file, and then have at it until it's broken. So, while lockouts are good, you're counting on the administrators never getting the file.