[Cryptography] Possible reason why password usage rules are such a mess

[Arnold Reinhold]

On 04/03/2020 13:16, Peter Gutmann wrote:
> There has been some speculation in the past over why we have so many cargo-
> cult password security rules that make no sense in any modern context, the
> prime example being the need to change passwords periodically.  I've found one
> possible explanation, the Ware Report, which talks about authentication words
> more than passwords, and in a manner in which they resemble military
> countersigns rather than what we'd think of today as passwords: …

Another historical source is the now obsolete FIPS PUB 112, from May 30, 1985: 

   https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub112.pdf

Its Appendix E.3, Determining Password Length (p. 44 ff), includes formulas for calculating needed password size based on allowed life, and acceptable probability of penetration. It assumes the threat is repeated login attempts and that the rate at which passwords can be tried is fixed. In their worked example they assume "8.5 guesses per minute (guess rate possible with 300-baud service)” They calculate a password length of 8 or 9 characters or 3 dictionary words, depending on assumptions, including 1 year and 6 month password life.

RFC 1750, December 1994, also obsolete, contains a similar calculation in section 8. They assume a fixed delay (e.g. 6 seconds) is imposed between successive attempts and that passwords are changed yearly and they then derive a minimum password size. They mention the possibility of detecting large numbers of failed attempts, but assume conservatively that this will be done infrequently by inspecting log files. Its replacement RFC 4086 section 8 has a similar but lengthier analysis, but still assumes a fixed rate. Interestingly, the later document assumes an acceptable probability of getting access as 1 in 1000, whereas RFC 1750 assumes 1 in 1,000,000. 

What is missing in both models is the notion of limiting the rate of attempts by progressively increasing the delay after each failure, i.e. throttling. (NIST SP 800-63B Section 5.2.2) It would be interesting to know when throttling was introduced. Also is there any standard or other text that does the same calculations assuming a throttling profile?

More broadly, there seems to be a lack of accepted best practices for password security. NIST Special Publication 800-63B “Digital Identity Guidelines Authentication and Lifecycle Management,” is a recent attempt, but this large document crams the issues we are talking about into just one section, 5.1.1.1. The document is relatively recent (June 2017) and not widely followed, as far as I can tell. It does not include many topics I believe are needed. Here is my list:

o Larger minimum password length (SP 800 63B requires 8 characters, but this is to few. 10 or 12 should be the minimum)

o Only using computationally and memory hard hash or hardware security for verification data

o Special treatment required for password reset answers (e.g. segregated server with separate backup and restricted connectivity)

o including algorithm versioning to allow password verification storage upgrades

o Disclosure to consumers by public-facing, password-protected systems of the protective measures in use , including, salt size, hash function and repetition count

o Offering system generated password or passphrases, preferably in several formats, e.g.
  Random pass phrase with different word lists
  Random letters with mnemonic sentences
  Random pronounceable syllable groups 

o Smart throttling 
    Higher limit for longer passwords 
    No dings for blank password or repeat of previous try
    Non bricking — no extreme lockout (>6 hours)
    Notification of possible caps lock

o Encouraging people to use password managers, at least for most passwords

o Encouraging people to write down non-managed passwords, with suggestions for safe places. It’s no longer reasonable to expect ordinary users to memorize all the passwords or passphrases users need, if they are to be strong enough. 

Other suggestions welcome.


Arnold Reinhold




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201116/e8cf306e/attachment.htm>