Slashdot (RSS Feed) on Nostr: NIST Proposes Barring Some of the Most Nonsensical Password Rules Ars Technica's Dan ...
NIST Proposes Barring Some of the Most Nonsensical Password Rules
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).
<a href="http://twitter.com/home?status=NIST+Proposes+Barring+Some+of+the+Most+Nonsensical+Password+Rules%3A+https%3A%2F%2Fyro.slashdot.org%2Fstory%2F24%2F09%2F27%2F0021240%2F%3Futm_source%3Dtwitter%26utm_medium%3Dtwitter"; rel="nofollow"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>;
<a href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fyro.slashdot.org%2Fstory%2F24%2F09%2F27%2F0021240%2Fnist-proposes-barring-some-of-the-most-nonsensical-password-rules%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"; rel="nofollow"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>;
https://yro.slashdot.org/story/24/09/27/0021240/nist-proposes-barring-some-of-the-most-nonsensical-password-rules?utm_source=rss1.0moreanon&utm_medium=feed
at Slashdot.
https://yro.slashdot.org/story/24/09/27/0021240/nist-proposes-barring-some-of-the-most-nonsensical-password-rules?utm_source=rss1.0mainlinkanon&utm_medium=feed
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).
<a href="http://twitter.com/home?status=NIST+Proposes+Barring+Some+of+the+Most+Nonsensical+Password+Rules%3A+https%3A%2F%2Fyro.slashdot.org%2Fstory%2F24%2F09%2F27%2F0021240%2F%3Futm_source%3Dtwitter%26utm_medium%3Dtwitter"; rel="nofollow"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>;
![https://a.fsdn.com/sd/twitter_icon_large.png"></a>](https://a.fsdn.com/sd/twitter_icon_large.png"></a>){kind=link}
<a href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fyro.slashdot.org%2Fstory%2F24%2F09%2F27%2F0021240%2Fnist-proposes-barring-some-of-the-most-nonsensical-password-rules%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"; rel="nofollow"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>;
![https://a.fsdn.com/sd/facebook_icon_large.png"></a>](https://a.fsdn.com/sd/facebook_icon_large.png"></a>){kind=link}
https://yro.slashdot.org/story/24/09/27/0021240/nist-proposes-barring-some-of-the-most-nonsensical-password-rules?utm_source=rss1.0moreanon&utm_medium=feed
at Slashdot.
https://yro.slashdot.org/story/24/09/27/0021240/nist-proposes-barring-some-of-the-most-nonsensical-password-rules?utm_source=rss1.0mainlinkanon&utm_medium=feed