[Addendum for 2010-01-17: I have received no less than two requests for permission to republish this (one of which is why you're reading this online and not on a mailing list). I hereby give you permission to republish this wherever you want, under a Creative Commons Attribution 3.0 Unported License, or the GFDL license. Linking back to this page would be choice, as I may add some other points in the future, but I'm willing to let people use it for just about anything short of declaring it public domain. Questions? Drop me a line. I just wish I had noticed the missing words before I sent it out. Ah, well. Adds to the manifesto quality, I guess.]
[Addendum 2 for 2010-01-17: I'll just add a table of contents.]
Three years ago, in accordance with Furr's Law, I decided to respond to a post over at Kotaku. [The video is now dead, but I think this is the same video]
In order to do that, I had to sign up for an account at Gawker.
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.
But that's not what I came to tell you about. Came to talk about password standardization. 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.
(6) Security questions should always make the user more secure, not less. I'm not really sure if they're ever useful in practice, but I'll admit that they could be, at least in theory. If you have a user who forgets his password frequently, a security question in lieu of password can help the user to remember it. A security question in addition to password, on the other hand, is just another password, and it might make more sense to use a method like you see in (D) in such situations. Once users recognize that this is just another password, they'll respond to it that way, and there's no sense in encouraging a user to use a password that, if cracked, can compromise several other accounts. If you do require security questions, these should be questions whose answers are known only to the user, are difficult to forget, and infrequently change. Systematic methods of changing these security questions should exist, as well, rather than assuming that the user will know which best man was used for this account.
There was a time when your mother's maiden name was fairly secure. If someone didn't know your mother, they didn't know her name (or at least she'd have to spend a few hours at the county clerk's office to find out). Those days are gone, and even your father's brother's nephew's cousin's former roommate's maiden name is easily identifiable to fraudsters. Whether the users know that information is less certain. You'll want to make sure you choose something that only the user will know, which means that if the user forgets the password, he has probably also forgotten the security question, since that is something only he knows, and has much less occasion to use. If you really want a good security question, try something like “What does this ink blot look like?” It's known only to the user, it's difficult to forget (indeed, the user may not even be aware that he has something to forget), and the answer is unlikely to change frequently (unless the underpinnings of inkblot tests as methods for analysis of fundamental psychological states is wrong).
A personal anecdote: one of my online accounts had me fill out some security questions. I did the normal thing, and chose arbitrary answers for each question, stashed the answers in a file, and hoped to forget about it. If I lost my password, I could go to the office and bring along my passport. Of course, that's not how the company chose to use those questions. Instead, it asks me those questions whenever I try to log onto their servers from a computer it doesn't recognize. And since I don't have a static IP address, this is just about every time, with the additional consequence that many people who are not me but simply exist in the same subnet may have the ability to bypass those questions while I do not. This is probably not how this was intended to work.
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.