Note: I previously wrote about passwords and how some changes in the industry had occured here - link here
Credit: Thanks to @blackroomsec for bringing this up
Passwords have been around IT systems since time immemorial. As times go by, technology and its practices experience a laggard in modernizing its SOP's. In this article we look into the proposed NIST standards, specifically zooming into password practices.
One of the key objectives I am writing this article is to provide awareness to the general cyber folks, especially those who are performing audit or being auditors. Many situations I have encountered where (especially in regulated environment), antequated cyber security practices are still being preached without cognizance to factor of risk or understanding of technology evolution.
Understand that as technology and risk factors evolve, so do practices surrounding controls and implementation.
In this article, I draw your attention to the NIST 800-64-3 (ipd) which is the 2024 revision of the document, currently in Initial Public Discussion mode called the Digital Identity Guides. The last revision made to this document was on 2020. In one of my previous article (link above), I wrote about industry standards, moving away from old practices.
These excerpts are taken from Section 3.1.1.2 Password Verifiers
-
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 requirement is pretty standard. Shall implies mandatory while Should indicates desired/recommended. Critical systems should move to a minimum of the desired requirements. With the advent of password managers, these requirements are rather easy to meet.
-
Verifiers and CSPs SHOULD permit a maximum password length of at least 64
characters.
Now this will be a challenge for current systems. Even online banking systems today (for some reason) limits the length of the password to something arbitrarily low. Longer passwords take longer time to crack.
-
Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the
space character in passwords.
Rather straight forward requirements, most current and even rather old systems can meet this requirements.
-
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.
This will be a challenge since the earlier requirement 3 was already a de facto standards. This allows non-standard ASCII characters (and some even use emoji) for passwords, which increases the difficult of cracking passwords.
-
Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring
mixtures of different character types) for passwords.
This has been a sore point with passwords. Password complexity gives an illusion of strong password, however from a password cracking perspective, it's the length that makes a difference. System's should just go away with password complexity rules.
-
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.
Interestingly, a lot of organizations today still insist on rotating passwords. This doesn't help to improve security but weaken the password creation. I have highlighted this in the previous article when talking about passwords. That said, you can still implement forced password change, when a user gets compromised. Or service accounts that are too sensitive which does not have MFA configured. Use this sparingly, when necessary. Time to bin this from a user account management, moving towards MFA.
-
Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is
accessible to an unauthenticated claimant.
Some systems do this, give hints to an unauthenticated user as to what the password can be. While the original intent of giving hints is to remind the user what the password may be (after coming back from a long vacation...), you are better off validating the user with MFA. Giving hints to an unauthenticated user gives rise to password guessing, which may eventually unlock the system.
-
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.
This has always been a pet peeve for me. One most common questions often asked - "What is your mother's maiden name?" A lot of knowledge based questions can be discovered through social media (i.e. Meta/Facebook).
-
Verifiers SHALL verify the entire submitted password (i.e., not truncate it).
I honestly didnt know this was being done, but I guess it was being done. Instead of using the whole password, some systems takes (for argument sake) the first 8 characters and check the hash of that. If it matches then the faulty system allows the user to authenticate (reminds me of the days of Wired Equivalent Privacy WEP).
Extension
Some of these requirements are not new, but has been around since 2017 (thanks for errata @blackroomsec). However, security policies that don't move with time, antequated systems in organizations make it difficult to retrofit new password policy requirements into old systems. Perhaps, some form of separate authentication layer (i.e Zero Trust type) before hitting the legacy system will thwart such threats or reduce attack surface prior to getting into the secured environment.
One of the challenges in NCIS (network/cyber/information security) setup is the egg and chicken issue between implementation vs policy. Get a policy approved and you get an immediate speeding ticket from auditors. Get implementation done and you get another speeding ticket for not following policy. Brings back to one of my old writings during Halloween - who does the CISO fear more?
Reference
[1] DrSuresh.NET - Passwords - https://drsuresh.net/articles/passwd
[2] DrSuresh.NET - Who does CISO fear more? - https://drsuresh.net/articles/wcfm
[3] NIST SP 800-64-3 (ipd)/PDF - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.2pd.pdf
Author: ORCID ID
Suresh Ramasamy: 0000-0003-4562-037X