Blog | Admin | Archives | Random | Recent | Thanks
    • Commute
    • Meat, bread, and succotash.
    • Happy Easter from the Isle of Wight!
    • Martenitsas for Spring

On Password Restrictions

Websites should list their password restrictions on their login pages. Sometimes I run into the following problem:

I try to use a password generated by my “standard model” — ie, a standard prefix depending on the nature of the site and some salt determined by the website itself. However, some sites have stupid rules on their password requirements. In real life, I have encountered a wide variety of password requirements:

  • A requirement of an exactly 6-character password
  • A prohibition on “special characters” like any of !@#$%^&*()+=></?{}[]|\/.
  • A requirement for a special character that happens to be one of !@#$%^&*()
  • A requirement for numbers, uppercase, and lower case in the password
  • A requirement for two sets of letters and numbers in the password — ie, fit the regex /([a-zA-Z]+[0-9]+){2}/

When my standard model password doesn’t fit into one of the more esoteric requirements, I have to modify it to fit. Fortunately, I find that on this subject at least, I tend to think the same way over time, so, given the standard model and a set of constraints, I will usually come up with the same password. However, it is uncommon for websites to list their password constraints on the log-in page. Therefore, I will usually try the standard model password first, and only when that fails twice (in case I mistyped the first time), and I’m down to one more try, do I realize that this website might be “special.”

Then I have to go to the trouble to find out what the password requirements are. This is not difficult — usually it involves clicking the “sign up button” and reading a little bit — but it does take some time and it is very annoying. Listing the password requirements at the login screen would make for a much better user experience (since it is so easy to find this information, not displaying it on the login screen can’t be interpreted as a security measure either).

Of course, the real solution is for websites to get rid of their inane password requirements, so I never have to deviate from the standard model.