I get that what comprises a good password is a bit of a moving target and not everyone agrees - just run a password through a number of checkers to see how it is rated differently depending on the criteria.

But a couple of things seem like safe bets and are widely acknowledged - length (as a method of achieving entropy, famously covered here: https://xkcd.com/936/), and size of character set, which doubles the number of possible combinations with each additional character.

So WHY DEAR GOD do some sites insist on limiting passwords to 8-16 characters, and/or disallow special characters? One example is WA state's GoodToGo toll road website, which does both.

This feels like it's one of three things, two of which are bad:

  1. Developers using antiquated frameworks that impose this last-millenium restriction;

  2. Developers still subscribing to the theory that long passwords are bad because they are hard to remember;

  3. Some cutting-edge understanding of password security that makes this an actual best practice that I have just never heard of and can't comprehend.

I'm hoping that this is just fading away, but I keep running into it. We need a public shaming site that lists sites that do this, to force them into adapting reasonable password form practices.


1 Answer 1


There are a couple reasons:

  1. Legacy software

    You may not know, but the vast majority of financial data today are processed on IBM mainframes, running applications written in Cobol and not updated since the last century. IBM already have provided way better security to the mainframes, but as there are still businesses running Windows XP in the desktops, not everyone is using the new functions.

  2. Passwords in the clear

    Yes, they exist. Some places store password in the clear, and the password field is something like PASSWORD TEXT(16). This limits the allowed size of the password.

  3. Sanitization of the password

    Some developers sanitize the input, and that's good. But not so when the input is a password. If I want my password to be <script>alert('XSS!')</script>, what's the problem? If everything goes right, that value is going to be salted and hashed. But some people think special chars on a password will break their code, so they break your password instead.

  4. Server-side encryption

    The above is true here too. Some places encrypt the password with reversible encryption, and no matter how strong is the encryption, it's a terrible idea. Passwords are to be salted and hashed, anything else is wrong. But to prevent special chars breaking something, they disallow them. The 16-char limit is also because of this. If they are using a 128-bit key, the password must fit a 16-byte "packet" to be encrypted.

We need a public shaming site that lists sites that do this

Something like The Plaintext Offenders...

  • 1
    +1 for "If I want my password to be <script>alert('XSS!'), what's the problem?</script>". Oct 16, 2020 at 18:47
  • @dmuensterer semi-lazy programming - someone might simply have built a sanitation function that restricts the character set on any non-fulltext input severely. And applied it to the password too. Used to be not such a terrible practice in pre-Unicode times :) Oct 17, 2020 at 3:12
  • 1
    So one annoying problem with trying to use <script>alert('XSS!')</script> as your password is when the site has a filter for XSS, SQLi, etc. between the client and web servers/service that processes the password field in the form data the same way as the other fields. If you put anything that looks like XSS or SQLi in the password field, it can get rejected before the web server even sees it. BUT, that has nothing to do with the question at hand. Oct 17, 2020 at 4:09
  • @ToddWilcox Surely you wouldn't apply XSS injection checks to absolutely every field? You wouldn't be able to send basically any binary files to the website.
    – l0b0
    Oct 17, 2020 at 5:10
  • @rackandboneman Well, any current system that stops you from using <script> in your password is clearly doing something wrong. There are methods in almost any programming language to convert HTML entities so there is really no excuse. Oct 17, 2020 at 16:07

Not the answer you're looking for? Browse other questions tagged .