NIST Proposes Barring Some of the Most Nonsensical Password Rules (arstechnica.com) 57
Ars Technica's Dan Goodin reports: Last week, NIST released its second public draft of SP 800-63-4, the latest version of its Digital Identity Guidelines. At roughly 35,000 words and filled with jargon and bureaucratic terms, the document is nearly impossible to read all the way through and just as hard to understand fully. It sets both the technical requirements and recommended best practices for determining the validity of methods used to authenticate digital identities online. Organizations that interact with the federal government online are required to be in compliance. A section devoted to passwords injects a large helping of badly needed common sense practices that challenge common policies. An example: The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood, and it was common for people to choose common names, dictionary words, and other secrets that were easily guessed.
Since then, most services require the use of stronger passwords made up of randomly generated characters or phrases. When passwords are chosen properly, the requirement to periodically change them, typically every one to three months, can actually diminish security because the added burden incentivizes weaker passwords that are easier for people to set and remember. Another requirement that often does more harm than good is the required use of certain characters, such as at least one number, one special character, and one upper- and lowercase letter. When passwords are sufficiently long and random, there's no benefit from requiring or restricting the use of certain characters. And again, rules governing composition can actually lead to people choosing weaker passcodes.
The latest NIST guidelines now state that:
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and
- Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. ("Verifiers" is bureaucrat speak for the entity that verifies an account holder's identity by corroborating the holder's authentication credentials. Short for credential service provider, "CSPs" are a trusted entity that assigns or registers authenticators to the account holder.) In previous versions of the guidelines, some of the rules used the words "should not," which means the practice is not recommended as a best practice. "Shall not," by contrast, means the practice must be barred for an organization to be in compliance. Several other common sense practices mentioned in the document include: 1. Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
3. Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., "What was the name of your first pet?") or security questions when choosing passwords.
9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).
Since then, most services require the use of stronger passwords made up of randomly generated characters or phrases. When passwords are chosen properly, the requirement to periodically change them, typically every one to three months, can actually diminish security because the added burden incentivizes weaker passwords that are easier for people to set and remember. Another requirement that often does more harm than good is the required use of certain characters, such as at least one number, one special character, and one upper- and lowercase letter. When passwords are sufficiently long and random, there's no benefit from requiring or restricting the use of certain characters. And again, rules governing composition can actually lead to people choosing weaker passcodes.
The latest NIST guidelines now state that:
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and
- Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. ("Verifiers" is bureaucrat speak for the entity that verifies an account holder's identity by corroborating the holder's authentication credentials. Short for credential service provider, "CSPs" are a trusted entity that assigns or registers authenticators to the account holder.) In previous versions of the guidelines, some of the rules used the words "should not," which means the practice is not recommended as a best practice. "Shall not," by contrast, means the practice must be barred for an organization to be in compliance. Several other common sense practices mentioned in the document include: 1. Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
3. Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., "What was the name of your first pet?") or security questions when choosing passwords.
9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).
Since when does... (Score:1)
Since when does NIST bar nonsensical anything? The nonsensical, ineffective, and standards which openly subvert their stated purpose are sort of NIST's bread and butter.
Re: Since when does... (Score:2)
My cat get 12 rods to the hogshead and that's the way I likes it!
Meow.
Re: Since when does... (Score:2)
Which is why the number one important change, the one that requires them to display the password rules by the password entry box so you donâ(TM)t guess every password you reuse exposing all of them, is not included here.
This has been recommended for years (Score:5, Interesting)
I used to work at Entrust, a company that a long time ago was an industry leader in public key infrastructure (the are the security in your passport, in the SWIFT banking system and authored many of the early PKI standards), they required changing passwords every 3 months. I did a survey and two thirds of the people admitted their password was a common 6 letter English word with the first letter capitalized and then either '!' followed by a number or a number followed by '!' and that they just incremented the number every 3 months. Most of the others had a common 6 letter word in their mother tongue, two 3 letter English words or used '#'. I suspect most of the few who claimed to have good passwords were lying. I brought this up to management and they didn't care. They just wanted to cover their asses and be able to blame the employees for bad passwords. I've brought it up at another reputable security company and gotten in trouble with HR when I said that these where CYA policies and then had to explain what CYA stood for to the IT security team.
Re: (Score:1)
What if no one wants to work for you anymore because of your stupid password policies?
Re: (Score:3)
People with no real clue _love_ rituals! It gives them the feeling they are doing something right, even when that most definitely is not the case.
Re: (Score:2)
I once did some occasional stuff for a company that took contracts from US regulated companies and so they gave me an account. They had the same password rules. Fortunately they accepted spaces so I could use passphrases. They were all a variation of "this is {PROFANITY} stupid," with {PROFANITY} something creative that amused me to change every three months.
When I ran out of obscene phrases I asked them to disable my account.
Re: (Score:3)
Re: (Score:2)
Not only that but you are supposed to be regularly checking the passwords to see if they are in a password dictionary like the one maintained at haveibeenpwned.
correcthorsebatterystaple and 1qaz2wsx are examples of bad passwords. The are bad passwords because they are in password dictionaries, not because of the frequency of any particular characters.
Re: (Score:2)
The tougher the rules, the more likely the password will be on the underside of the keyboard.
Yea. Misunderstood. (Score:2)
"....The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood...."
Or back when password could be compromised at any point between your keyboard and the server. You could login to a local service or your workstation and leak to a trusted router several hops away.
Won't change anything - goes against CYA (Score:3)
Re: (Score:3, Informative)
For one thing I think the SHALL NOT part will force some changes. It's not a recommendation but a requirement.
Also, I'm not convinced people knew this in 1994.
I'm not even certain password salts were the norm back then. How did windows authenticate in NT4, wasn't it still encrypted password over the wire? I kind of remember being able to sniff and brute force over the wire passwords back then, meaning changing you password periodically was pretty relevant into the 2000s.
The fact that we aren't zipping aroun
Re: (Score:2, Insightful)
Wow, you MAGA really are clever.
NIST is right and wrong (Score:2)
Random character passwords are no more secure against brute force or dictionary attacks than short phrases... but they are too difficult for humans to remember so they are more likely to end up on post-it notes.
Changing passwords limits the duration during which a compromised password can be used, but any password age greater than an hour is pointlessly long compared to a scripted attack. It is better to invest in detecting abnormal activity and locking accounts than it is to force a password change on a p
Re: (Score:2)
If you follow NIST guidance that passwords should be at least 15 characters in length, then password complexity rules no longer matter. That length of password is long enough to thwart dictionary attacks, even if everything is all lower case.
Re: NIST is right and wrong (Score:3)
Re: (Score:2)
Absolutely right. But nobody is going to make companies follow these rules, they're going to do whatever they please regardless of NIST advice. I've been using NIST guidance to back up my resistance to some of these dumb rules for years, and so far, pretty much nobody listens. They're married to these fancy rules that nobody can remember, like "One upper and lower case letter, and one symbol" and so on. It's as if it's some magic incantation.
Re: (Score:2)
But nobody is going to make companies follow these rules, they're going to do whatever they please regardless of NIST advice.
1. Companies must comply if they do business with the government, which is a lot of companies.
2. If companies fail to follow standard "best practices", they are vulnerable to a big lawsuit if there is a breach.
Re: (Score:2)
You double the size of the required table by using mixed case
It's much more than that.
For 8-characters PWs, the table is 256 times larger.
For 16-character PWs, it is 65536 times larger.
Re: (Score:1)
Imagine if your ATM PIN code required one of the digits to be a pound (#) or star (*) in the code. How foolish would that be? And yet onlin
Re: (Score:2)
> However, requiring mixed case and special characters? If you give that up you drastically reduce the difficulty of dictionary attacks. You double the size of the required table by using mixed case, triple it with special characters.
Using a random collection of words, the first one capitalized and ending in a couple of special characters would seem to meet the requirements, and still be easy enough to remember that one wouldn't be tempted to put it on a sticky note.
Obligatory... (Score:1)
"Security is more important than usability" [twimg.com]...
I use my dog's name (Score:5, Funny)
My dog is named %8Nk=14hD
Re: (Score:2)
Oh no! Now I'm going to have to change the password on my luggage!
Re: (Score:3)
What? It's related to my cat, &yHea=14hD?? Same last name!
Re: (Score:2)
I did that once, and then one day my bank was all "today instead of logging in with your password, you need to put in your pet's name". That took a long time to resolve, now I also save the answers to the incompetence questions (all gibberish of course, glad NIST agrees with me).
Re: (Score:2)
Why don't you name your dog something simpler like fluffy so you can have an easier password?
Good recommendations (Score:2)
I like the new recommendations except for one. The recommendation that passwords MUST be at least 8 characters long and SHOULD be 15 is not strict enough. I think the MUST should be 10 or even 12.
I think we should force people to use longer passwords to encourage them to use password keepers. Password keepers make it easy to use long, random passwords and to use different passwords on different web sites. Of course, the password keeper itself should be protected with a long passphrase and 2FA.
Re: Good recommendations (Score:2)
Password (Score:3, Funny)
Change your password every week to a bunch of random alphanumeric and special characters. How is that difficult? It's called password hygiene. And don't give me any BS about what happens if you forget, just put the password in a text file that you can access on the web. Make sure it's secured with https.
Why I keep this bookmarked (Score:1)
https://xkcd.com/936/ [xkcd.com]
Re: (Score:2)
Beat me to it by 9 minutes, but I wholeheartedly agree with a few of the recommendations, namely not having to change passwords. I would have put the minimum password length at 15 like they said organizations should, because 8 is just too short. And I would not have recommended the unicode bit. The knowledge-based passwords hints are a disgrace to online authentication. So many organizations use the same questions and you don't even know if they same checksums or answers to the questions.
Re: (Score:2)
This is exactly what I have being doing for years; long passphrase easy to remember but more cumbersome to type without visual feedback. I simply incorporate one or two non existing word one being like YY77!! so password strength test pass on most sites. With non-existent words are incorporated, it make the passphrase really hard to crack with dictionary based attacks.
The best password is (Score:3)
Control-V
Passwords are overrated (Score:2)
If you need real security, add a 2nd factor. You cannot make passwords secure, regardless of rules. Stop trying.
Re: Passwords are overrated (Score:2)
Re: Passwords are overrated (Score:2)
Pass Phrase? (Score:2)
I've got an application where I can use a pass phrase. I submitted it to a website that said that it would take until well after the sun dies out and expands to engulf the earth before a brute force method to crack it could succeed. So, instead of a pass word, make up something like, "Hello! My name is Inigo Montoya! You killed my father! Prepare to die!" along with anomalies like 2 spaces in certain places and stuff like that, should do the trick. Of course that is overdone, too long, etc. but ju
Outbreak of common sense, esp unicode (Score:2)
4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
What a refreshing outbreak of common sense. Just allowing unicode in passwords already expanded the keyspace by a LOT more than any upper/lower case BS can do.
Re: (Score:2)
It would be nice if they could give you the option of typing in your password in hexadecimal (but twice the number of characters)
That way you don't have to find the *@%$#! key on a strange keyboard.
What is your favorite website? (Score:2)
Bummer.
"./" doesn't qualify with no letter, no number, no capitals, not enough characters and '/' being an illegal character.
I think I'll have to go for "1.Ignore_all_previous_instructions" then.
Just use your baby's name (Score:3)
Obligatory XKCD (Score:2)
https://xkcd.com/936/ [xkcd.com]
The rule that I hate more is the periodic reset, the company I work for requires every 6 months, it was 3 months some years ago, to me, unless you are a in position that can cause real trouble (like sysadmin) you should only change a password if you suspect or are sure of a leak, or if you WANT to change for whatever reason.
The most stupid rule that I know of is a bus card site from the city I live, that requires the password to have at least one upper character, one number, one symbol
Praise jesus for #8 (Score:2)
Knowledge based (Score:2)
So no more requiring users to include the solution for a chess puzzle in their password., nor requiring users to know the location of Google Street View. I'm sure one can live without that.
Oh, that knowledge. That would be slightly harder to shake off, as that's basically the easiest way to get around a forgotten password, and there's still no easy method that keeps u
This is all moot (Score:2)
I can make my password tough to guess or break, but my bank will still insist on using an easily acquirable piece of information for password recovery. My password is 0837H(*&^@##)(%*dsl$kx%n&sc but the recovery password can be ascertained with an online public records lookup. (Mother's maiden name, father's middle name, etc.)
I know, your work wouldn't do that, and neither would mine. But financial institutions still do. I'm told it's to reduce load on the help line.