So, you're implementing a new software system that requires user authentication and management? Personally, I'm tired of seeing web sites fail to include a number of basic elements in their user management schemes. These Laws for Authentication Systems should not be violated regardless of how important or unimportant security is for you.
If you decide to write your own solution or pick a packaged solution, make sure that system does not violate these laws.
#1 Encrypt user passwords using strong, one-way encryption.
How is it that people are building systems that store unencrypted passwords in 2009? I don't care how low the risk profile is for your system. You have a duty to the rest of the Internet to make sure user passwords are encrypted because your users are likely using the same password to access multiple systems.
Encryption is not good enough. It should be one-way encryption. In other words, if your help desk person can tell the user their password, it's a bad encryption scheme. One-way encryption essentially means that the password itself is required to decrypt the encrypted password. If you don't know the password, you can't decrypt the encrypted version.
#1a Encrypt passwords over the network.
The real master law is: passwords are always encrypted except at the moment of comparison during an authentication operation.
It also means if you are keeping a password around in memory (why exactly?), you should have it encrypted while it is sitting in memory doing nothing.
#2 Do not place a meaningful upper limit on password length.
Few things irritate me as much as a web site that has a silly maximum password length. I recently setup a new account with American Express and their maximum password length is 8 characters. ON A FINANCIAL SITE.
Encourage your users to create strong passwords. While forcing a 10 character minimum makes no sense unless you have a top security web site (and, in that case, you should be using a 2nd factor of authentication), there is never a scenario in which you should limit password creativity. Because you are likely storing the passwords in a relational database, you may have to put a practical limit on the passwords.
May I suggest 255 characters?
#3. Do not limit the kinds of characters that may be used for a password.
Most people know that you should have passwords that mix case and include numbers. The reasoning is because the larger domain of possible characters in a password, the
harder it is to execute a dictionary attack. There's no good technical or usability rational for eliminating any of the Unicode spectrum from passwords. The only thing you likely want to disallow is the use of whitespace to start or end a password.
"1s33Hax0rs" is a good password
"+иß33(ax0rΣ" is a better password
If you just can't do the full Unicode set for technical reasons, at least allow non-alphanumeric punctuation and other ASCII symbols.
#4 Never email a customer a permanent password.
Depending on your system's risk profile, it may never be appropriate to email out passwords. If you do, a password change should be required every single an unencrypted password goes out via email.
I recently had an experience buying VMware Fusion on VMware's ecommerce site in which they emailed me the password I registered with. Why on earth did they do such a stupid thing? I created the password, so obviously I know it and don't need an email reminder right after registering. Furthermore, they compromised the integrity of that password and any other system that I might have been using with that password.
Let me enumerate the attack vectors:
- Anyone who had access to the network or SMTP systems involved in the hand-off chain between VMware's systems and Google.
- Anyone who has administrative access to Google's email systems, including the eternal GMail backups.
- Anyone capable of compromising the integrity of Google's systems.
- Anyone capable of compromising the integrity of my laptop.
- Anyone who gains access to a public machine I was using after I forgot to log out of GMail.
Fortunately, I use encrypted IMAP. Most people don't. So an alternate attack vector in most cases is anyone who can engage in a man-in-the-middle attack between the mail client and GMail.
I am sure I have missed others.
By the way, it's almost certain they weren't encrypting my password using a one-way encryption algorithm either.
#5 If you have a low-to-medium risk system, use OpenID.
By leveraging OpenID, someone else is worrying about authentication for you. OpenID is not appropriate where control over user authentication credentials are a key part of your security requirements, but it is appropriate for most systems out there on the web.
I'm also intruiged by the solution being offered by Usable Security Systems. I've not personally implemented or even played with their authentication solution, but it looks like a strong contender for a cloud-based authentication solution for medium-to-high risk systems.
I suppose the real moral of this law is: don't implement your own authentication system unless you absolutely have to.