Extracts from three other posts:
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.
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?
- 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.
- 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.
- If your passwords are not hashed, it’s a bug.
- 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…
- If you allow people to use a password of less than 12 characters, it’s a bug.
- If you do not encourage people to select a unique password for your service, it’s a bug.
- 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.