Schneier on Security

Roger • August 11, 2009 6:45 AM

DO use a password manager …

Yep. Password Safe, hereinafter “PS”. Used for everything except my work and home Windoze logins (password manager not running yet when logging in!), and my cell phone unlock PIN, plus the PS master password itself. And yes, I have backups!

DO change passwords frequently. …

I don’t generally follow this, because nearly all of my PS generated passwords have approximately 105 bits of entropy, and so it is pointless. There are 2 special cases I change once a year. Plus I might login to something low-grade at a riskier PC, like say, IMDB at the library, but then I change it as soon as I get back to a trusted machine.

DO keep your passwords secret….

Yep.

DON’T use passwords comprised of …

Yep. Follows trivially from using PS.

DON’T use the same password for different sites.

Yep. Follows trivially from using PS.

DON’T allow your computer to automatically sign in on boot-up and thus use any automatic e-mail, chat, or browser sign-ins. Avoid using the same Windows sign-in password on two different computers.

Yep, I follow this. Logon passwords are two of the four passwords I actually have memorised. Everything else bootstraps off PS.

DON’T use the “remember me” or automatic sign-in option available on many Web sites.

Yep, I don’t do this. In fact Firefox is set to delete all cookies at the end of every session. (Contrary to various claims, I have never found this to be an issue with anything at all.)

DON’T enter passwords on a computer you don’t control — such as a friend’s computer —

I sometimes violate this for certain proverbial “low value accounts”, such as accessing IMDB at the library, but then I change the password when I get back to a trusted PC. If I’m expecting to be using untrusted PCs for a while, e.g. email access whilst travelling light, I’ll actually create a couple of “disposable” accounts beforehand, change the password everytime I login, and cancel them afterwards. In principle the owner of a key logger could get to the password quickly enough to take over the account before it’s changed, but it’s never happened yet, and all I need to do is use the backup account to tell everyone to stop using the compromised one.

DON’T access password-protected accounts over open Wi-Fi networks —

Yep, I follow this one. Actually I rarely use an open Wi-Fi link for anything except general interest browsing, or checking e-mail over an account that SSLs the entire session.

DON’T enter a password or even your account name in any Web page you access via an e-mail link.

I also follow this – which is arguably the most important rule on the list!

I’m a little surprised that Bruce says he violates so many. It’s true that they are a PITA to obey without a password manager, but using PS — which he designed! — solves 99% of the problems and enables you to be this strict quite easily.

Roger • August 17, 2009 7:15 AM

@Hugo, triceratops, Bilge:
What Clive says is pretty well right. However there is another argument often used today, which is superficially quite convincing, but also wrong. The argument concerns dictionary cracking of a hashed (one-way encrypted) password.

The argument presumes a cracker who has somehow stolen some sort of hashed credential (whether a copy of /etc/shadow, an NTLM hash sniffed off the network, or whatever.) The attacker is proceeding to grind into these hashed credentials with some sort of brute force or dictionary attack. The attacker has some probability per unit time of success, depending on the entropy of the passwords, and his number of trials per second. His total probability of success is the life expectancy of the password multiplied by this rate, i.e.:
P = Tr/N
where P is probability of attack success, N is size of password space (here assumed uniformly distributed for simplicity), r is the attack rate, and T is the maximum permitted password life.

Now the argument goes like this: obviously we want to minimise P. We have little control over N: users will be given advice on choosing passwords, and perhaps we will even do some password strength checking, but there will always be some guy who chooses his car registration number. We also have little control over r: we can make password hashing slow to reduce this rate a bit, but we can’t make it too slow or else it will annoy users, and we simply have no control over how much iron the attacker can throw at the problem. Thus to minimise P, our best bet is to minimise T.

Obviously we can’t make it too small, or it will be really inconvenient to change passwords so often, so how small should we go? Well at some point in the past people threw some guesstimated numbers at the problem and came up with various figures from a week to a year or so, depending on what parameters you guessed, and a lot of folks settled on a month as being not too inconvenient yet not too risky.

Unfortunately, the whole line of argument is baloney, for two reasons. The more important and cuter reason is that if the attacker can still gain access to a hashed credential (and we’ve done nothing to stop him), then he is not “defeated” by the password change, he just has to start again (or if he is already randomising his search order: he changes nothing, just keeps going!) That might seem like a lot of extra work but actually it turns out that on average, all these password changes at most double his time until success, no matter how frequently they are done. Even if the hapless user is forced to change his password at every login, he achieves at most a doubling of the time until the cracker controls his account! This is really not very helpful.

The second reason it is baloney is that the calculations are now totally dated (that is, the calculations that people once did to come up with a month as the right order of magnitude.) If your users are still choosing 6 character dictionary words as passwords then be warned, they can be cracked not in a month but in a fraction of a second. Changing it once a month is useless because it will be broken again somewhere between hitting “Enter” and lifting the finger off the key. If you are a paranoid bastard like me and use 16 character random strings then you were immune to dictionary attacks back then and you still are. But most users need to have graduated from 7 or 8 character pronounceable non-words up to at least 10 character random alphanumeric strings (e.g. “ZY1L5QKA9D”), or 14 character pronounceable nonsense (e.g. “sotrebtapmundo”). For many people this is simply too much, and so the reality today is:
a) if system security prevents the cracker from getting a hashed credential to chew on, then all of the above is moot; but
b) if the attacker can get a hashed credential, then it is still moot, because most users will be dog meat in minutes.