Against the braindeadness of password policies: Andrew A. Gill's "Password Manifesto"

I was struck by the rational thoughtfulness of Andrew A. Gill's write up about password rules. Read the original post.  I learned about it through a Twitter post from @mediajunkie.

With Andrew's permission, I'm excerpting here.

The Password Manifesto

by Andrew A. Gill

...

For both of the people on the internet who do not know, Gawker's user databases have been compromised and the passwords stolen. I tried to log in to my account over there with any of the throwaway passwords I use when I don't care if I get compromised, and that did not succeed, so I'm pretty sure that I never changed it in the first place.

All of this makes me (much like this guy) wonder why I needed a password for that in the first place. I'm not interested in the Gawker community; I just wanted to let someone know that the Flight of the Bumblebee is not Fantasie Impromptu. Ideally, I should be able to sign up for an account, comment, and then disable the account, unregistering any password for it, requiring e-mail authentication if I ever want to comment again.

... The process of password generation for multiple accounts doesn't need to be a difficult process, but it invariably is because of the brain dead password limitations that the web sites give you.

Or, more often, don't give you. I have several passwords that are less secure than they could be because I'm not sure how long they can be, or in some circumstances because they have to be kept in sync with passwords that have to be shorter or can't use anything other than all caps or other idiocy.

And then these have to be kept alongside passwords that have to have letters and numbers and specials and have to have a number in the second position and can't have a capital on the last letter.

There is no reason why any password cannot have the 62 characters of [:alnum:], and you'll even have the rest of the printable ASCII characters left over to escape anything that Bobby Tables might throw at you. I should demand that all websites use Unicode for passwords. There are many different open source solutions to handle form input (with or without i18n) out there without counting the proprietary ones. But let's settle for the `normal' characters just to get to some sort of common ground now.

But it's time to get to the manifesto. Yes, I know that most of you reading this already know what I'm going to say. Still, we need to make sure that this information is clear and easily understood by everyone so that we can come up with a standard set of procedures to implement.

(1) If nothing else, show the users what options they have for selecting passwords. What is the minimum? What is the maximum? Which characters are allowed and which are disallowed? Are there going to be password hints? Is the password stored on the remote system or the local system, both, or neither (with a system like shadow passwords)? If the remote system is keeping a copy of the password, will that password ever be sent to me in plaintext? Is that code going to be used as a password hint to be given by the local system or as a token given by the remote system to prevent phishing?

Without this information, users will default to using worse passwords than they can. If one password is compromised on your system, it might allow an attacker access to another part of the system where another flaw would leave your entire system compromised. It's bad enough that many systems don't allow good passwords, but we don't need to encourage people to use less secure passwords than they want to.

(2) Allow good passwords. The only excuse for disallowing any Unicode character in a password is that you're running a legacy system that disallows it and you cannot upgrade the system. There is no excuse for disallowing any of the 95 ASCII printable characters (32-126), and if your system disallows some of the 62 characters of [A-Za-z0-9], there's something seriously wrong with your input handling, which wouldn't even be able to handle LadiesMan217. And if you allow those for your usernames but not for the passwords, you've got your priorities backwards.

I suppose I shouldn't have to say this, but I have more than one password or PIN number that is less than ten digits long, and must be numbers. It may sound like I'm being sarcastic when I talk about Unicode on legacy equipment, but I get it. Many people still have legacy equipment and can't change for whatever reason, but unless you're transmitting passwords via Teletype, your system can handle it.

(2a) Allow long passwords. My WPA wireless password can be up to 63 characters long, and that's not the most sophisticated security out there. If every wireless hardware manufacturer has figured out how to implement that length, there is no reason why every software password system can't allow one that long. If the passwords are stored as hashes, increasing the size of the password will not increase any storage requirements on the remote system, since verification is done by checking the result of an cryptographic transformation on the password, and the results are a set length.

This naturally will get into a discussion of passphrases later. Be aware that simply using passphrases doesn't make you more secure--we tend to use a few common words for passphrases, with the result that one word in a passphrase may be worth only two or three printable characters in a password.

(3) Allow bad passwords. Good passwords are a good idea, but so are bad passwords. That doesn't mean allow four number passwords, but it does mean getting rid of the smarmy messages about how ihatethisstupidpasswordchecker is not a strong password since it is composed of words found in a dictionary.

People use passwords for different things, and sometimes they might want to use a bad password for one of a few reasons. I understand that you are concerned that your whole database of which username wants to marry which character from Naruto. This is obviously vitally important to keep secure and thus justifies the randomly generated FIPS-181 password that changes once every two weeks and cannot be set by the user—in case they have some burning desire to add another spouse to their fictional online polyamorous relationship. But it it at least conceivable that lebowskifan87 might not be too concerned that someone finds out that she likes Coen Brothers movies.

(4) Use some real thinking to determine when require good or bad passwords. Does this password give you access to your money? Or other people's money? Perhaps confidential client information. You'll probably want to use a good password for that. But you won't force users to use good passwords if they don't care about your security. They'll use technically good passwords like Ab(d3 or write them down in an unsecured location. How often do you need to enter a particular password? If you have to enter it every time you come back to your PC or send a message, you'll probably want a short password, while a longer password may be useful for things that you have to do once a day or so.

I have several passwords that I either no longer remember or had to write down in an unencrypted file because the ones I wanted to use were too insecure for the webmasters at some blog that forces people to register in a lame attempt to convince its readers that they're part of a `community.' I also have several passwords that I have to use for work to handle client data, and do things like log onto my work PC, which I lock every time I get up from it. I choose high-entropy, difficult to remember passwords, and let muscle memory take me the rest of the way. A couple days after changing the password, and I have no trouble entering the whole thing, even with my typical fat-fingeredness. If I got locked out after a few bad passwords, I'd quickly find myself out of a job trying to enter a 63 character passphrase blind.

(5) Never default to send a user's password via plaintext e-mail without a prior request to do so. Plaintext e-mail, as has often been said, should be treated like a postcard. Expect that any plaintext message can be intercepted and read, because, well, it can be intercepted and read. For whatever reason, some users may want to use plaintext e-mail to have their passwords sent to them from time to time, either as a reminder or as part of a forgotten password recovery procedure. We aren't going to see that go away anytime soon, but many users are not going to want their passwords routinely transmitted insecurely, and we should honor their wishes. At the very least, the user should have to opt in to this type of behavior.

I have had to change passwords on multiple occasions when they were sent to my e-mail address in plaintext, usually as helpful weekly password reminders. This is just downright silly.

Well, that's pretty much it, but here are some advanced tips that I don't expect can be used in every case. I recommend using them in every case, even when there are legitimate objections to them because they are part of best practices, and I suspect that the objections will be overcome in a few years, at which point, these will be part of the standard operating procedure.

(A) All passwords should be transmitted through encrypted communications. This means using SSL for your servers. SSL and certificates aren't cheap, so I understand why you might not want to do this, but there are other ways to encrypt a password if this is not available to you. If you need to send a password to the user's e-mail, send it using the user's public key encryption, if available. If you can't afford to do any encryption at all, consider if you really need users to give you secure passwords if you're not going to keep them secure.

(B) Passwords should be stored as hashes of the password, not the password itself. By doing this, the password itself is not stored and if the password database is cracked, no data are compromised. The cracker would have to generate a hash collision to get a password. Doing this also means that you won't be able to alert the user that the third digit of her four digit PIN number is the same as the previous password she used for this account. Good riddance, in my opinion.

(C) Users should be able to temporarily or permanently disable accounts, removing all passwords from the remote server's database. Whether that's because the user rarely comments, or because the user is paranoid, or because the user gave up the internet for Lent or because the user has been convicted of wire fraud and can't use a computer for the duration of her sentence is irrelevant.

(D) A very long password, like a sentence or some other multi-word phrase may indeed be better than a shorter password, but it might make sense to include it as a sort of two-factor identification. Enter your passphrase at the start of a session, and that passphrase enables the operator to use the shorter password to authenticate when the program notices a five minute idle and logs you out. The password is useless to any attacker who is not physically at your computer while you are logged in with your passphrase.