9

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.

ramatsu
  • 91
  • 1

1 Answers1

13

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

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • 1
    +1 for "If I want my password to be ". – dmuensterer Oct 16 '20 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 :) – rackandboneman Oct 17 '20 at 03:12
  • 1
    So one annoying problem with trying to use 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. – Todd Wilcox Oct 17 '20 at 04: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 '20 at 05:10
  • @rackandboneman Well, any current system that stops you from using ` – dmuensterer Oct 17 '20 at 16:07
  • Yeah, Legacy software was my #1 theory above. Very familiar with the issue, but still somewhat amazed that those systems haven't added front-end security layers in more modern frameworks. Would the middleware be vulnerable? – ramatsu Oct 17 '20 at 19:27
  • Using a hardware password storage module can mitigate the dangers of decryptable passwords, while allowing for the possibility that a company might acquire a system that stores passwords differently. If two companies that use hashed passwords merge and want to unify all of the accounts under one system, that may be difficult if both of the original systems use passwords that were hashed differently. – supercat Oct 18 '20 at 01:45
  • @dmuensterer in a way, displaying a plaintext password in a web app is, while not caterogically wrong, a strong "good reason or no reason" thing :) – rackandboneman Oct 20 '20 at 21:01