NIST Proposes Barring Some of the Most Nonsensical Password Rules (arstechnica.com)
- Reference: 0175140755
- News link: https://yro.slashdot.org/story/24/09/27/0021240/nist-proposes-barring-some-of-the-most-nonsensical-password-rules
- Source link: https://arstechnica.com/security/2024/09/nist-proposes-barring-some-of-the-most-nonsensical-password-rules/
> Last week, NIST released its second public draft of [1]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 [2]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).
[1] https://pages.nist.gov/800-63-4/sp800-63b.html
[2] https://arstechnica.com/security/2024/09/nist-proposes-barring-some-of-the-most-nonsensical-password-rules/
This has been recommended for years (Score:4, Interesting)
The last NIST publication on shared secrets (passwords), explicitly spelled out that it was a bad idea to have mixed case, symbols and numbers. Every security specialist worth minimum wage has known for 30 years not to require passwords that are hard to remember and only in the case of compromise to force password changes.
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:2)
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:2)
I suppose you will be shocked to hear, then that Entrust just lost their webtrust and their certificates are no longer going to be trusted by browsers any longer...
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)
Everyone should have known this for 30 years but companies want to be able to blame the customers or the employees for any breach. Having a weak passwords makes it easier to pass the blame and Cover Your Ass.
Re: (Score:2)
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
Poo emoji smilie face interracial gay couple (Score:1)
The perfect password.
Re: (Score:1)
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:2)
I was surprised they still think the acceptable character set "should" include all of printable ASCII instead of demanding it. So many systems which can't take semicolons, quotes or percents, because they still have database injection concerns they should have fixed twenty years ago.
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.
Obligatory... (Score:1)
[1]"Security is more important than usability" [twimg.com]...
[1] https://pbs.twimg.com/media/FUvCit6WAAEetPU?format=jpg
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:2)
What? It's related to my cat, &yHea=14hD?? Same last name!
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)
Unfortunately there are still old systems out there that cap out at 8. I used to do work for a utility and they had a system for syncing passwords between internal systems when you reset on. Passwords had to be exactly 8 characters. No more, no less. And only a couple of special characters were allowed. This was due to an old system in the mix that ran half of the entire place. I suspect the US gov has plenty of antiquated systems that is preventing NIST from making something over 8 characters a must.
Password (Score:2)
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)
[1]https://xkcd.com/936/ [xkcd.com]
[1] https://xkcd.com/936/
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.
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.
Since when does... (Score:2)
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.