Tuesday, February 02, 2010

The Password Policy Fallacy

Greetings!
As I am shutting down my mostly inactive blog, I'll start my guest blogging career by reposting the few blog posts I made there. Here goes...


Dilbert.com

Well, that was funny! At least I thought so back in 1998, when I first saw that Dilbert strip. Like many others, I thought that there was no way we would ever subject ourselves to such a complex and draconian password policy. Little did we know then, that 11 years later, the brutal reality is that we wish our password policies were that simple.


What's a good password, anyway?


Someone said: A good password must be impossible to remember and must never be written down. 
As admirable as that goal may be, it's also slightly impractical. If we had the chance, we'd all have blank passwords on our accounts, or at least a statistically significant portion of us would. All kinds of people, heavily armed with anecdotal evidence and equipped with fatally flawed logic, have set out to create policies that dictate the complexity of our passwords, no doubt to protect us from ourselves.

Lately, a colleague of mine, who is passionately interested in all things password related, has been exposing me to plethora of different password policies, and the resulting passwords. Here are a few of the more common rules found in those policies:

The Password must be 8 characters or longer (in some very rare cases, the number is 15).
Okay, that kinda makes sense. The longer the password, the harder it is to brute force. Except on Windows, where it's just as easy to crack a 14 character password as it is to crack a 7 character password, but not a 15 character password. Because that's monumentally more difficult to crack, except when it isn't: The previously mentioned colleague of mine cracked my 38 character password in 2 days flat. If your dictionary is big enough, you can crack anything.

The Password must contain a mix of lower and upper case characters, and digits or special characters.
Again, kinda makes sense, or at least it used to before somebody mainstreamed hybrid dictionary attacks, which was what, 10 years ago?

The Passwords must not be (or contain) the user id or the real name of the user.
Well, this one actually does make sense in a Duh! kinda way. It's right up there with password must not be blank. Which of course no one in their right mind would do. Or would they?

The password must be changed every 3 months, and must not match a previous password.
Again, sorta makes sense, but the thing is (and I'll be talking some more about this in a later blog post) that people seem to love patterns. If you enforce periodic changes like that, along with restrictive rules about password length, format and content, you'll inevitably end up with passwords like Spring09, Summer09, Autumn09, and so on. Care to guess what the next password will be?


So far, so good?


In actuality, all the previous rules are technically possible to implement, and it's also possible to measure the compliance level. But it never ends there. As the brainstorming session drags on, and coffee and do-nut deprivation sets in (they ran out hours ago), somebody's bound to go "man, we've only got a 3 line password policy, there must be more we can put in there to make it look like we've actually done something!"
And this is when rules like these start showing up (notice how they're always at the end of the policy, never at the beginning):

The password should not be a word written backwards.
You know, I've never actually seen a password containing a word written backwards. Does that mean the rule works, or perhaps that nobody ever did that to begin with?
The password should not contain personal information that can be related to the user, such as name, social security number or phone number.
Hi! I am Mordac, the preventer of information services. Please enter all the personal information you can think of into this database, so that we can check against it every time you change your password. Oh, and keep it up to date forever.

The password should not be found in a dictionary.
Uhm, quick question: Which dictionary is that? The Merriam-Webster English Dictionary? Cassell's Dictionary of Norse Myth & Legend? The Oracle Data Dictionary? Or perhaps this 53 million word dictionary I just found on the internet? Actually, that last one wouldn't be such a bad idea...

A password should not be a common combination of characters, a word or a common combination of words found in dictionaries, or that is commonly used in a spoken language, regardless of language.

Yes. You read that correctly. Not only would they have you check all the worlds dictionaries, but also all the worlds spoken languages. Did I mention that there are nearly 7000 spoken languages in the world? There's some extra special kind of craziness going on with that rule. So, where does one find such a glorious example of an impossible-to-implement-or-verify policy? Why, in a governmental guideline for password creation, of course.

Suddenly, Mordac, the preventer of information services, doesn't look like such a bad guy.

In the end, I guess my question is: do these more or less ridiculous policies really help create more secure passwords?


To be continued...

3 comments:

  1. The whole concept of a 'strong' password is a fallacy. It's based on there being a threshold of cardinality (usually around 10^13) determined to be 'hard' given available computing resources.

    There's a similar fallacious rationale behind frequent password changes: If a password-cracking program can discover a password in N days, one should change one's password no less often than once every N-1 days to be safe.
    The inventors of such rules don't understand that N is an upper bound, and that by happenstance a password might be discovered in seconds; in other cases take up to almost the N day limit; and that the likelihood of a success on any single try is not affected by the age of the password, except insofar as the remaining password space is reduced by the number of unsuccessful probes. No matter how often you change your password, you at best double the average effort for an intruder to discover it.

    Both of these policies are a disaster in the workplace where people are driven to adopt password schemas and/or write passwords down on notes that ultimately end up in the garbage. In any case it's a solution to a problem that's already better solved by simply detecting crack attempts.

    ReplyDelete
  2. (JFL is rather busy with other work these days, hence the lack of new blog posts from him. I think he'll get back on track soon...)

    Really nice comment, with one of the best "one-liners" I've heard in a long time: "In any case it's a solution to a problem that's already better solved by simply detecting crack attempts."

    As for writing down passwords I do support that, given that those passwords are "strong". Writing down your strong password instead of remembering really simple passwords is good, as i see it.

    Detecting crack attempts is interesting, no doubt. Any pointers to tools, techniques, algorithms etc?

    Best regards,
    Per Thorsheim

    ReplyDelete
  3. With the proliferation of readily available "rainbow table" password cracking tools, all these password policies become futile nonsense attempts to somewhat safeguard "higher management" egos.

    ReplyDelete

All comments will be moderated, primarily for spam. You are welcome to disagree with my posts of course.