Simple suggestions for implementing passwords correctly

The usability of web forms is a subject that has been discussed extensively, and one which is supported by a large body of literature (1, 2, 3, 4). The consensus is that getting web forms right is much harder that it may initially seem. One aspect that particularly annoys me is the way most developers implement passwords and their validation.

Despite the emergence of single sign-on systems like OpenID, most users are still affected by so-called password fatigue, due to the effort required to memorize a number of different passwords for several services.

For a variety of reasons, users end up taking a dangerous shortcut: they reuse the same password (or small group of passwords) for everything. This approach is as secure as the weakest site you signed up with 1, which generally means it’s very insecure. A better alternative, and the approach I take, is to use a secure password manager instead. At this point it would be very challenging for me to work on Mac OS X, without having 1Password installed.

The reason I mention 1Password is because it has advanced features that generate randomized, secure passwords when you sign-up for a new site. Having that tool at my disposal further highlights the shortcomings of most web forms in regards to handling passwords. In fact, I often find myself changing settings in the password generator, just to satisfy the arbitrary rules defined by each individual form.


In light of the aforementioned considerations, here are a few suggestions for login implementers:

  1. Don’t ever store my password in plain text. When I sign up, don’t send me my password in clear text. If I can see my password in your recovery email, your implementation is not secure. Always store an encrypted (salted) version of my password. If I forget my password, I expect a reset link in my inbox. Oh and it should be obvious, but just in case it’s not, never use a text input field for a password.
  2. On a similar note, don’t allow my password to be transmitted in plain text, or it becomes possible for unwanted eyes to intercept it. SSL is your friend.
  3. If you try to prevent remote, brute-force attacks by limiting the number of login attempts, do so with a large, sensible number (e.g., not 3 attempts maximum). Also, understand that speed is not a desirable trait for hashing algorithms in this context. For this reason, it’s a good idea to use bcrypt, which offers a much slower and harder to brute-force algorithm that enables you to choose how time consuming the hashing operation should be. This is particularly important, if a malicious user manages to obtain local access to your encrypted passwords. It’s one thing to process, say, 100,000 hashes per second, and an entirely different thing to process 7 of them. Login and registrations are rare enough not to warrant fast encryption algorithms.
  4. Show me what the length and characters requirements for a password are upfront.
  5. If you choose to ignore the suggestion above, at least make these requirements clear in the error message you are showing me. Far too many times I’ve seen errors like “The password you entered doesn’t meet our requirements”. So, what are your requirements?
  6. Don’t cap the password to 8, 12, or even 15 characters. People who use password managers, may want to store strings of 35 characters, and should be free to do so. With the current technology, even a password with far fewer characters is secure enough 2, however there is no good reason to impose arbitrary limits that are so restrictive. Accept up to 50 characters at least (which happens to be 1Password generator’s limit as well).
  7. Don’t impose limits on the type of characters that are permitted. If I want to use special characters, I should be able to do so. This further strengthens the security of your users’ passwords, so why not allow it? If you don’t do so because you can’t make your code immune to SQL Injections, you should not be implementing a login system in the first place.
  8. Don’t invent arcane rules for password validation. It’s ok to require special characters, but if I have to think hard about what password could fit your criteria, you stand to irritate your new users. Feel free to show me how secure my password is though. Doing so may aid newbies when it comes to choosing a stronger password.
  9. If both the password and the confirmation are automatically filled in by a browser add-on like 1Password, don’t prompt me with an error saying that I haven’t filled in my password or that my password doesn’t match (I’ve seen this far too many times). Instead, strive to have a more reliable detection mechanism in place.
  10. Don’t show me an error message about mismatched passwords as soon as I leave the password field to proceed with filling the confirmation field in.

The majority of sites don’t follow these seemingly obvious guidelines. As a result, I often catch myself wondering if the password I’m about to submit will go through or not. That’s actually what motivated me to write this short article. I’m certain that some may disagree with a few of my points, while others may want to add more. Please feel free to do so in the comment section below.

1 Your client itself could be compromised of course (think about keyloggers, for example).

2 Technically speaking, no password system is ever truly secure. But as far as login systems go, these rules should be a good compromise between the need for security and the desire to avoid unnecessary frustration on the part of your users.

Get more stuff like this

Subscribe to my mailing list to receive similar updates about programming.

Thank you for subscribing. Please check your email to confirm your subscription.

Something went wrong.


  1. Nicola Larosa March 24, 2010
  2. thomas March 24, 2010
  3. Antonio Cangiano March 24, 2010
  4. nlo March 24, 2010
  5. nlo March 24, 2010
  6. Zach March 24, 2010
  7. Antonio Cangiano March 24, 2010
  8. Giovanni Bajo March 24, 2010
  9. Antonio Cangiano March 24, 2010
  10. Cindy Compton March 25, 2010
  11. Piervincenzo March 25, 2010
  12. Matt April 1, 2010
  13. Antonio Cangiano April 1, 2010
  14. Matt April 1, 2010
  15. Antonio Cangiano April 1, 2010
  16. Philip Tellis April 12, 2010
  17. andy April 12, 2010
  18. Philip Tellis April 13, 2010
  19. Antonin April 19, 2010
  20. Stefano March 18, 2012

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.