0

Recently, I've checked the some articles including R. E. Smith, The Strong Password Dilemma. ch. 6., Password Strength: An Empirical Analysis, Distance between two passwords and Password strength metrics. The mentioned strong password policies are:

  • Each password you choose must be new and different.

  • Passwords must be memorized. If a password is written down, it must be locked up.

  • Passwords must be at least six characters long, and probably longer, depending on the size of the password’s character set.

  • Passwords must be replaced periodically.

  • Passwords must contain a mixture of letters (both upper- and lowercase), digits, and punctuation characters.

When it comes to building a user registering system with user-chosen password input, I want to provide some information about the strength of the password typed from the user (such as the three level results: weak, medium and strong) to guild user to set an appropriate password. The website The Password Meter performs the similar function and the criteria including number of characters, the count of uppercase letters, the count of lowercase letters, the count of symbols, etc. However, to evaluate a password is strong enough is not easy. Even a password is complex enough as something like @P3V;4sF!]9u;3G,, the strength may still be not high enough in the situation of re-using the password in multiple authentication sites.

Thus, my question is : Is there a robust benchmark / algorithm / method to determine password strength (maybe giving a password strength index) which consider not only the complexity of the password itself but also the similarity (distance) of the known passwords in leaked password databases or common password databases like 10k-most-common.txt on Github?

If I misunderstand something, please let me know.

Reference of experimental implementation

Android APP Password Strength Assessment class implementation

JimmyHu
  • 103
  • 1
  • 1
  • 4
  • *... the strength may still be not high enough in the situation of re-using the password in multiple authentication sites*" **NO, Just NO!** Reusing passwords across multiple sites should not be done unless you consider all of the sites as trivial and unimportant. – user10216038 May 27 '21 at 17:39

2 Answers2

1

The fundamental problem with determining password strength is it’s entropy… you can’t predict it or calculate it easily (and not in isolation). (entropy is the amount of unpredictability of the bits used in the password)

All password strength indicators are therefor meaningless… except as an indicator. But for an indication length is also a really good indicator. (The longer the better). Increasing the digit space also adds a little bit not nearly as much as length.

(Adding “#?!” to your digit space(password character set) increases it with 3 to while increasing the amount of digits increases it with 62 (a-z,A-Z,0-9))

Complexity therefor is dwarfed by length with even as few as 6 additional characters. So getting passwords that are 24 or longer in characters are often sufficiently hard to protect you. (If you don’t reuse or use predictable patterns)

Replacing passwords should only be done if you have reason to suspect it has been leaked or compromised. Especially when combined with a 2nd factor this is easily to detect. (Also enforcing longer passwords helps to mitigate any potential issues)

On short this advice from the papers is obsolete. The NIST has even actively discouraged things like forced password expiration and enhanced character spaces (complexity rules) in favour of simple length rules. People are good with remembering a sentence…. There bad with a simple complex password like “P@33w0r17”. Let’s stop trying to make people do things there bad at… it decreases security not improve it.

LvB
  • 8,336
  • 1
  • 27
  • 43
1

Please note there are multiple schools of thought regarding passwords.

I would recommend using a password manager. Ok, you will need to memorize the master password protecting the password manager database, but everything else is stored there. This satisfies:

  • "Each password you choose must be new and different": You generate a new random password for every site with no effort.
  • The passwords in the password manager are locked up (as opposed to e.g. "passwords.docx").
  • "Passwords must be at least six characters long, and probably longer, depending on the size of the password’s character set." As you are storing them, it's trivial to create obscenely long passphrase
  • You are not limited to your memory, so you can use random passphrases (you would otherwise have trouble memoizing) completely different between them
  • It's also trivial to make them contain a mixture of letters, digits and punctuation (but see below)
  • If a site is compromised, the password manager lets you find the relevant entry (not just the password -which shouldn't appear on other sites, anyway- but also other details such as the associated email)

However, note that the "Passwords must be replaced periodically", while traditionaly a requisite, is now somewhat outdated, and NIST SP 800-63 goes as far as saying it should not be done:

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).

The theory behind password changes is that should there be an undetected compromise of the password, with a policy of periodic password changes, the obtained password would automatically become meaningless after the next password change.

However, changing to a completely new and different password imposes an important cognitive burden on the users. And, they are likely to work around the by not using completely new and random passphrases thus missing the point (e.g. on a system with a monthly passwword change policy, an attacker discover that a user had as password "elephantApr2021" 30 days ago. Can you guess their current password?).

Similarly, "Passwords must contain a mixture of letters (both upper- and lowercase), digits, and punctuation characters." can be considered a bit dated. The goal of this requisite is to ensure certain entropy on the password. However, this is generally not needed for a sufficiently long password. And users would probably work around it by appending a number or symbol (e.g. bad password "password" became "Password1!").

NIST SP 800-63 says

If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed.

The rationale is discussed in the Appendix A.

Plus, I should add that each system considers "punctuation characters" differently, for extra user frustration.

You are also missing some important step such as throttling user login attempts.


Password meters generally work by assuming for their measur a random generation of the password, which is rarely the case.

The excelent zxcvbn library includes warnings like "This is similar to a commonly used password" or "This is a top-10 common password", so it already does something like that.

It claims:

Through pattern matching and conservative estimation, it recognizes and weighs 30k common passwords, common names and surnames according to US census data, popular English words from Wikipedia and US television and movies, and other common patterns like dates, repeats (aaa), sequences (abcd), keyboard patterns (qwertyuiop), and l33t speak

Ángel
  • 18,188
  • 3
  • 26
  • 63