The solution to password guessability is this…

Extracts from three other posts:

Password Cracking in a Nutshell

The solution to guessability – even via brute force – is to get users to choose unguessable passwords; for that [see extract below].

And those passwords that they choose must most certainly be defended with the best algorithms possible on the server side to help keep them economically unguessable, hence bcrypt() or PBKDF2 implemented by security-aware developers.

I am no longer convinced that it is possible to wean people away from the method of reusable passwords, and fear that to do so may in other ways be unwise.

…I could make three password guesses per second…

There’s a pendulum that swings from structured-guessing to brute-force, and I think we’re on the return path at the moment; the complementary solution to widespread adoption of bcrypt() and PBKDF2 is to fix the user password management problem.

For me that means:

  • adoption of long pseudorandom passwords; plucking a number out of the air I go around telling people to use 16-character random mixed-case alphanumerics with punctuation, which are clearly untenable for human use especially when you…
  • change your passwords on a schedule – once a quarter, once a year, whatever the schedule it’s in case someone has picked specifically your ciphertext to break and is throwing a few thousand bucks’ worth of AWS and Hashcat at it specifically – so you need to change before their likely time-to-break is exceeded; because this is all such a pain you will need to…
  • use a decent password management tool like 1Password, PasswordSafe, whatever, so you can stop whining about how long the passwords are and how hard it is to choose and change them because most of the work is done for you; and finally you need…
  • user education and motivation. But you knew that already didn’t you?

And finally: seven basic rules for developers setting up password systems

  1. If any part of your user interface or code truncates password plaintext input at a length of less than 255 characters, it’s a bug.
  2. If you can’t cope with password plaintexts that contain SPACE and TAB characters (update: or if you impose any charset restrictions) it’s a bug.
  3. If your passwords are not hashed, it’s a bug.
  4. If you’re hashing your passwords with anything other than Bcrypt, it’s a bug; bcrypt() maxes out at 72 character passwords, but that’s not your fault…
  5. If you allow people to use a password of less than 12 characters, it’s a bug.
  6. If you do not encourage people to select a unique password for your service, it’s a bug.
  7. If you do not encourage people to use passphrases, it’s a bug.

Yes, the rules are opinionated. They are even biased and make sweeping assumptions. They don’t even address issues like UNICODE. But if you address these seven points in every application in the world, you’ll make password cracking a phenomenally tougher job.

5 Replies to “The solution to password guessability is this…”

  1. Crazy idea: Why not cross-check the credentials against well-known websites before accepting them? Any successfull authentication = unusable credentials. A little server-side validation could easily do this. Validating the email address before setting the password would prevent (at least the most obvious form of) abuse.

      1. Latency not perceivable if properly implemented on the server, but you have a point regarding leakage. It would require trust in the 3rd party apps, which I certainly don’t have, since I know how the industry works.

        Oh well, nothing like authenticating against our own personal identity provider… 😉

Leave a Reply

Your email address will not be published. Required fields are marked *