Threat Model Short Simple Passwords

[taprootsec]

Organization: Taproot Security

Type: 3

Reference: "Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber; memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric.... No other complexity requirements for memorized secrets are imposed; a rationale for this is presented in Appendix A." [SP 800-63-3B 5.1.1.1]

Comment:
A more thorough and persuasive rationale for short, simple, non-expiring passwords than what is currently provided in Appendix A is needed.

Long, complex passwords have been information security orthodoxy since the 1960s, with the trend toward ever longer passwords and more character sets. This is enshrined in the Common Book of Knowledge.

I’m sure NIST didn’t propose this password heresy without considerable thought and analysis. Unfortunately this is not reflected in the short text of Appendix A. It lacks the formality and completeness of a solid threat model. For example, it doesn't consider the effect of password length/complexity on “shoulder surfing” attacks.

I largely agree with the recommendations in 5.1.1.1. and applaud NIST for taking a bold stand, but I recommend beefing up Appendix A with a formal threat model in order to preempt deep skepticism from the information security community.

Suggested Change:
Revise Appendix A to make a more compelling case for short, simple passwords. Formally threat model a typical password login process to demonstrate password length and complexity do not significantly mitigate any threat vector. Cite studies that show long complex passwords lead to insecure user behaviors (writing them down, reusing them across sites, choosing them in overly predictable ways). Quantify the benefits of short simple passwords over the risks.

---

[jimfenton]

We are not making a case for short, simple passwords. Indeed, we require verifiers to accept memorized secrets that are as much as 64 characters long with as few restrictions on composition as possible to encourage the use of long memorable secrets. The rationale for the lower limit, considering different types of attacks, is as follows:

• Online attacks - With the throttling specified, an attacker has little opportunity to mount a sizeable online (guessing) attack. 8 characters provides plenty of margin against 100 attempts per month for a very long time.
• Offline attacks - Successful defense against offline attacks, where the attacker has obtained a hashed password file, requires a much longer and high entropy password. Rather than set the requirement high enough to attempt to defeat these attacks, we require effective hashing and salting, and strongly encourage the use of a keyed hash function such as HMAC as well. With a keyed hash, if the key can be protected (preferably stored separately, e.g. in an HSM), the hashed secrets cannot be used by the attacker.
• Shoulder surfing - While shoulder surfing attacks are made more difficult with a longer secret, the amount of benefit here depends greatly on the complexity of the secret and whether the attacker can extrapolate from a portion of a longer secret. Shoulder surfing is less of a concern for remote authentication than it is for local authentication (e.g., ATMs or physical access control) where the attacker might have a better opportunity to observe the user.

With the possible exception of attacks like shoulder surfing, there is no benefit to setting the password requirement higher than necessary for protecting against online attacks but lower than required to protect against offline attacks. See Florencio, Herley, and van Oorschot, "An Administrator's Guide to Internet Password Research".

We have modest expectations for the security of memorized secrets. Executive Order 13681 requires the use of multi-factor authentication for all applications making personal data available to citizens, and we encourage the use of multi-factor authentication wherever practical.

Is this the sort of information you would like to have included in Appendix A?

[taprootsec]

Thanks for the prompt response. This is indeed the type of information I feel should be included in Appendix A. Ideally a formal threat model based on an attack tree enumerating all common attacks against secrets -- including shoulder surfing, keylogging, & social engineering -- will confirm all attacks vectors are equally probable against a 6 or 8 length single character set password, versus a 10 length 3-of-4 password with those other mitigations in place (throttling, salted hash, etc.).

I disagree shoulder surfing is less relevant to remote authentication, given widespread smart phone use in public places. I often see people typing their passwords in plain view of others.

[paul-grassi]

Password only use is allowed for AAL1 - low risk applications. Any other federal system will require two-factor authentication, so the shoulder surfing of mobile phones is of limited risk. Given the clarification provided by @jimfenton do you think you could also update the blog you wrote stating we are advocating for short passwords, which as explained, is not true? Thanks @taprootsec for all the great comments!!

[taprootsec]

Thank you. 800-63-3B allows passwords 6 characters long (8 if user selected) drawn from a single character set. To my mind this is a short password so I'm unclear why I should change the blog. However, if NIST revises Appendix A to give a compelling defense of this choice, I'll certainly tell my blog readers. I'll also mention these short passwords are intended to be supplemented by a 2nd factor at AAL2.

[paul-grassi]

Sounds good. These requirements have been there since the beginning. In fact, we lengthened them in this version. The real change we are focusing on in this version is the updated guidance on storage, length, composition requirements, and expiration.

[demarinaGit]

Jim's answer seems right to me: modest expectations of memorized secrets. Shoulder surfing and visual collection is a real threat, but to ameliorate that threat with length or complexity is very tough, and probably costs too much in terms of usability.

[Terebi42]

Offline attacks - Successful defense against offline attacks, where the attacker has obtained a hashed password file, requires a much longer and high entropy password. Rather than set the requirement high enough to attempt to defeat these attacks, we require effective hashing and salting, and strongly encourage the use of a keyed hash function such as HMAC as well. With a keyed hash, if the key can be protected (preferably stored separately, e.g. in an HSM), the hashed secrets cannot be used by the attacker.

This makes little sense to me. Even under very unfavorable conditions, an offline attacker can bring many more resources to bear. Even with strong hashing algorithms, thousands or millions of attempts per second are realistic. 6 and 8 char passwords are trivially weak under these conditions. Unless the keyed hash is a mandatory requirement, this is completely unacceptable as a modern recommendation.

[jimfenton]

There is a balance between security and usability here. Making the memorized secret requirements strong enough to withstand offline attacks would require substantially longer memorized secrets. See, for example, @demarinaGit presentation at Passwords'15 Las Vegas, "Pushing on String: Adventures in the Don't Care Regions of Password Strength" which is available on YouTube -- in particular around minute 21.

Even if memorized secrets were required to be long enough to withstand offline attacks, they would present only modest security due to other attacks such as key loggers. Use of a keyed hash is a strong recommendation, but was considered too onerous (especially if key management is done properly) to make a hard requirement.

[taprootsec]

I note the password length & complexity requirements remain the same in the new draft, and Appendix A still offers a simplistic defense that doesn't address all attacks (e.g., shoulder surfing) much less offer a formal threat model. While I don't disagree with the password construction guidance itself, I do feel that not offering a threat model in Appendix A is a missed opportunity.