Living with Password Policies

It seems to be accepted wisdom that password policies are a Good Thing™ for IT security. But are they really? A password policy typically consists of two things:

  • Rules about how complicated your password must be
  • Rules about how often they must be changed, reused, etc.

A typical policy will say ‘at least one upper case letter, one lower latter, one digit, at least 8 characters’ and ‘must be changed every 30 days’. And the general idea is that although this inconveniences users a bit it certainly increases security.

Some web sites have rules for ranking the security of passwords, although exactly how those rankings work is not clear. Interestingly I had the same password rejected as too weak and accepted as 10 / 10 in strength on 2 different web sites – go figure.

Given that a typical user cannot remember large numbers of truly random passwords what do they do in real life in the face of these policies?

Some users will use a personal password vault, such as KeepassLastPass, there are some excellent ones and this is not a bad plan.

At the other extreme people will write their user and password on a post it and stick it to their screen. True story: Way, way back I had a highly privileged account; one day I paid a visit to the office of some colleagues only to find my user name and password stuck on one of their screens! Post-its – clearly a bad idea.

Some people use password templates. For example they always use dogDOGNNN. Where NNN is a 3 digit number that is changed as required. This reduces the problem to one of remembering a 3 digit PIN. Now you could even write the PIN down, since the dogDOG part is kept secret. The user knows that 237 means dogDOG237.

Others use transformed words. The transform rules are standard; capitalize the first letter, transform the first o or I to a digit () or 1). Thus kitten becomes K1tten (probably too short but you get what I mean); xkcd has thoughts on this.

So where are we; did we improve our security by adding password rules? Well we certainly want to disallow things like 123456, ‘password’ or ‘abc123’ and we did that. We forced people to use non trivial passwords, but are all complexity rules good?

If we treat a password as a supposedly random sequence of characters then many policy in fact do harm. For example banning repeated characters definitely reduces the search space: I know that the letter ‘a’ cannot be followed by another ‘a’. A policy that requires a digit means that if I have not yet seen a digit after, say, 8 characters, then pretty soon I am going to see one thus I should try digits before characters. However passwords are in general not random sequences, they are human generated (people are bad random number generators). If we did not have rules then they would use overly simple ones.

So what to recommend. The common recommendation is to force a good length and don’t ask for change very often – maybe never. So ‘house_brick_cat_sea’ is a good password. This is the xkcd style; in fact there are several online xkcd generators.

How often should we force changes? Well that begs the question – why force password changes? Answer: so that if a password is compromised then the effect is limited. But if my password is stolen then most bad things will happen pretty soon. The only time having a short change time is if a hacker wants ongoing access to something – a ‘spy’ checking in once a week to see our new secrets. So again there is no easy answer – the consensus seems to be around 90 days.

And of course I recommend our enterprise password vault