'Open Sesame!' (or: Why strong passwords fail)
Q: Huh ? Where is this coming from ?
A: A little while ago, I had a friend visiting at home. During a conversation, I wandered over to my computer to look something up. Being a good little PC user, I typed in my password, searched, found what I was looking for and locked my workstation again. When I turned around, my visitor was giving me a rather odd look and asked me why I had such a long password on a computer I only used ? I explained to him that though it was not likely that anyone else would gain physical access to the machine, I didn't want to take the risk; after all, just because something is unlikely doesn't mean you don't need to anticipate on it. He nodded and mentioned that it was a good practice to have, and then added that he'd probably forget a password that long. After he left, I pondered upon his statement for a while and put it into perspective with my work. What you will find here is the thoughts that occurred to me during this train of thought.
Q: Okay, fair enough. Ehm. What exactly is a 'strong password' ?
A: Good question. A strong password consists of more than 7 characters, contains uppercase and lowercase letters, numerals and symbols.
Q: Ah, I see. But.. why ?
A: That is also a good question, however, the answer is going to be a bit longer than you might have hoped for. Therefore, I'd like to split up the question in two parts. First of all, why does a strong password consist of more than 7 characters ? As you may or may not know, passwords are often encrypted using encrypting algorithms. The point of this encryption is to ensure the passwords are not stored somewhere in plain text for everyone to read. In a very basic explanation, the algorithm uses the password as its input and gives an output that is complete and utter gibberish. For example, let us presume that we have '12345678' as a password. As you can see, this is not a very strong password, only satisfying two of the 5 criteria for a strong password (being more than 7 characters long and containing numerals). However, it will do nicely as an example.
Supposing we let loose a popular encryption algorithm such as MD5 on this password, the output we'd receive would look like this:
25d55ad283aa400af464c76d713c07ad
Brilliant! Our not-so-secure password has changed into a completely illegible piece of gibberish! This piece of gibberish, by the way, is what we call a 'hash'.
So what happens when we create a password on, say, a webserver ? The moment we create the password, the server uses an encryption algorithm such as MD5 to create the passwords' hash and stores it on its harddisk somewhere nicely secure and snuggly. The next time we log onto the server and enter our password, the server once again runs the encryption algorithm to create the hash of the password we've just entered and compares it to the hash that's stored locally. If the hashes match, we're validated and good to go. If not, well, try again.
Now that you see how the hash is created and how passwords are compared, let's move on to the next bit: why a password longer than 7 characters ? The best way to illustrate and explain this is .. another example!
Let's presume we didn't create a password that was longer than 7 characters, but instead uses 6 characters, such as 'abcdef'. Again, not a very secure password. Thankfully, we have encryption to hide this ugly fact from the world. Here we go. This time, we will be using the LANMAN hash, an widely supported algorithm that was often found in, for example, Microsoft NT networks.
When we give our present password 'abcdef' as input to this algorithm, we are given a nice hash in return:
13D855FC4841C7B1AAD3B435B51404EE
Looks pretty cryptic, huh ? Let's try another one! This time, let's make it a bit stronger though. Let us feed the password 'S3cr3t!' into our hungry little algorithm and see what we get:
FB6C29B505EF316AAAD3B435B51404EE
Still cryptic as hell! But.. wait a second.. what's this ? What is this disturbing similarity we are spotting at the end of our hash ? Why.. yes! The final 16 characters of our two hashes are identical. That must be a coincidence, right ? Wrong. It's not. LANMAN divides the password into two blocks of 7 characters, runs the algorithm on the separate blocks and pastes the outcomes together into the hash as you can see above. Now, as we used passwords that didn't use more than 7 characters, the second block of the password was blank. As LANMAN isn't the brightest grape in the bunch, it doesn't take much notice of the fact that one of its two variables is blank, and returns the value for 'blank', being 'AAD3B435B51404EE' and adds that to the outcome of the first block.
Let us now presume that we are a malicious hacker that has gained access to our webserver's harddisk. Any trained digital criminal will swiftly locate the hashes and glance at them. Recognizing the notorious blank LANMAN hashblock, he will be cheer in triumph, realising he has located an account that is only 7 characters or less! That'll dramatically increase his changes of bruteforce cracking the password, as the amount of possible combinations for a password with 7 character or less is at least much less than that of a password with more than 7 characters.
So, there you have it. That is why a strong password has more than 7 characters. Naturally, not all algorithms make the same 'mistake' as LANMAN does, but because you can't always tell what algorithm will be used to store your password, the minimum of 7 characters is a good general guideline. If you don't believe me, feel free to try out some passwords and hashes of your own. You will find a lovely little hash calculator on http://www.securitystats.com in the Awareness Tools section.
Q: I really wish I hadn't asked that question.. please tell me you don't have a similar answer to the part of upper- and lowercase characters, numerals and symbols question.. please ?
A: Rest assured, this part is much easier to answer. Actually, it's very easy. Imagine 'a character'. Now, in the normal alphabet, that could be any of 26 characters (for the standard English alphabet). If we were to make a password that consisted of 5 characters (which we wouldn't, of course, as we've just learned that that is a big no-no, haven't we ?), that would mean there is a grand total of 11881376 combinations we could make! Wouldn't that make our password hard to guess ? After all, trying that many combinations ? It'd take an attacker ages, right ? Right ?
Wrong. Attackers aren't stupid, you know. Fully aware of the amount of combinations, they have created various tools that allow so-called 'brute force'-attacks. These tools will just enter all the possible combination into, for example, the loginscreen of our webserver, till the hash of the password matches locally stored hash. Considering the specifications of modern machines and the intelligence of attackers and their tools nowadays, it wouldn't take very long at all to brute-forcecrack a password with that many combinations.
So, what we do is expand the number of possible forms a character can take by distinguishing between uppercase and lowercase letters. We also introduce numerals into the array of possibilities, and symbols. This increases the amount of combinations a 5 character long password can have dramatically, thereby increasing the time required to brute-forcecrack such a password. Simple.
Q: Okay, so that's a strong password. But the title of your article mentions 'Why strong passwords fail'. Why do they fail ? After all, this looks pretty damn secure to me!
A: It is pretty damn secure, yes. And anyone with a technical background can see how this form of passwords can protect valuable company information from falling into the wrong hands. All you have to do is make sure everyone uses strong passwords!
Q: Yeah! So what's the problem ?
A: The problem, very often, is this: Suppose you, as the administrator of your network, have decreed that from now on, strong passwords will be used on the network! Active Directory password policies will allow you to technically enforce this. Users logging into the domain are confrontated with a nice little dialog box that asks them to change their password. The dialog box will keep returning with an error until the user enters a password that matches the so-called 'complexity requirements', i.e. the criteria we mentioned earlier for a strong password. The first time this happens, users will be annoyed. The second time, they shall curse loudly. The third time, they will probably attempt to hunt you down with a splintery stake. If you're lucky, they will succeed into creating a strong password! As you can imagine, the amount of frustrations and complaints will grow and grow with every user having to think of a strong password. Before you know it, your manager (the same manager you convinced of the importance of strong password usage) will call you to say that though he understands the importance of password security, this simply will not do and that this strong password-silliness better be turned off in the next 15 minutes, thankyouverymuch. And we're back to the passwords consisting of 4 characters (year of birth, day and month of birth, name of significant other, etcetera, etcetera). And the Gods Of Security looked down upon the hapless administrator and smote him mightily.
Q: Hah! That won't happen to me because I'll make sure everyone understands the need for these passwords, or at least make sure my manager doesn't budge under the pressure!
A: Good for you! May I then now direct your attention to the little yellow sticky notes that suddenly appear on every monitor throughout the company on which something that.. well goshdarnit.. seem to resemble something very similar to a strong password..
Oh no! It seems that even though people understand the need for these passwords, they're having trouble remembering them and have written them down. Oopsie. Right. Back to the drawing board. Where did you go wrong ?
Q: I dunno. Where did I go wrong ?
A: You were doing so well. Very well even. Having created awareness of security issues at different management layers and making people understand the need for strong passwords. However, you've failed to give them a final tool.
Strong passwords will be quite complex and therefore hard for people to understand. And if you have to type it in 20-30 times every day, the chances of typos and account lockouts will be high. The only way to prevent this from happening is to ensure that people create strong passwords they can easily remember.
Let's say, for example, I'd like to create a strong password. As I only have very limited imagination, I'll start with my own name. That would give me the password 'Paul'. Not very strong yet, right ? Nope. What else do we need ? We've got uppercase and lowercase characters, so that's a very decent start. But we still need numerals, symbols and more characters. Hey.. what about my year of birth ? Let's add that to it, shall we ? That would make my password 'Paul1980'. Brilliant! We've managed to make a password with uppercase, lowercase and numeric characters! And it's also longer than 7 characters! What does that leave us ? Right, symbols. As I have very little imagination, this is tricky! What to use, what to use.. wait! I've got it. I'm using this password at work, right ? So.. why don't I add '@work' to my present password ? That's easy to remember and fulfills our final criteria!
There we have it. My password Paul1980@work is strong and easy to remember. Nor did it take much imagination to make. Suppose I want to change it later on ? I could capitalise my entire name, or use my day and month of birth instead of the year.. still, easy to remember and easy to make up.
And that is what you need to give your users: Tips and tricks to create strong passwords that they can easily remember as well. Everybody happy ? Nope. You've just made a small group of bruteforce hackers very very unhappy. Good for ya!
Q: So that's it ? All my passwords are now virtually uncrackable ?
A: Alas, no. Even though the usage of strong passwords makes brute-forcecracking very difficult, someone who has personal information on one or more users of your network might actually have a decent shot at guessing their passwords. Therefore, make sure you don't give out hints that are too detailed. If I were to use the above example of password creation in a user manual, I'll happily bet you both of my kidneys that at least 25% of the users would have a username consisting of 'First name - Year of Birth - @work'. Any attacker gaining access to this user manual would giggle happily and set about guessing passwords. With quite a bit of success, possibly. One way to prevent this from happening is to give a huge list of examples or none whatsoever. Only you can judge the best way to communicate these tips and tricks to your users. Depending on the size of the company, a personal approach might be worthwhile.
Q: Soooooo. This, ehm, password cracking.. ehm.. how would that work then.. ?
A: An excellent question which I will happily answer! .. in a future article.