Saturday, September 05, 2009

Passwords and security

The industry standard password policy is pretty much universal. The cornerstone is that people have to change their passwords regularly, and everything else follows from that: that they choose their own passwords (because no one else has time, and so no one else knows them), that the passwords have required complexity (since they're terrible at choosing their own passwords), and that they can't keep reusing the same ones.

The thing is, no one really ever seems to have considered the alternatives and given them a really rigorous scientific investigation. The standard is what everyone does because it's the standard, and that's why everyone does it. But in my opinion and in my experience, it actually is pretty poor security.

It seems everything about this policy is based on one point: that it's a bad idea to have the same password for a very long time, because it increases the odds that it could be compromised, and you might not even know that that happened. And that's certainly a factor, no one would deny that. But it's not the only factor. In my opinion, forcing regular user-made changes to complex passwords is just inviting far greater weaknesses than what strength you gain from the frequency of the change.

First, you're asking users who don't understand security and have no particular incentive to care about it to be the ones to choose their passwords, and that alone is the greatest weakness in password security. Users choose terrible passwords. And no amount of algorithmic password complexity validation is going to prevent that. They're still going to use their dog's name or their birthday, they're just going to add a number to the end, and then keep incrementing the number. Not everyone will do this, but most people will, and it only takes a few doing this to mean your password security on the whole is already weaker than assigned passwords that don't change for a year.

Second, if users have to know five different complex passwords which change often, you're just inviting them to write them down and keep the note near their computer or on their person. You can exhort them not to, but if you don't meet them in the middle by making it reasonably possible for them to memorize their passwords, it's just not going to happen. Back when you had only one password, maybe you could be expected to memorize a constantly-changing, arbitrarily complex password; but today, with all of us having a lot of passwords, it's just not possible to expect that.

Third, users now have every motivation to reuse the same password on multiple systems, both ones you control and others. Face it, every one of your users probably has a home computer and accounts on banking sites, fora, email accounts, social networking sites, and who knows what else. If it's hard to remember passwords for all of the systems you host, how much harder to remember fifty more. Obviously they're going to reuse passwords, and some of them are going to use the ones they use at home at work. That means they're taking the password they use to get to your highly sensitive, mission-critical system, and typing it into random web pages of dubious provenance.

All this can be avoided by simply meeting your users halfway. Assign passwords algorithmically, but make them memorizable: randomly selected words joined with randomly selected punctuation or digits makes memorizable passwords that are still secure. Use as few as possible: share them between different systems if you can. And don't change it more than once a year, and don't let users change them at all. If you do those things, users are far more willing, and far more likely, to not write them down after the first week or so, and to not share them with other sites or systems. In exchange for the relatively minor weakness of having the password not change that often, you eliminate all the other, far greater, weaknesses of bad passwords, written-down passwords, and password sharing.

But you can't get away with that because the industry standard rears its head and everyone insists on it as a matter of policy because it is the standard. It's self-perpetuating. I wonder if someone's actually proven that the standard is better for some reason which eludes me, but I doubt it. It's very frustrating to be forced to abandon a policy which users like and which gives solid security for one which makes everyone unhappy and actually weakens security just because someone calls it "best practices".

No comments: