Password sensibilities...

Finally, some password sense! NIST has released some updates for password verifiers (SP 800-63B). While this isn't everyones cup of tea, it is nice when things like this come out to with discussions around security best practices.

Highlights

Some highlights from section 3.1.1.2 and my thoughts...

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.

This should already be in place.

2. Verifiers and CSPs SHOULD permit a maximum password
length of at least 64 characters.

This seems slightly silly. Passwords should not be stored in plaintext. If required, their hashes should be stored and those will use a fixed amount of space. Now, if the max length needs to be limited to prevent some denial of service, that would make sense, but set the length to 1000 characters.

3. Verifiers and CSPs SHOULD accept all printing ASCII
[RFC20] characters and the space character in passwords.

Yes! Once again, passwords should not be store plain text. So if the passwords are being hashed, then the characters shouldn't matter!

5. Verifiers and CSPs SHALL NOT impose other composition
rules (e.g., requiring mixtures of different character 
types) for passwords.

100 x Yes! Making passwords harder for people to type and impossible for them to remember doesn't make more secure 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.

1000 x Yes! Forcing periodic password changes forces people into bad habits.. (e.g. $uperP@ss01, $uperP@ss02, etc). Only change when required!

7. Verifiers and CSPs SHALL NOT permit the subscriber to 
store a hint that is accessible to an unauthenticated 
claimant.

Why was this even a thing? If I have to use this, just send me through the password reset process.

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.

Awesome! I no longer have to make up random crap and store that crap. Once again, if I can't remember what I entered, I'm headed for the password reset process.

9. Verifiers SHALL verify the entire submitted password
(i.e., not truncate it).

This should really go without saying. Once again, hash the password and verify the hash!

Verifiers SHALL allow the use of password managers. 
Verifiers SHOULD permit claimants to use the “paste” 
functionality when entering a password to facilitate 
their use.

I was shocked when a company I worked for disallowed browser integrated password managers, forcing a person to copy the password to the clipboard (which is visible to all applications) and then to the password field. Now I know this doesn't exactly say "browser integrated password managers", but if it's not easy... people will not use it.

Email SHALL NOT be used for out-of-band authentication because
it may be vulnerable to:

 -  Accessibility using only a password
 -  Interception in transit or at intermediate mail servers
 -  Rerouting attacks, such as those caused by DNS spoofing

Email is easy to use and easy to abuse. While hopefully, an email user is using MFA / passkey / OTP to login, but there is no guarantee. And since DNSSEC and SMTPS are not ubiquitous, interception of the out-of-band authentication is possible. Although allowing some to login via a link in email, is easy... no tech experience required. :/

Section 5.1.1 even covers how browser cookies should be used for session maintenance.

Conclusion

Now I don't expect the password silliness to change over night. But now there is a government document that companies can refer to as "best practices".