Handling Password Fields

With the advent of the heartbleed debacle you’ve probably spent a bunch of time changing your passwords. I know I have. Having to update several passwords has opened an old wound: the really really stupid policies and coding behind password fields.

My passwords are generated automatically by my password manager. They’re long random strings containing both cases, symbols, and digits. They’re very secure. Of course a lot of sites don’t like that. They’re too long, or they have symbols the site doesn’t like, or some other fool thing. I saw all these complaints while I was changing my passwords.

Here’s Terence Eden with a hillarious post on entering passwords. He’s got all the problems (and some that are, maybe, just a bit fanciful). Except for the obvious humor, they’re all real and all very annoying. But the worst, absolute worst, is the common practice of not telling you what the password policy is. You try a password and get an error message. You try another and get another error message. It’s like a text adventure game. I know, how about xyzzy1? Eden’s post captures this craziness nicely.

A good general rule, which I subscribe to, is that if there are any restrictions on the password then the site is insecure. That’s because if they’re doing it right—using bcrypt, scrypt, PBKDF2 or something similar—then it doesn’t matter what password you enter2. If you’re not using bcrypt or one of its siblings then it’s almost a certainty that you’re not properly hashing and key stretching so that when your user database is captured it will be an easy matter to recover the passwords.

Eden suggests some rules to reduce user frustration. The first, of course, is state your policy up front so the user doesn’t have to guess. Of course, if you’re doing it right you don’t need any rules because you won’t have any restrictions. Yes, yes that means that users can input stupid passwords but most stupid passwords will pass the normal rules anyway. Password123 anyone?



I tried that one but nothing happened.


OK, if you’re too lazy to deal with variable length inputs, choose a max password size of 1024 or something that no one is apt to actually use. They all get hashed down to the same size anyway so the initial size doesn’t matter. The point is that arbitrary restrictions are a sign of weakness.

This entry was posted in General and tagged . Bookmark the permalink.

4 Responses to Handling Password Fields

  1. Well, there is one reasonable reason (pun intended;)) to restrict characters in password. Imagine a scenario when it is possible to define and/or use a password both in a GUI (e.g., a browser) and in a (e.g. Linux) terminal (this of course does happen sometimes). Now, you’d better not use TAB (ASCII #9) in your password! I heard that (at least in Windows) it is impossible to enter TAB in a text field…

    • jcs jcs says:

      Sure, and we could probably think of other cases where you’d get into trouble having some character or another in your password. The point is, though, it’s the user’s problem. If he can enter the character into the field, just accept it.

      Let’s suppose, to take your example, a user enters a TAB in the terminal and then discovers, “oops that doesn’t work in the GUI.” Call up the terminal and do a password change. Maybe the TAB does work in his GUI and now he’s mad you won’t let him use it.

      You’re right, of course, that the TAB is a remarkably poor choice but why should the site care? If it works for the user, let him have at it. I don’t want to make too much of the point of this: maybe sometimes a restriction is necessary but the general rule holds. Almost always a restriction is evidence that the password is not being handled correctly.

      • Of course – I agree with your point. I just wanted to highlight a (slightly funny IMHO) problem with one particular character.

        But this seems to be really about “do we give the user the power to do great things – but also stupid ones” or “our users are idiots, let’s not allow them to do too many things or they’ll break something”.

        So maybe I was wrong after all with my example. If someone really wants to shoot himself in the foot, let him do it…

        • jcs jcs says:


          But this seems to be really about “do we give the user the power to do great things – but also stupid ones” or “our users are idiots, let’s not allow them to do too many things or they’ll break something”.

          Yup. I come down on the side of letting users do pretty much what they want (password-wise) because even if you insist on rules that try to enforce strong passwords, there’s a certain type of user who is going to use Password1! to meet your rules and still be on the top 100 list.

          My major point, though, takes the view of the user. If you care about having a secure password and you encounter a site that imposes retractions on the password, that’s a warning flag that the part you can’t see is probably insecure.

          All in all, I think we’re in violent agreement.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>