Jump to content
Sign in to follow this  

NIST Security Guidance Was Wrong

Recommended Posts


NIST Analyst: Our Security Guidance Was Wrong (August 7, 2017)

"Much of what I did I now regret," said Bill Burr, who in 2003 wrote a National Institute of Standards and Technology (NIST) publication that offered advice about creating strong passwords." That advice, which was widely relied upon, did little for security and "actually had a negative impact on usability." NIST has published a new version that reverses most of the old guidance including frequent changes, special characters and numbers and capitals. The new 8-page SP-800-63 advises using long passwords that are easy to remember, and changing them only if there is evidence they have been compromised. Explaining the root cause of the earlier misleading guidance, Burr explained he would have liked to have empirical evidence showing effectiveness and usability of passwords but was unable to find it.



New NIST Security Guidelines

Share this post

Link to post
Share on other sites




Hate silly password rules? So does the guy who created them


Password rules followed by millions of users for over a decade turn out not to be based on any real-world data.

The man who drew up widely-used password rules that are now regarded as wrong regrets ever having created them.

f you've ever wondered why you're forced to pick hard-to-remember passwords with a mix of uppercase, lowercase, numbers, and a symbol -- and then asked to change them every month -- it's probably because a developer somewhere followed guidance from a 2003 document by the US National Institute of Standards Technology (NIST).

That eight-page document 'NIST Special Publication 800-63. Appendix A' was written by Bill Burr, now a retired 72-year-old former manager at the institute.

"Much of what I did I now regret," Burr told The Wall Street Journal.

Also: 13 technologies that are safer than passwords | This cheap password-stealing malware just added to your security headaches | Cyberwar: A guide to the frightening future of online conflict

NIST finalized a rewrite of the password management guidelines in June, reversing many of the recommendations contained in the document he wrote.

It did away with recommending periodic password changes and password complexity requirements, while introducing a requirement to check that new passwords aren't compromised or commonly used, like '1234567' or 'password', which always turn up in breaches as the most commonly used passwords.

As the revised document notes, analyses of exposed passwords, which now number several hundred million in the haveibeenpwned database, show rules around complexity and changing passwords don't produce the benefits they were thought to, yet make using systems terrible.

For example, a user inclined to choose 'password' might well choose 'Password1' if required to include a number and uppercase letter. Meanwhile, periodic password changes can make them difficult to remember for those needing access to dozens of systems, who might then waste time requesting a password reset whenever they've forgotten them.

Burr, a former mainframe programmer for the Army, told the paper he did actually want to create password guidance based on real-world passwords, but there wasn't much available in 2003. He even asked NIST computer admins to look at real passwords on their network but was knocked back.

As a result, he leaned largely on empirical data in a computer password security whitepaper from the 1980s.

Under the new guidance, admins responsible for verifying newly created password are advised to check them against passwords exposed in previous breaches, dictionary words, receptive and sequential characters, and words containing the name of the user or service.

The only time that admins should force a change now is if there is evidence a password has been breached. And to support longer random passwords, it advises that admins should let users paste their password in, backing the use of password managers.

The guidance also addresses password length, suggesting users be required to pick one that is at least eight characters in length, while the system should support passwords at least 64 characters in length.




Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.