Everyone and their dog has probably seen password rules before. The annoying little notice that says, “you must have …” and then goes on to list a litany of criteria, all in the name of making a password “more secure”.
Tonight I ran into this with GitHub, and I’m finally pissed off enough that I’m going to say something about it:
PASSWORD RULES SUCK.
There, I said it. I’m sure some wannabe security “expert” is out there right now flipping his shit, but the above is simply true. This post details why.
Password rules do nothing to enhance security.
The idea behind establishing a litany of criteria for a password, such as, “you must have at least one uppercase letter, one lowercase letter, one number, and one special character” is that with a non-dictionary based password (i.e., a bunch of gibberish), it wouldn’t be all that easy to brute-force and crack.
However, people who need this kind of “enforcement” in the first place are, by definition, ignorant about security. If you understand security, you understand how brute force passwords work, and therefore don’t actually need this kind of hand-holding. Those who don’t understand how security works, or even understand the concept of brute-forcing a password, are likely to then write down the gibberish random password they’d have to come up with anyway. And the truth is, a password written down is every bit as insecure as a password that’s brute-forceable, because they can both be cracked through well known means (i.e. look at the paper or fire up your brute force cracker of choice).
On the other hand, those of us who don’t need this kind of hand holding get penalized. They say the best password is the one that not even YOU can remember. That’s bullshit - what’s the point of having a password if you can’t even remember it to use it? I say, “the best password is the one ONLY you can remember.”
But then we have this strange problem: how do you create a password that adheres to all the rules, is secure, and is memorable? Short answer: you don’t. If you do, you wind up entering it into a password manager or writing it down, and as mentioned above, that’s not as secure as something you can only keep in your brain (issues of kidnap, torture, or crazy trips on sodium pentathol withstanding).
How to create a GOOD password.
In my book, a good password meets these criteria:
- Far too long to brute force
- Wide variance of characters, including spaces and punctuation
- Multiple cases of letters
- Easy to remember
What meets all these criteria? A sentence. I’ve been a proponent of creating sentences and/or key phrases for passwords for several years, and I’ve never seen that philosophy steer me wrong. However, using password rules that disallow spaces, punctuation, etc. and force you to use letters, numbers, and !@#$%^&*() (which are not punctuation, but are considered “special characters” in most cases) inherently gimp your password’s security by limiting what you can input, thereby creating a situation where you are forced to use some bass-ackwards crazy combination of stuff that makes no sense, and therefore, requires you to memorize it or write it down.
“What’s wrong with memorizing it? You’re just bein’ lazy!”
Not necessarily. Consider, for the moment, the fact that most web applications have some form of password rules similar to what I’ve outlined here. Also consider that for real security, you need a different password for every single account you own. There’s no way any human being is going to be able to memorize several hundred weird crazy passwords like that. So what happens is that they usually figure out a password that tends to meet most criteria, then use it everywhere. The guys at LulzSec love people like this.
So, what’s the answer? Create a SENTENCE for a password that has something to do with the service you’re logging into. Rely heavily on personal interpretations and neuro-associations with the subject matter on said website, the more personal (and embarrassing) to you, the better. The reason for this is that the more personal/embarrassing your neuro-association to the subject matter at hand, the less likely you’ve ever told any other person about the event, action, mishap, thought or idea that occurred. And that’s what we want – total privacy that only you know.
In my experience, I can create a totally different password for each service I have an account with by creating a sentence-based password (when rules don’t bite me in the ass, that is) for each. It allows me to memorize passwords easily because I base my phrase or sentence off the name of the company or product/service they offer. I’m not copying their name into the password, or anything like it, but a concept that’s related. I find this works well for me because my brain has some VERY weird neuro-associations.
“Well, companies limit password length so they can save space in their database.”
If they’re doing this, they’re storing passwords DEAD WRONG – another thing guys like LulzSec absolutely love. Storing passwords using reversible encryption, or even worse, plain text, is one way to absolutely guarantee that said passwords will, with complete certainty, one day be divulged.
When storing a password in a database, the software doesn’t have any reason to try remembering what said password was, because it can calculate a cryptographic hash of that password – one that can’t ever be reversed – and simply store that hash. Then, when the user logs in again later, the password they enter is put through that same encryption process again, and then compared with the encrypted password on file. If the encrypted passwords match, the login is correct. Off by even the slightest bit, and it’s a total failure.
The truth is that once these passwords are stored in encrypted form, they’re all the same length. A password of one character (the letter ‘a’ for example) is just as long as a password comprised of the totality of War and Peace. The only difference is that the longer the password is, the more CPU cycles are spent on calculating the cryptographic hash to store and compare. However, in just about any case, a password the length of the average sentence (so, say, under 200 characters), is going to be just fine and won’t cause any serious impact with respect to application latency.
Which is easier to brute force?
Consider the following passwords: which is easier to crack?
- Now is the time for all good men to come to the aid of their country.
The first password is 8 characters long. If one assumes that each character can be UTF-8, the total number of possible combinations is (1,112,064 ^ 8).
However, as experience has shown, that’s usually not the case. Most of the time, passwords can consist of approximately these characters:
Depending on the service, others may be available as well, but in my experience, this seems to be the most common set.
Looking at this list, we see (26 * 2) + 10 + 9 = 71 characters. 26 (* 2 for both cases) for the English alphabet, 10 for digits 0-9, and 9 for the most common special characters. Spaces are not included.
Now that we have this new data, we can say that the total number of possible combinations for the first password is (71 ^ 8), far less than if all characters were allowed. Not only that, but chances are, a person forced into that kind of password system is going to have that password written down on a sticky note either attached to their monitor or in an adjacent desk drawer.
Look at the second password example. That sentence was a phrase my grandfather used to teach me how to type (on a typewriter) when I was a school kid in junior high. Assuming that the length of the password was between 1 and 200 characters, and any series of characters even in just the narrow (by comparison to UTF-8) character set of ISO-8859-1, we come up with (224 ^ 200) (assuming the reference for the ISO-8859-1 character table I looked at was correct). This goes even further – by far – if all characters under UTF-8 are fair game, which in my view, they should be.
“But without password rules, people would get hacked ALL THE TIME!”
That’s right, they would. Anyone who’s worked with end users (read: computer illiterates) knows that when it comes to security, the vast majority of them see it as a massive hurdle, thinking it’s just there as a formality to make their lives harder. Some go so far as to say, “oh nobody wants any of my account details – I’m not on the radar.”
I’m sure that’s what these people thought at one point in time, too.
The bottom line is that it’s going to take a serious security breach for people with this mentality to shape up. They don’t get it because they don’t want to get it – not because it’s all that hard. They aren’t paying attention and think, “oh it can’t happen to me”.
By coddling these users with password rules, we’re just delaying the inevitable, and not even doing a good job at it. Better to get it over with, let the user learn their lesson (since they haven’t been paying attention anyway), and stop burdening the rest of us who know better with “security” models designed during the Reagan administration.