America’s National Institute of Standards and Technology (NIST) have recently updated their guidelines on how to handle the most basic and ubiquitous method of authentication, the password. This is important because it sets expectations across the board as to what good password practice looks like.

If I may be unfairly stereotypical, small websites often lack basic security measures like hashing their password database, while large companies enforce myriad arbitrary password rules that hinder more than they help. The large companies sometimes have adherence to NIST guidelines written into their contracts, which will now guide them into good practice. The small websites, well maybe they’ll read Hacker News, or if they get desperate, this post.

Bad Password Policies That Should Never Have Happened, That NIST Now Recommends Against

  • Allowing passwords less than 8 characters long
    This is a softball to start with, most websites and other server operators are good about disqualifying passwords so short and easily brute forced - the equivalent of a combination lock with a single digit.

  • Having a maximum password size less than 64 characters long
    First of all, if a website says your 12-digit password is too long, then be worried, because they could well be saving it as plain text in a database column 10 characters wide, allowing any hacker that can gain access for a moment to walk off with your password with zero effort. Given that proper hashing transforms any password into a fixed-length string, maximum password length should be a very high number. That’s not to say it should be unlimited, as Django developers discovered when multi-megabyte passwords overloaded the web servers that tried to hash them…

  • Allowing horrifically common passwords
    password is 8 characters long, but also the most common password ever used. If you had only one guess at trying to get into a random account, it would be a toss-up whether you entered password or 12345678 as your first attempt. Either way, it’s clearly unwise to let security-deficient users set the nuclear codes to all zeroes use any of the top 1000 passwords.

  • Requiring a lowercase letter, an UPPERCASE LETTER, a digit, an Egyptian heiroglyph and a partridge in a pear tree 𓅂
    Yes, if your attacker knows you are only using the letters A through D in your password, he will find it easier to guess. Yes, there are many weird and wonderful symbols a keyboard can produce. No, users will not remember cKp"AYpHm#M$8+D_, and if you force them to, they will take a permanent marker and scrawl it across their office desk, along with their username.

  • Expiring passwords like a bottle of milk
    Another example of the elegant sports car of theory meeting the dense brickwork of reality. Users have a hard enough time coming up with one decent password. If you make them repeat the process then a hacker with the last few passwords will probably have a flash of clairvoyance when reading boringpw1, boringpw2, boringpw3

  • Giving hints
    Relying on users to offer their future selves a small hint about the password they chose while retaining decent password security is a mistake. When a hacker sees the hints wife's birthday, football team, or the password is chocolate, let’s just say the search space is massively reduced. To return to the combination lock analogy, it would be like writing on the side things like prime number beginning with 1, all even digits, or the combination is 2745.

All in all, NIST merely asks that you avoid making life needlessly difficult for users choosing a password, while stopping them sabotaging their own security efforts in ways that actually matter.

Storing Those Passwords

NIST also recommends storing passwords hashed and salted. This involves generating a random string called a salt, appending it to the plaintext password at setup time, and then hashing that combined string with a strong one-way cryptographic hashing technique. You then save the combined hash, and the original salt, and throw away the plaintext password. You now have a list of passwords that can’t be feasibly turned back into plaintext (because they are hashed), and if your clueless user sets his password to 123456, a hacker with your list of hashes can’t simply recognise the hash value of 123456 that he calculated earlier (so-called rainbow table attack).

There are of course different hashing techniques, ranging from the completely broken and old to the shiny new and safe (for now). You should use a function from the SHA-2 or SHA-3 categories, then make it very slow (computationally speaking) to calculate the hash by running it through a key stretching algorithm, to further discourage hackers trying to check their dictionary of passwords against your stolen hash list.

Or you could store everything in plaintext_passwords.txt, but at least NIST could say “I told you so”.