The Five Laws of Implementing a Login Solution

By George Reese
May 19, 2009 | Comments: 16

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.

You might also be interested in:


The link to Usable Security Systems is missing a 'w'

"Because you are likely storing the passwords in a relational database, you may have to put a practical limit on the passwords."

Excuse me? No, you are not. You are storing a cryptographic hash of the password, which is (most likely) of constant length, irrespective of the length of the password.

You're absolutely right. I was torturing myself trying to think of a reason why someone would place a limit on password length and wasn't thinking about the fact that what you are storing is not the password, but the encrypted hash.

Another flaw is the manner in which browsers transition from unencrypted to encrypted sites. Improving that alone would put all the MITM spoofs and scams out of business entirely.

Using more robust encryption technologies out there that are impervious to MITM, such as Extended Validation SSL /simply because it's impossible to replicate./

What a wake-up call from VMWare /the way they compromised your password, which just shows how even corporate networks are going to need to start using more robust encryption.

You have to have the unencrypted password from the source before you can encrypt it for comparison :)

Hola, I have a question about:
"The only thing you likely want to disallow is the use of whitespace to start or end a password."

I have seen this requirement exactly two times--both times for older systems which connected to mythical beasts called mainframes. I have never understood why or even how this type of requirement came into being--but I assumed there was some "legacy" reason.

Can you explain to me why I would want to disallow whitespace in a modern web app? Thanks, David S

Whitespace to begin or end a password can create usability issues. There's nothing wrong with whitespace within the password.

About point #3, I would beg to differ.
Users should be limited to the latin charset only (and of course, numerals, punctuation marks, etc.).
I work in a multi-cultural environment and we have different keyboards and different language encodings. If you allow users to enter passwords using the Greek alphabet for example, the user will only be able to login from a computer who has the Greek language keyboard encoding installed.

Actually, most systems these days offer alternate keyboard entry such as the Character Palate on the Mac.

Care to elaborate a bit more on this?
I am not familiar with the "Character Palate" on Macs, but I don't understand how anyone would manage to login to a website using a password with Greek characters on a PC which does not have the Greek language keyboard encoding.
Are you suggesting that users could fire up something like the "Character Map" system utility and just select characters from there? If so, I assume you realize this is neither practical nor advisable given that most users are not even aware of the existence of such utilities.

Great post.

I can't stand when sites limit my password length, or characters. I've had sites not allow "." I'm not entering any weird or wonderful symbols, just a simple full stop. Means I have to learn another password.

And site that email you your password are just wrong. Encrypt it using a salt/hash.

Good article, but I'd change this

"passwords are always encrypted except at the moment of comparison during an authentication operation."


"passwords are always encrypted"

Why would you decrypt a password for comparison? Just encrypt the password entered for authentication, and compare it against the stored encrypted one.

The reason people are placing a limit on password length is most likely because they *aren't* encrypting the password. Or, there are non-technical managers frustrating their programmers with idiotic requirements beyond normal, which then makes you wonder what else the system does that is less than smart...

A great solution to check out if you want to accept third party accounts like the OpenID providers (AOL, Yahoo, Google, MySpace), proprietary solutions (Facebook, Live ID) or OAuth-based solutions (Twitter) is RPX ( provided by JanRain.

Store TWO different hashes of the password. Let's say, SHA1 and MD5. You might be able to find a plaintext for either hash, but you probably won't find a plaintext that generates BOTH hashes unless it was what the user entered.

Both MD5 and SHA1 hash algorithms can be implemented in JavaScript at the browser. Thus, only the hashes ever traverse the network. To prevent replay attacks, when the server generated the login page, it includes a new unique "salt" value. The JavaScript code computes: SHA1( salt + SHA1(password) + MD5(password) ).

Since the server already has SHA1(password)+MD5(password) stored in the database, it can computed the same salted hash and compare. Every time the user gets the login page, the "salt" value is different.

@DannyB Don't do stuff like storing two hashes if you don't exactly know what you are doing. Cryptography is a complex science and providing two hashes for one password might actually introduce the chance for an attack.

If you have doubts if an up to date hashing algorithm plus salting offer enough security for you needs, don't try to improve the algorithm on your self. Hire somebody highly specialized in this kind of thing. And she probably shouldn't tinker with the algorithms either.

News Topics

Recommended for You

Got a Question?