I have serious issues with the password length requirement of 8 characters. It's far too short. This is the discussion on that.

5.1.1.2. Memorized Secret Verifiers

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.

Okay, some history. Put this in the appendix for this document, because I want it forever stamped on someone's face.

Probably everyone has heard that a good password should be eight characters long; use a mixture of upper- and lower-case letters, numbers, and symbols (“four-class”); and not include a dictionary word. Even Microsoft’s password complexity rules enforce the four-class recommendation, and most password policies require a minimum of eight characters.

Why eight characters?

Security experts have recommended twelve-character passwords as far back as 2010, and length is mathematically more-important than complexity. Eight characters has been a mainstay for years, even though a twelve-character password is obviously much stronger—just like counting to a hundred is like counting to ten ten times, breaking a twelve-character password is like counting all possible four-character passwords and breaking that many eight-character passwords. Instead of adding length, we’ve tried to create more possible eight-character passwords.

That still doesn’t explain why we chose eight characters.

In older versions of Windows released before 2002, Windows stored passwords as two passwords of seven characters each. Because a seven-character password always had the same encrypted value for the latter half, it was easy to identify and quickly break weak passwords. Eight-character passwords created some variation—a maximum of 68 possible values, in fact, meaning an attacker could immediately know the eighth character and attack the password as if it were only seven characters long. The entire approach was ineffective; yet the eight-character recommendation stuck.

To summarize: the advice to use an eight-character password was originally given as an ineffective work-around for weaknesses in the NT LAN Manager hash in 1995. It was never secure.

Pasword Variations

Let's assume absolutely-random passwords for a moment. People can't memorize these, and they're not really put into use; but we still use them as a basis, so let's try the low-hanging fruit first.

An all-lower-case, 8-character password has 200 billion variations, whereas a four-class password has 6,000,000 billion variations. That seems fine, yet an all-lower-case 12-character password has 95,428,957 billion variations—because it’s 1.5 times as long, instead of using 3.6 times as many possible characters.

Illustration A: Second place is the first loser.

Some experts suggest selection of words, by Diceware or other means. Generally, words average four characters plus a space, thus a password length of five per word would make some sense: a minimum password length of 16-20 is appropriate for passphrases.

Above, we assumed a truly-random, 4-class, 8-character password would have 6,000,000 billion variations. If we instead assume the password is based on a dictionary word with complexity variations, the number of variations falls to a theoretical strength of just 13 million.

Compare that 13-million-variation real-world memorable password strength to passphrase generated from three and four words. Diceware supplies a 7,700-word vocabulary. Assuming a 5,000 word vocabulary, a 3-word passphrase presents 125 billion variations; a four-word passphrase gives 625,000 billion variations.

Illustration B: First, second, third, fifth, and twelfth loser; why did you even finish?

In this context, a "word" is equivalent to a "character", and we've simply constructed a scenario where your keyboard has 5,000 keys to chose from. Four words out of a vocabulary of 5,000 gives a number of variations equal to 5,000 raised to the power of 4.

Summary

Eight characters is too short. While the passphrase argument makes good sense, password length is the only readily-enforceable characteristic.

While a password length of fifteen to twenty would be appropriate for a hard-line passphrase approach, compliance would likely suffer. To maximize standards compliance, NIST should indicate a minimum password length of twelve; regardless of password complexity, this raises the number of password variations to a power of 1.5.

Even given the low complexity in modern passwords, a raise to a power of 1.5 adds a tremendous amount of entropy. Our pessimistic 13-million-variant password space above becomes a 46,872-million-variant password space when raised to 12 characters. That's over 3,600 times as many variations, meaning a password which is broken in one day now averages nearly ten years of resistance at current computational speeds.

Eight-character passwords are built on a flawed work-around for an even-more-flawed password storage system. The advice to use eight characters as a minimum length is not based in any form of science or mathematics, and has never been adequate. Eight-character passwords represent what may be the largest failure in information security theory history: flawed advice with no theoretical backing taken as gospel and perpetuated well beyond its age. Any discussion of password length must establish that the eight-character password was never a well-developed concept, and that the advice was always wrong.

Your thoughts on the matter are appreciated.

The 8 character length actually goes even further back than that, by about a decade! The NIST green book CSC-STD-002-85 (ironic, I know) published in 1985 references password strength. On or about page 19 I believe, there is "A Procedure for Determining Password Length" including a worked example. This example measures the time it would take to crack a password of various lengths over a 300-baud or 1200-baud service.

One of the results found is that it would take 12 months to crack all 8 character lower-alpha+number passwords. The DOD halved this time period to 6 months, so theoretically passwords would rotate before their half-life. Thus was born the 8 character password that must be changed every 90 days.

We've come so far in the last 32 years. The general wisdom provided here is no longer to rotate passwords or require complexity rules. It's downright silly that the minimum is still only 8 characters. I came to the issues page to make this exact argument and found this thread already in place.

Please, for the love of everything, increase this minimum. I would strongly suggest 16 characters myself. That said, as mentioned above, even 12 characters provides us with exponential improvements over the current guidelines.

8 characters, even with some additional controls, is generally too low in a lot of cases
Without any additional requirements, merely increasing the minimum password length from 8 to 12 characters will not significantly increase the security of an information system. A purely mathematical approach to the entropy problem of passwords is doomed to failure.
- September2017 is a 13-character password that meets "3-of-4"
- Requiring password rotation strongly nudges users to use patterns in their passwords
I strongly advise against ever implying "if you use long passwords, there is no need for additional measures
It's important to realize that passwords on their own are generally not sufficient. Guidance should strongly relate to additional controls like screening user choices against dictionaries of common passwords, and the use of timeouts, rate limiting, and multi factor authentication.. In other words, since password length alone is never sufficient, explicitly reference the need for additional controls where you are prescribing a minimum password length. Call out the requirement for long, novel passwords where a system cannot have additional controls like lockouts or especially secondary auth.

So I agree, stop recommending 8 characters but even more importantly, emphasize that even 12 characters on its own is not good enough, on its own. That's the more important point.

We expect only modest security from passwords alone; that is one of the reasons that Executive Order 13681 mandates the use of multi-factor authentication for any application that makes personal data accessible to citizens. However, there are still many applications that require only this modest level of security.

It is useful to consider online and offline attacks separately. A relevant paper in this area is Florencio, Herley, and Van Oorschot, "Pushing on string: the 'don't care' region of password strength" published in November 2016 Communications of the ACM.

The primary defense against online attacks is authentication attempt throttling. We believe that the rate limit guidelines in Section 5.2.2 are appropriate for the complexity of 8 character passwords used in conjunction with a blacklist or for 6-digit randomly-generated PINs.

For offline attacks, we instead focus on storage of memorized secrets by the verifier. They must be salted and processed using a one-way stretching function to drive up the work factor for the attacker. We also highly recommend the use of an additional one-way stretching operation using a secret value as the salt. With this secret value (which is to be stored separately from the stored hashes, perhaps in an HSM), it is not practical for an attacker to mount an offline attack unless they can also obtain the secret value.

As the paper points out, there is little point in choosing a password requirement that is longer than that required to protect online attacks and shorter than that required to protect against offline attacks.

there is little point in choosing a password requirement that is longer than that required to protect online attacks

It doesn't seem sufficiently clear that for things like 8 character passwords, there is a requirement for additional controls to adequately protect against online attacks. If you agree that it can be better broken down, I think that would be well placed effort.

You essentially suggest that password strength doesn't matter, and that 8 characters is excessive. 6-digit, randomly-generated pins means 1 million combinations. That's the same as a single dictionary word of 4-6 characters with a mandatory two capitals, assuming a dictionary of only 5,000 words and a ban on anything not in the dictionary (essentially choose your password from a small list).

As for the secret value, good luck with that. Likely attacks include:

Whatever hijacked (likely Web) application gives the config.xml file with the secret value, because VMs and most off-the-shelf stuff don't have an HSM;
- Attacker uses hijacked application to encrypt the passwords 'a', 'b', 'c', 'd', and so forth through the HSM, then goes through them in order to search for collisions. Test each possible secret value on 'a', then test 'b' on each match, 'c' if you get a match from 'b', and so forth. Shortest possible sample passwords to minimize the number of rounds through the hashing function.

As a practical matter, online attacks guess passwords; offline attacks generally are high-speed dictionary-mutation attacks (comprehensive rainbow tables don't work on SHA512). 12 characters swiftly takes you outside those practical limits: the number of mutations increases dramatically, and the use of multiple (2-3) words increases.

In other words: you try to draw a wide gap separating passwords short enough for online attack from passwords big enough to resist offline attack; as a practical matter, there is an overlapping region of passwords short enough to be attacked by a reduced set (dictionary mutations) and long enough to change basic form into something requiring a much-more-involved attack (multiple dictionary mutations).

Passwords based on mutated dictionary words can start with base words varying from 5 to 7 characters. The resistant strength of an 8-character password is a simple multiple of a 5-to-7-character dictionary word--or rather, a word from a dictionary of short thousands. That multiple is essentially the average binary length of passwords (e.g. 5.5-letter average word length, 2^5.5 = 45) times the average insertion of extra characters (e.g. 1 special character, 1 number, 2 orders, 6 possible positions, 19,200). For a dictionary of 10,000 words, that gives you 8.64 billion passwords, whereas a random 8-character password is assumed 209 billion possible lower-case strings or 6.1x10^15 possible random 4-class strings.

Once you break over into using two mutated dictionary words out of a dictionary of only 5,000 (half the size), you're looking at 1.87x10^19 possible attempts from just a mutated dictionary attack.

The paper you cite suggests an online attack might make T1 = 1,000,000 online guesses at a maximum, approaching the 6-digit pin, but not the 8-character password. It also suggests an offline attack might make a minimum T2 = 10^14 guesses, which is 100,000 times as many guesses against which an 8-character password practically protects.

In other words: you defined a password strength which can probably prevent online attacks, but which will fall to offline attacks.

A 12-character password will, from a practical perspective, come up at 187,000 times the T2 strength of 10^14, resisting both online and offline attacks.

I suggest you abandon the fantasy that sites will cease getting hacked and password databases will remain under lock and key, or will be made unreadable by anyone aside from their proper owner. That's been the advice for literally two decades, and it still hasn't happened.

See response to #1291 and #1293. We recognize the value of longer memorized secrets, but any sensitive application, and any application releasing personal data to the user (as required by Executive Order 13681) should be using multi-factor authentication in any case. It is for that reason that memorized secrets alone are permitted with such modest requirements.

any sensitive application, and any application releasing personal data to the user (as required by Executive Order 13681) should be using multi-factor authentication in any case.

https://arstechnica.com/information-technology/2017/04/picture-this-senate-staffers-id-cards-have-photo-of-smart-chip-no-security/

Today, the Senate neither requires nor offers two-factor authentication as an additional protection for desktop computers and e-mail accounts. The Senate Sergeant at Arms does not require two-factor authentication for staff who wish to log into Senate IT systems from home, using a Virtual Private Network... Moreover, in contrast to the executive branch's widespread adoption of PIV cards with a smart chip, most Senate staff ID cards have a photo of a chip printed on them, rather than a real chip.

Do you see my point? The Senate doesn't use two factor. You saying it should be used does not reflect what is done in the real world.

Best practices are often not followed to the letter, either because people implementing them are lazy, constrained by budgets or bureaucracy, or simply overlook them. Multi-factor will not be implemented properly, if at all. Best practices for strong hashing algorithms will be ignored. It is for this reason that defense in depth, multiple layers of strong security, are recommended. Multifactor isn't a magic bullet, it's a layer. One that should be combined with other strong layers, such as not using weak passwords.

You say you recognize the benefit of longer secrets, but you're burying your head in the sand to the reality of things.

I believe the argument that sensitive access will be further protected by 2FA violates the fundamental principle of defense in depth. The existence of another control does not justify weakly implementing a control. For example, we have recently seen an example of a an attack specifically designed to subvert an SMS based 2FA solution. In that case, the attack used other means to learn the users' passwords, but this attack could well be applied to users specifically because their password had been compromised via hash cracking. Passwords must be strong as must other authenticators.

Many systems do not currently support slow hash algorithms and we must protect assets until slow hash algorithms are universal. Also, further increases in processing power and optimization of brute force methods may weaken slow hashes of short passwords. The argument that users reject and can be expected to undermine the value of longer passwords is easily refuted with training toward user-friendly passphrases.

I disagree with the recommendation of an 8 character minimum length for memorized authenticators. I propose that this be increased to at least 12 and preferably 15 characters.

usnistgov / 800-63-3

Password length #585

Pasword Variations

Summary