Password policy insanity

I'm a realist. I prefer written password policies that can be technically implemented, and at a level which doesn't make most of my colleagues *hate* me.

The Norwegian Post and Telecommunications Authority (NPT) in Norway is the only government authority in Norway that has published a publicly available recommendation for a password policy targeted towards organizations. Among many other recommendations for end-users and organizations, they can be found (in Norwegian only) at their portal named "Nettvett". Being the only recommendation publicly available from the Norwegian government, some might consider this as a "best practice" recommendation.

Well, let's dissect it, one line at a time. The recommendation is available here (as of 30.12.09): Forslag til policy ved bruk av passord. Using Google Translate you'll get this English text, which seems fairly correct. In case they change their recommendation, i've got a screenshot of the 30.12.09 version here:

1. Passwords are personal and must not be given to others
Fair, reasonable, makes sense. Nothing to add or subtract here.

2. A password should be at least 8 characters in length. Furthermore it should use at least three of the four character groups: small case, UPPER CASE, numbers and special characters.
This is in line with many (most?) publicly available recommendations found across the Internet. I consider this reasonable requirements.

3. A password should not be the same as the username, or contain parts of the username.
Here's my first objection. The first part is obviously ok, but if my username is per, it does seem a little strangetrange that i shouldn't use the 3-letter phrase per anywhere in my password? I'll agree that per12345 may not be the very best of passwords, but Ad=?vBn//øæÅper49$$ is "good enough", even if it does contain the username as part of the password. Alas; the recommendation text should probably be changed a little. (I've got some statistics on where users put their username in their passwords, i'll get back to that in a later blog posting...)

4. The password should not be linked to personal information such as name, social security number or phone number
Objection! Please, read RFC2119 for starters! When I worked for PricewaterhouseCoopers, i learned that on the documentation side of things, i should write a policy ("the law"), with standards below it ("explaining the law"), and guidelines ("how to implement security in compliance with the law"). Seriously; it is IMPOSSIBLE to create a password filter or conduct a security audit that checks these parameters. Although NPT uses the word should, they really should differentiate between a requirement and a recommendation. Otherwise we would surpass George Orwell's "1984" in controlling any and all information about all users. Besides, i've got statistics showing that a lot of people breaks this "requirement" anyway!

5. Passwords should not be a regular character combination, a word or a common combination of words found in dictionaries or used in everyday language, any language.
What is a regular character combination? Everyday language? Any language? Ahem. Given the number of languages that exists on this planet, this is simply not possible to implement in a password filter. If people actually read the requirement and spent more than 5-6 seconds thinking about it, they would see the impossibility of such a requirement.

6. Passwords should not be a word that is written backwards
I don't know why NPT decided to put this up as a separate bullet, since (again) statistics shows that very, very few people does this with their passwords. In addition, given the requirements in bullet 5 & 2 above, this requirement is unnecessary anyway.

7. A user's password that is used within the organization should not be similar to other password that is used outside the organization
It's a good idea (and good practice) to write policies in such a way that they can actually be measured, at least to a certain extent. This requirement is a good recommendation, but impossible to block or implement technically in any way, as it would require absolute trust/honesty or "1984" control.

8. Password should be replaced every three months and may not be the same as a previously used password
Why 3 months?  Why not 7 days or 1 year? Why change? Well, a bright mind told me a few months ago that a really good password should never need to be changed. I told him he was wrong. You simply can't trust your password to be 100% secure against any and all types of cracking, recovery, theft, bruteforcing or whatever you want to call it. However; many parameters affects this decision, and as a general recommendation i support a 3 month change policy. I'll get back to details here in a later post on hash recovery performance (i've already got some numbers posted on this).

9. Passwords should not be written down
Many people who gets into a discussion with me on passwords tend to suggest "never write down your password" as a good rule for everyone to follow. Bad idea. In fact; if you can't remember your passwords, write them down! (and protect your physical piece of paper somehow). Here's the simple example.

Bob has password34 as his password for a given system. It is very easy to remember (he doesn't write it down), and he never changes it every 3 months, the next will be password35. Sorry, but that's not a good password. Let me talk to Bob. "Bob, if you promise me to set a complex 10+ character length password, I'll let you write it down, along with all other passwords of the same or greater length. Yes, i know you will have problems remembering it, that's part of the point here".

My point is simple: any idiot can rather easily find simple passwords through dictionary attacks, or a little more advanced hybrid attacks. With the Internet up and running, that means maybe 2-3-4 billion people that may guess Bob's password in just a few attempts. If Bob writes down his complex password 44llm::;/34wwoert!!, there will be rather few people to interrogate if his account is breached, since guessing or bruteforcing such a password is highly unlikely.

Dear NPT: Please rewrite your recommendation for a password policy. Please specify which parts should become requirements and which ones that are just recommendations. Remove at least 50% of the text. Ask people who uses computers once or twice a month for advice (Call my dad...). And read my blog to see what the real world looks like on password reality. What you recommend is nowhere near the truth ANYWHERE.