At the end of August 2024, NIST issued some new guidance documentation (SP-800). Of specific interest is their recommendations around passwords (in SP-800-63B) – because it conflicts with what many organisations actually do, and addresses a few bugbears of mine.
Even with widespread adoption of Multi-Factor Authentication (MFA), passwords are not dead & buried yet. Section 3.1.1.2 of SP-800-63B includes many specific points, so let’s run through them.
In the text below, a CSP is a credential service provider.
Password Length
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.
Most organisations & systems require passwords to be at least 8 characters in length. Few require 15, but with more modern approaches (such as using multiple concatenated words), longer is more appropriate.
2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
Systems which don’t allow long passwords can cause unexpected issues. Especially ones which don’t actually TELL the user that their password has been truncated; the user can be left thinking that they have a nice long password but the system may only be using the first N characters of it. Ouch.
Password Complexity & Composition
3. Verifiers and CSPs SHOULD accept all printing ASCII characters and the space character in passwords.
It never ceases to amaze me how many systems cannot properly handle passwords with spaces in them. Some reject such passwords. Others, even worse, silently terminate the password at the character before the space – another truncated password scenario; you use a multiword password with spaces in, but only the characters up to the first space are used. It seems to work, but in fact it’s only using the first word. Ouch.
4. Verifiers and CSPs SHOULD accept Unicode characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
Allowing Unicode significantly expands the search-space. There are some complexities that come with this, such as the need to normalise, and the need to count Unicode characters as a single character for password purposes regardless of how many bytes they require. Normalisation must take place before hashing, both at the time of setting a password and when testing candidate passwords.
5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
Well where to start. Many systems require quite complex rules along these lines. Some of them even tell you up-front, but not all. And these ones are my absolute least favourite systems; you enter a password, THEN it tells you the hidden rules which you have failed to meet. And on a stressed day, that can all too easily lead to this….
So if you DO insist on complexity rules, tell the users please before wasting their time.
9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).
Taking this one out of order, as it relates to some of the above points. Truncation is a recipe for disaster. Don’t do it.
Password Lifetime
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.
A bit of a change from most systems, maybe. This is a balancing act. By encouraging users to use passwords which are easier to remember but harder to crack (see XKCD from 2011), the need to change them is reduced. Educating users not to use their credentials on public or shared machines minimises the risk of keylogging.
Forcing users to change their passwords leads to increased levels of helpdesk calls (when they forget the new one), and greater levels of stress all round. Clearly, if there is any suggestion of compromise, then a change is required. But not otherwise.
7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
Seems like common sense to me, but still found in many systems. It is perhaps more forgivable within a closed environment not exposed to the Internet at large.
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.
These things are too simple to guess. Unless the user uses random replies, in which case they are going to either be forgotten or written down. Avoid.
Rejecting Passwords
When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords. The entire password SHALL be subject to comparison, not substrings or words that might be contained therein. For example, the list MAY include but is not limited to: Passwords obtained from previous breach corpuses; Dictionary words; Context-specific words, such as the name of the service, the username, and derivatives thereof.
Many systems check for specific substrings. This is counter to the new guidance.
Again, this is a balancing act. Any sane system will rate-limit password attempts, with temporary (short-term) blocking of attempts after a number of failed attempts, and often a longer-term blocking after a higher limit of failed attempts is reached.
The blocklist needs only to defend against passwords likely to be tried before reaching an attempt limit.
Of course, systems which do not rate-limit are asking for trouble with a capital T.
Maybe we, as security professionals, could take the time to explain to system owners and suppliers the rationale behind this guidance, and remove some of the user frustrations from future systems?
Gânduri Eclectice - Eclectic Thoughts 