1. 7
  1. 2

    The part about annoying users by rejecting passwords reminded me of when I did tech support for a company that implemented zxcvbn.

    First, you can accept the 1/99,857,412 chance of a false positive and block the user from using the password. This means that for every ~100,000,000 users that sign up to your service, you might annoy one of them.

    It’s not really true that you’d annoy that user, since they don’t know that you lied about the password being pwned (and neither do you; it likely was pwned). More likely, you’ll annoy lots of users signing up, because you’re rejecting most of their passwords.

    I spoke to people who were brought to tears, frustrated that they couldn’t pick a password that satisfied the website that used zxcvbn. Many others were angry, including one, who after many failed attempts to please the password checker, told me that nobody else would have that password because it was the name of his cat.

    I don’t really have a point here, except that you can’t add a restriction, even a good one like “the password isn’t in the Pwned Passwords database”, without annoying people.

    1. 3

      In my experience, using zxcvbn as training wheels to steer users towards better passwords (i.e. by simply displaying the derived “password strength” when creating a new password) works pretty well. Using zxcvbn’s score as a hard restriction is a choice of the implementor, not the library authors.

      1. 2

        I tried to implement zxcvbn for a client once and they begged me to replace it with some “simple rules” like “the password must contain a digit”. I told them that professional ethics wouldn’t allow me to do that, but I could just have no requirements instead since that has equivalent safety.