The National Institute of Standards and Technology (NIST) has issued a new draft of its Digital Identity Guidelines. The Special Publication, 800-63-3, includes sections that cover Enrolment and Identity Proofing Requirements, Federations and Assertions guidelines, and Authentication and Lifecycle Management.
While each of these documents are helpful in many regards, the one that will impact the security industry with the broadest reach is the Authentication and Lifecycle section. This section has some very advanced, yet timely guidance about passwords, or as NIST likes to call them, “Memorized Secrets”.
To quote the document directly (in which I have bolded three key items):
- When users create and change memorized secrets:
- Clearly communicate information on how to create and change memorized secrets.
- Clearly communicate memorized secret requirements.
- Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization.
- Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets.
- Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.
- Provide clear, meaningful and actionable feedback when chosen passwords are rejected (e.g., when it appears on a “black list” of unacceptable passwords or has been used previously). Advise users that they need to select a different secret because their previous choice was commonly used.
In case that paragraph did not make your eyebrows go all the way up to your hairline, NIST now recommends that we no longer force periodic password changes and we no longer should force complexity requirements. In the appendix in the same section of the document, the strength of “memorized secrets” is explored in a beautifully concise and accurate manner.
Folks like Graham Cluley, Per Thorsheim, and many others have been promoting these ideas for years, and it is as if NIST has not only listened; they heard!
I have to admit that even I was late to this party, and once I changed my view, I have had a hard time convincing the old password stalwarts of the new paradigm now codified by NIST. I plan to post a framed copy of this new model at my desk as soon as it is in its final published form.
What do you think? Would your staff prefer to make one long password that they only have to change if there is a compromise, or would they still prefer the complexity and forced change requirements that have failed us in so many ways?
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
18 comments on “New NIST guidelines banish periodic password changes”
A related story, this time from the British Government's Cyber Security Centre.
NCSC also released a piece aligned with the NIST guidance back in 2016 (https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach):
"Most administrators will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user (who is likely to choose new passwords that are only minor variations of the old) and carries no real benefits as stolen passwords are generally exploited immediately. Long-term illicit use of compromised passwords is better combated by:
•monitoring logins to detect unusual use
•notifying users with details of attempted logins, successful or unsuccessful; they should report any for which they were not responsible
Regular password changing harms rather than improves security, so avoid placing this burden on users. However, users must change their passwords on indication or suspicion of compromise."
You would have to enforce a minimum number of characters for a passphrase I think unless there is compulsory 2FA. I noticed that TrueCrypt recommended a minimum of 20 characters, so I've always considered 20 characters as my personal minimum for a passphrase. But many websites won't accept longer than 16 and there's even one that only accepts 10 characters (Virgin Mobile).
It depends. If they use an appropriate hashing algorithm then 20 characters is overkill. Using a 20 character password might be very weak if the developers have designed their systems badly!
If I were to design a piece of software I could make an 8 character password more secure than your 20 character password. It all depends on the implementation and whether effective salting is used alongside a decent iterative count.
But I'm pleased to hear that you use a 20 character password (because you don't know how badly designed the websites you use are) but to be honest if you're using a password manager (which you should be doing) then my recommendation is to use a 40 character password with the full ASCII character set (numbers, mixed case, symbols).
No 8 character password is secure. They have rainbow hash tables that almost instantly crack them once the hash is in hand. And more and more sites are having their hashes stolen. It is far more common than It departments want to admit. Any password 10 characters or less is basically useless.
So if 'Puppy123' can be used today – why won't the users use 'Puppy123' in the future too? The only difference is, that they will keep that pw for years and years… And btw, it's the same pw they use for FB etc., so it's perfect for the users and the hackers.
Apparently NIST thinks, that the users are willing to make something more complex just for the fun of it… And if I have a passphrase of 25 characters – do I REALLY want to type that everytime I leave my workstation? When I go to pick up a print? Naah… So I just don't lock it as often – maybe at the lunch break… But maybe that will be the next recommendation from NIST: Do not lock your workstation when you leave it… LOL
Thanks for the comment.The NIST documents also advise a check of "disallowed" passwords at the password creation time, so Puppy123 would probably be disallowed.
How long does it take to type a 25 character password? The extra length is worth the effort.
I lock my workstation to prevent my cat from altering my documents (although, she has been known to type some insightful prose as she prances across the keyboard!) Cheers!
I really dont understand how you can post this with NO mention of what is required to actually have this policy
Like what? Some kind of secure password managment platform? LastPass / CyberArk / BeyondTrust etc etc will relieve you of some currency to solve this problem.
I think it would be extremely useful to have some statistics supporting this change in recommended policy. I believe it to be safer, but my experience and belief would never be a valid argument unless I had the numbers to back up the assertion.
Great information as always Bob. Thanks for posting this unexpected and interesting new information.
Choosing Secure Passwords, by Bruce Schneier
Schneier: The best way to explain how to choose a good password is to explain how they're broken. The general attack model is what's known as an offline password-guessing attack. In this scenario, the attacker gets a file of encrypted passwords from somewhere people want to authenticate to. His goal is to turn that encrypted file into unencrypted passwords he can use to authenticate himself. He does this by guessing passwords, and then seeing if they're correct.
One upper or lower-case letter or digit holds 62 = 10**1.79 choices. 12 letters holds 10**21.5 choices. If chosen randomly, a brute-force attack checking 100 million combinations per second would take about 10**13.5 seconds = 10**6 = 1 million years. A 12 letter/digit combination is perfectly safe if chosen randomly by a password manager.
Schneier recommends the abreviated passphrase technique to memorize the password for use with the password manager. Of course, for a personal workstation, no colleague can run that sort of attack, so even a 4-6 character password is OK, unless it is your birthday.
How to downsize security by governmental advice…
@ Andrew Garland : That "may" be True in 2014 but it easier to break a complex password now. For example, with the windows hashing algorithm ( MD4 ) you can test 8 billion passwords/s with a K80 GPU. Thanks to AWS you can have 1h oh an 8-gpu system to test up to 64 GHash/s for 15$. That allows you to break a 7-char full ascii password in one hour.
cf : https://hashcat.net/forum/thread-4509.html
cf : https://aws.amazon.com/fr/ec2/pricing/on-demand/
Taking this great passphrase recommended by the Nist : "ChoosingSecurePasswords" with 23 chars is equivalent to take a 9 char full ASCII password because of the few number of word in english. People must add special chars into their passphrases to add entropy. A powerful hacker group (or a government) should be able to break it in less than 10minutes.
cf : https://password.kaspersky.com/fr/
( I consider one million word to cover word for an upcase first letter )
Nevertheless, using a good passphrase is a good practice that should widely adopted.
So simply put – not changing passwords regularly in conjunction with less restrictive password generation rules is supposed to encourages a user to create a strong password in the first place and to reduce the formation of bad habits by not having to regularly change them – nice in theory, in reality mmmm we will see password policy enforcement systems would have to enforce a minimum rather than restrict to a minimum.
This type of scenario would need all on line systems to get on board with this, there are many social media services and even on line banking brands that enforce restrictions on password length and characters able to be used which beggars belief sometimes.
It will also need a change to the PCI DSS requirements which currently require regular password changes for in scope systems or do NIST acknowledge that these would be an exception to the rule.
This is true, but is missing some crucial context. The draft guidelines only allow passwords ("memorized secrets") to be used as a single authentication mechanism when there is no requirement to link the user to a specific real-life identity and personal data is not made available. In other words, if you create an application with user accounts but don't really care how the accounts relate to real people and don't collect personal information with the accounts, you can use password authentication and you don't need to force periodic password changes.
But when user accounts do need to be linked to real-life identities (or when personal data is collected), a password is not an acceptable means of authentication; multi-factor authentication must be used. One of the factors may be a password (which doesn't need to be changed periodically).
There are, of course, lots of sites, systems, and applications with user accounts that are linked to real-life identities which are protected only by a password. They don't follow the NIST guidelines, so NIST advice on whether to require password changes for them is irrelevant.
I do not agree with this.
An end-user will most definitely never know that their account or password is compromised.
Depending on an administrator to monitor and notify users as to when they should change their password is impractical.
Think of this scenario:
A user is using, say a PC or Mac with a exploitable vulnerability.
A hacker has gained access to the system and has exploited local privilege escalation vulnerability and got the user's account compromised. In future, the system might get updated but the hacker might be still holding on to the hacked account credentials.
Who is in fault in here? Who will be monitoring such actions?
If everyone follows NIST, it will make it much easier for hackers, both in the wild and government agencies to exploit an account forever without leaving any trace.
This is counter-intuitive. Do not fall into the trap…
My two cents
(with a little ad at the end, sorry)
Having a password manager that can generate and auto-fill a random password for each site, combined with 2FA, eliminates these weak password problems. This solution is also the simplest for users, and it gets rid of the need to change passwords frequently. NIST would be proud.