Why do some sites enforce low-security passwords? [duplicate]

Question

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.

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...