1. 32
  1. 24

    This article starts by using an example of 8 “bad” password rules, but by the end of the post, Jeff ends up suggesting 5 of the 8 anyway. This post really should have been called “special character requirements are bullshit.”

    I’d be willing to bet that a future version of Discourse will also disallow using your previous password as well. Then we’ll get another password blog post talking about how hard passwords are and how we need more rules for passwords. Experience is a funny thing.

    1. 17

      The article could have been summed up by just linking to one of the many NIST guidelines recap such as the one he himself links to in the article.

      The blogpost itself is just yet another subset of those guidelines anyway:

      • 1. Password rules are bullshit - 800-63-3 specifies “Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types)”
      • 2. Enforce a minimum Unicode password length - “Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. […] Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well.”
      • 3, 4 and 5 - “verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to): Passwords obtained from previous breach corpuses, Dictionary words, Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’), Context specific words, such as the name of the service, the username, and derivatives thereof.”

      In addition to that, 800-63-3 also suggests not forcing the password to be changed periodically and forces proper storage on the backend (using a large number of iterations of hash+salt and suggesting HMAC), among many other things (it also has its own chapter on TFA, which is something more services should offer)

      1. 2

        Indeed. The NIST standards are quite good, and should be used unless there is a very good reason not to use them.

      2. 11

        The thing that bothers me the most is how some sites enforce a small maximum length. For example, my bank’s site doesn’t allow passwords over 14 characters. Since I use a password manager I would have liked to make one that is much longer.

        1. 1

          Unfortunately a lot of those odd rules are driven by legacy systems that just don’t allow longer passwords (or even passwords with anything other than alphanumeric characters, quite often not even distinguishing between upper and lower case).

          The support site of one large software vendor is like that - no passwords longer than 8 characters, etc. Of course, the support site use the vendor’s own software, but obviously a pretty ancient version.

        2. 6

          we missed two common cases that you really have to block: password equal to username

          But why? If the user wants to be dumb, they’re going to be dumb. I mean, why not also require users to provide their twitter handle and then monitor their twitter feed to make sure they don’t post their password there? Is that also a mandatory requirement?

          1. 5

            I’m pretty happy with https://github.com/dropbox/zxcvbn to show password strength instead of asking for a special requirement.

            1. 3

              Or just let users use whatever password they want.

              If they use an insecure password, then they shall suffer the consequence of their choice.

              1. 2

                What really grinds my gears is forced password expiry. My bank has me change passwords every 6 months, and has those stupid character validation puzzles.

                1. 1

                  The social security website also does that. It’s comically frustrating, since I only every log into it about once per year.