NIST’s New Password Rules

We have looked at the guidelines for users in creating good passwords, but what are the best practices for the places that make you create those passwords? These would be places like Web sites, corporate networks, and so on. They create rules that are often difficult or annoying, such as “Every password must contain a capital letter, a number, a Mayan hieroglyphic, and a squirrel sound.” But do these rules work? And what rules would be best for maximizing security? That is what NIST (the U.S. National Institute for Standards and Technology) tries to do a new document called Digital Authentication Guideline that is still being written and is in Public Preview, but I found a great analysis by Chester Wisniewski over at Sophos Security: NIST’s new password rules – what you need to know. So while this is not a final document yet, I think there is value in looking at what they recommend.

So, what are the big takeaways from this recommendation?

Favor the User – Make all of your recommendations user-friendly, and when something is burdensome, put put the burden on the password-issuer. This means first and foremost that you stop asking users to do things that don’t improve security. Many of the so-called “best practices” fall into this camp when closely examined. (I’m looking at you, mandatory frequent password changes). What you really want here is voluntary compliance with both the letter and the spirit of your rules. Unneeded burdens will get you subversion instead.

Size matters – Passwords should have a minimum of 8 characters, but you should be allowed to use one of up to 64 characters. That means no longer rejecting passwords because they exceed some number like 12 or 16 characters. And if issuers are doing things the right way this should not matter. Issuers should be storing hashes of the passwords, not the plain text, and hashes will all be the same size regardless of the initial password length. If an issuer says your password is too long, you should be very suspicious that they are storing passwords in plain text, which at this point is simply insane. Issuers should add a “salt” (a random number) to each password, then hash it.

Large character sets – You should be able to use any character in the Unicode set, including Emoji, in creating your password. Again, adding a salt and hashing the result should create a standard hashed result to store. If you are restricted from using certain characters, you should be very suspicious that they are storing plain-text passwords.

Hashing vs. Plain Text – A brief review for people not entirely familiar with hashing. Hashing is the transformation of a given piece of plain text into an encrypted “cyphertext” by the application of an algorithm. There are a number of algorithms out there, that employ measures like Exclusive Or (XOR), block cyphers, and so on, in a recipe that generally includes applying such measures in a certain order and repeated a certain number of times. A full discussion is beyond the scope of this piece, but is not really necessary to get the main point. Some of these algorithms are no longer secure enough to provide real privacy or security, but can be used to validate file integrity, such as the MD5 hash. That is because a useful feature of hashing algorithms is that a single one-bit change in the original plain text produces a completely different hash. Salt is the addition of a random number to the plain text before the hashing is done, which makes the hash more resistant to dictionary attacks, which is when a malicious person creates a dictionary of hashes of known passwords to compare the hash to when they can get a database of hashed passwords. The last characteristic of hashes is that the length of the hash is a constant, and is independent of the length of the original plain text. And it does this by working on the binary code of the plain text, which is all zeroes and ones. When you understand all of this you see why you should be very suspicious about restrictions on password length. The hashing algorithm should never care about password length, and the resulting hash should be the same length no matter what. And when you understand that it works on binary code, you see why it is hard to find a good reason for limiting the characters you can use. At a minimum, every character on a standard keyboard should be allowed, and each character will be encoded as a series of zeroes and ones. The algorithm doesn’t care. And that is why you should suspect that someone is storing your passwords as plain text when you run into length or character restrictions. And if they are doing that, they are incompetent and you should be looking at alternatives, particularly if it is a bank or broker.
NIST says that the passwords all need to be salted, hashed, and stretched. Salting we have already mentioned, but NIST says the salt should be a minimum of 32 bits. Hashing we have mentioned but which algorithms are suggested here? NIST says they must be HMAC, which stands for Hash-based Message Authentication Code, which is essentially hashing with a secret key. Among the algorithms they find acceptable are SHA-1, SHA-2 or SHA-3, although most experts today would not use SHA-1 as it is becoming as insecure as MD5 and is being phased out in things like SSL certificates. This may get changed in the final draft. Finally, there is stretching, which essentially means repeating the encryption process many times to add to the computing burden on crackers.

Check new passwords against a dictionary of known bad choices – We periodically see articles showing the worst passwords in use, and more data comes in all the time from databases that have been cracked. For example, here is an article from The Guardian entitled “As easy as 123456: the 25 worst passwords revealed“. Here is the Top Ten list for 2015, but every one of these was on previous year’s lists as well.

123456

password

12345678

qwerty

12345

123456789

football

1234

1234567

baseball

So, how big a dictionary would this realistically take? Jim Fenton, a consultant on this project, thinks that a dictionary of about 100,000 entries is a good starting point.

Eliminate composition rules – You know, the ones that say you must have one upper case letter, one number, one Mayan hieroglyphic, and one squirrel sound. This results in things like pA55w+rd, which meets most such rule sets but is easily crackable. So is p@55w0rd. Folks, we need to understand this is an arms race, and the folks on the other side are not stupid and can devote considerable resources to cracking passwords. Anyone who thinks “leet speak” is any kind of protection needs to enter the 21st century sooner rather than later.

Eliminate password hints – If your password can be remembered by a hint it is too easy. As Chet Wisniewski points out, hints like “rhymes with assword” pretty much give the game away. And as with Knowledge Based Authentication, this stuff is easy to look up. It does not take a lot of effort to figure out the names of your children and pets.

No more Knowledge Based Authentication – These are the questions you are asked to answer like where you got married or who is your favorite sports team. This stuff is all easily findable, as Vice-Presidential candidate Sarah Palin discovered in 2008. Some enterprising young person looked up her biography online and used that information to answer the questions and get her e-mail account password changed. Then he had complete access and released her e-mails to the world.

No more expiration without a reason – If we want users to choose long, hard to guess passwords, we shouldn’t make them change those passwords unnecessarily. The good reasons for changing a password are 1) it has been forgotten; 2) it has been phished; or 3) your database has been breached. Anything else is simply annoying and probably encourages users to find a way around it.Steve Gibson of the Security Now podcast told a story about a guy who was forced to change his password, and he encountered a policy that the company would remember the last 9 passwords and not allow you to reuse any of them. So he changed his password 10 times, one after the other until he could reuse the password he liked. And the thing is, as long as that was a long and strong password he did not reduce network security by doing this. Now, you won’t find every user being that determined, but what they will likely do is put the password on a post-it note and attach it to the monitor, or add the number 1 to the end, or come up with an easy to remember password that will probably be very easy to crack using a dictionary attack.

No SMS messages for two-factor authentication – Two-factor authentication is awesome, even doing it with SMS is probably an improvement over not doing it at all. The problem is that SMS is not sufficiently secure. One trick that some scammers have been able to employ is convincing a carrier that they are Joe Blow, that they lost their phone, and need a new SIM card. With the SIM card all of your messages now go to them. Number portability is also an attack method, and there is malware that can redirect text messages. And the network itself can be attacked, such as in the SS7 hack which lets malicious hackers read your text messages, listen to your phone calls, and track your phone’s location.

The bottom line in all this is that password issuers need to look at actual evidence in deciding which measures to use, and to apply a reasonable cost/benefit calculus to the problem. And this analysis needs to take into account that passwords are created by and used by human beings. If users find your rules burdensome, they will find a way to subvert them. And if that burden is caused by stupid rules that don’t provide a valid benefit, you will succeed in reducing your security while annoying all of your customers. And that can’t be good.