Validating new passwords
Much research has gone into the efficacy of many of our so-called “best practices” and it turns out they don’t help enough to be worth the pain they cause. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.) Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.” Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!This is great advice, and considering that passwords must be hashed and salted when stored (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length.At the same time, the computing power available for password cracking just gets bigger and bigger.
That’s right, the United States National Institute for Standards and Technology (NIST) is formulating new guidelines for password policies to be used in the whole of the US government (the public sector). Because the policies are sensible and a great template for all of us to use within our own organizations and application development programs.
The explanation is simple, one has lots of accounts, several email addresses (for essential business, for spam etc.).
Why bother to create each time new passwords and keep them in mind.
Anyone interested in the draft specification for Special Publication 800-63-3: Digital Authentication Guidelines can review it as it evolves over on Github or in a more accessible form on NIST’s website.
For a more human approach, security researcher Jim Fenton did a presentation earlier this month at the Passwords Con event in Las Vegas that sums up the changes nicely.