Password strength calculator

[jboileau99]

Hey team,

@filipblnt @m4rk055 @noelmace @TheKinrar

In our meeting on Friday we discussed creating an password strength calculator for use in our products. Here's some information I've gathered and a proposed system which combines a few different techniques to give what I feel is a complete indication of the password's strength:

Summary

Component 1 - Leaked password check

• Even for an “objectively” strong password, it could still be very weak if the user repeats it. To combat this, we could also use the haveibeenpwned API v3 to check password hashes against their database, see here (scroll down to “Pwned Passwords overview”)
  • Uses k-anonymity so only a partial hash of the password is sent to the API, which responds with a list of hashes matching the partial one, which we could then compare to the full hash on client-side

Component 2 - Hueristic strength estimator

• zxcvbn (Made by dropbox) A popular heuristic password strength estimator, ranks passwords based on:

  • Dictionary - matching popular words
    • Generic passwords (e.g. “admin”, “password”), name + surnames, common words, inverted words (e.g. “password” → ”drowssap”), L33T (substitution of numbers for letters
  • Spatial matching (close keys on keyboard)
    • Uses qwerty, dvorak, common, and mac keyboard combinations
  • Repeat matching
    • “aaaaabbbb”
  • Sequence matching
    • “abcdefg”
  • Date matching
    • Strings like “20220610”

  The output from zxcvbn is a score out of 4, info on how long it would take to crack, plus warning and recommendations to improve the password. We would likely only be interested in the score but warning/recommendations are interesting.

Component 3 - Quantitative indicator (Entropy bits)

• Lastly, we could employ a quantitative measure such as entropy bits, which is often used as a quick alternative to password strength checkers.
  • This package or similar would work
  • We would have to decide what the threshold entropy bits will be for a password to pass
    • This MIT article suggests that for very high security in the year 2004, password should have 96 bits of entropy. It also states that an updated recommendation can be obtained by adding 2/3 of a bit per year, by Moore’s law. This would mean in 2022 we should consider a password with 108 bits of entropy to be highly secure.
      • 108 bits of entropy corresponds to approximately a 17-23 character password depending on the assortment of character types used

Combination

• These three components taken together could be used to produce a final password “score” which we relay back to the user, or just a pass/fail based on some score threshold

Proposed System

References

• Concordia university paper on password strength meters
• Password strength blog
• Password+statistics blog

[filipblnt]

I like this idea, and how it has different elements that look at the different aspects of the problem.

So we have three objective dimensions for the password strength, based on which we can interpret the strength for the end user and give recommendations via password assistant, of which the strength calculator defined here will be a part of.

@jboileau99 Think about how we could calculate the score/recommendations based on the outputs of the three components, and what you think it would be the most useful/practical for the end users. We'll then move to the implementation and the assistant.

Others, please give your opinions and suggestions.

[milstan]

@jboileau99 these are great finds. I think once you figure out how to combine them, indeed it will be a great component of the assistant.

Here are some things on my mind, more as a reminder:

• This component is going to be used by several other components of the blindnet devkit. For example, the Data Consumer Interface will use it, but also the Capture Component and the Privacy Request Capture Interface (formerly Rights Request Capture Interface might use it.

• Client Systems may use it in combination with password strength rules. Your design should support the situation where a developer (for legal or other reasons) must impose a combination of character types, but still wants to show the indication of strength and recommendations for improvement.

• IMHO, what brings the real added value here are the recommendations.

  • The score itself is necessary, and it is great to be able to configure a password-strength validator using objective criteria like this. However, it is not sufficient for wide adoption because people don't just do something because it's the right thing to do. They always need a little nudge.
  • I think, a nice way to nudge them into using objective criteria is if this allows them to perform a paradigm shift. We can call it the "teach rather than impose" principle.

So, if we approach it from that angle, what we want to generate really are not "explanations" about why the score is not good enough, but really "recommendations" about how it can be improved.

The challenge is, for every combined score value, how do you calculate actions that the user can perform in order to improve their password score.

The way I’d approach it is to have a list of actions (e.g. “add one more word”, “remove a popular word”, “remove a keyboard sequence”, “remove the already leaked password”), and I’d cope with a way to produce, given a score, a subset of those actions that can help improve it.

Then, with every action I’d associate a sort of an estimate of the “delta” – improvement of the score it can make, and I’d rank them, so that I first propose the action that likely to make the highest improvement of the score. Basically, I want to teach the user to make maximal improvement of the password, in a minimal number of steps.

Ideally, I’d have a configuration file, associating wordings (in different languages) with every action. That way, developers using this component can customize wordings and translate them in different languages.

UPDATE: The whole thing is in fact a password improvement recommender engin. The developer should be able to configure a set of or more "strenght estimators" (the 3 here mentionned, or the developer can add a 4th one of their own). Each strenght estimator comes with a set of "improvement actions" with weights, and wordings. Then it is ranked.

[m4rk055]

Great summary @jboileau99

I like the pedagogical idea @milstan proposed.

I'm against using the external API to check for leaked passwords. Even though the technique is (relatively) secure, blindnet users might get confused why their password is being sent to a third party endpoint. The component should also work offline.

We need to keep the basic password strength estimator component as light as possible, so I propose to have:

• Quantitative indicator (Entropy bits)
• Heuristic strength estimator with the rankings you specified and customizable wordings

And add as Milan suggested:

• Recommendation compiler

The first two components should work independently while the recommendation compiler needs the output from (one of) the first two components.

Since none of the JS libraries are being actively maintained, we should create our own.

[jboileau99]

Thanks for the feedback everyone!

@filipblnt @milstan The different possible use-cases is really useful, and I agree the password recomendations provide the most value. I'll imagine the design of each component to follow the same pattern of Input: Password, Output: score + ranked recomendations, which should allow developers to add more components as they wish.

To add on, here's some sample output from the zxcvbn library for the string "Tr0ub4dour&3":

{
  password: 'Tr0ub4dour&3',
  guesses: 19058000,
  guesses_log10: 7.280077322611945,
  sequence: [
    {
      pattern: 'dictionary',
      i: 0,
      j: 9,
      token: 'Tr0ub4dour',
      matched_word: 'troubadour',
      rank: 11905,
      dictionary_name: 'us_tv_and_film',
      reversed: false,
      l33t: true,
      sub: [Object],
      sub_display: '0 -> o, 4 -> a',
      base_guesses: 11905,
      uppercase_variations: 2,
      l33t_variations: 4,
      guesses: 95240,
      guesses_log10: 4.978819386732842
    },
    {
      pattern: 'bruteforce',
      token: '&3',
      i: 10,
      j: 11,
      guesses: 100,
      guesses_log10: 2
    }
  ],
  calc_time: 3,
  crack_times_seconds: {
    online_throttling_100_per_hour: 686088000,
    online_no_throttling_10_per_second: 1905800,
    offline_slow_hashing_1e4_per_second: 1905.8,
    offline_fast_hashing_1e10_per_second: 0.0019058
  },
  crack_times_display: {
    online_throttling_100_per_hour: '21 years',
    online_no_throttling_10_per_second: '22 days',
    offline_slow_hashing_1e4_per_second: '32 minutes',
    offline_fast_hashing_1e10_per_second: 'less than a second'
  },
  score: 2,
  feedback: {
    warning: '',
    suggestions: [
      'Add another word or two. Uncommon words are better.',
      "Capitalization doesn't help very much",
      "Predictable substitutions like '@' instead of 'a' don't help very much"
    ]
  }
}

The suggestions are interesting, I don't really like the wording "very much", especially in "Capitalization doesn't help very much". Even if the capitalization doesn't make the password significantly more secure, removing the capital letter would only make the password worse, and we'd be teaching the user the wrong behaviour. Perhaps we'll need to fork zxcvbn-ts (see below) and redefine how it does the recomendations.

@m4rk055 For zxcvbn, I did find this typescript fork that is maintained and people have switched to. Do you think we could use that? As for the entropy calculator, it's not too complicated so shouldn't be too hard to create ourselves.

I see what you mean about user perception of passing the passwords to a third-party. We could leave it as an optional component?

[milstan]

I see what you mean about user perception of passing the passwords to a third-party. We could leave it as an optional component?

Well if you design the tool with the idea of wrappers arround thrid-party password strenght estimators, where the developer can add their own, then you don't have to bother making one for this "Leaked password check" strenght estimator. The developer who wants it, can make one of their own.

[m4rk055]

@jboileau99 good, we can use that library. I'm only concerned about the size (~550 kB), but it's probably the dictionaries.

[milstan]

It can be a very minimal, very elegant component, in fact. I like this a lot.