Re-Calculate Passphrase entropy when manually adjusting

[LilithHafner]

When auto generating a passphrase and then editing it, the entropy is not recalculated.

Operating System: Linux Desktop Env: Gnome Windowing System: Wayland

[droidmonkey]

That is the passphrase generator not password generator. Passphrase entropy is calculated based on word count used, not composition.

[oscardssmith]

@droidmonkey I don't think this is password vs passphrase. The problem is that editing the password doesn't change the displayed entropy. IMO, the expected behavior would be that when the password is edited, the entropy calculation is redone even if the user is using the passphrase generator. In this example, the user changed the word count used (from 4 words to 1 word), and the entropy did not change.

[droidmonkey]

I could go with re-detecting the number of words, based on the chosen separator, to re-calcuate the entropy. FWIW this only applies to the passphrase generator, the entropy adjusts dynamically for the password generator.

[LilithHafner]

I think that @Iiridayn's position

anything a user types in the box is suspect and should display only guessability per zxcvbn. However, for higher entropy passwords the system generates, I find it much more useful to know the true entropy value

Makes a lot of sense. I agree with displaying Shannon entropy for these system generated passphrases, but as soon as a human touches it, I would revert to a pessimistic guessability computation for human generated secrets (such as zxcvbn). Simply re-counting the number of words is likely to lead to an overestimate. For example, if I randomly get

coat accompany headless old sneeze anybody earful lullaby

and change it to

papa alpha sierra sierra whisky oscar romeo delta

or even worse,

a a a a a a a a

the new password has the same number of words, but is significantly less secure.

[droidmonkey]

Yah thats why I am saying you are on the wrong pane, if you want to make a bunch of edits use the password generator. Toggling entropy calcs is just confusing and defeats the purpose of passphrase.

[oscardssmith]

The counterpoint here is there are lots of very good reasons to mess with the passphrase generator. The common one for me is to need to take a passphrase and then add a number and symbol at the end to make it pass a dumm password requirement.

[droidmonkey]

Adding a number or symbol shouldn't make the entropy calc revert to zxcvbn though.

[nsajko]

if you want to make a bunch of edits use the password generator.

"You're doing it wrong" doesn't make sense here as a response to an UX complaint.

The problem here is that there's a numerical value for password strength that's being mislabeled as "entropy" in the UI in some cases. This naturally causes confusion, as evidenced by many prior bug reports on the same topic.

I think it should be easy to solve, though, either:

1. Remove all numeric indications of password strength (it would at least decrease confusion)

or

2. Display multiple numeric values and label them correctly

I think the correct name for the estimate produced by zxcvbn may be "an estimate of Kolmogorov complexity", but it surely is not "entropy", see the release notes for zxcvbn v4:

Removed all mention of entropy in place of more intuitive guesses and guesses_log10. (entropy in older versions was just log2 of guesses -- a sloppy use of the term.)

So you could, e.g., always display three numbers, labelled as:

• Entropy assuming password generator
• Entropy assuming passphrase generator
• Kolmogorov complexity estimate

[nsajko]

Another possible label might be "information content".

[Iiridayn]

Re labeling, could label it "guessability" - for independently and identically distributed random rolls, the guessability is equivalent to the Shannon Entropy (see Pliam 2000, "On the incomparability of entropy and marginal guesswork in brute-force attacks"), and once humans have influenced the generated outcome, we can at best estimate the guessability.

[michaelk83]

"Guessability" doesn't work, because a higher number indicates lower guessability.

I think getting too technical with "Kolmogorov" and "Shannon" and whatnot, is not helpful for most users. Even for the technical ones, it's rather besides the point. The exact value doesn't really matter, as long as the password is strong enough. If it takes 1 billion years to brute force or 10 billion years, it makes no practical difference for 99% of users.

If we're relabeling stuff, I would suggest simply "Complexity". But then I'm sure people would add a digit to a passphrase and wonder with the "Complexity" isn't now higher. Intuitively, the passphrase is now "more complex".

Maybe "strength"?

[nsajko]

The referenced paper actually uses the term "guesswork", they never use the word "guessability". Some interesting excerpts (thanks for the reference @Iiridayn):

It is now well-established that there are a variety of different uncertainty measures important to cryptology. Recent scholarship suggests a hierarchy of inequalities surrounding entropy (see in particular Cachin’s summary of [3, Table 3.1]), and counterexamples exist (see e.g. an important one due to Massey [9]) which show that many of these inequalities are not tight. Our result adds to this overall picture in a rather negative way: marginal guesswork, which we shall argue to be as meaningful a measure of uncertainty as any within the secret-guessing paradigm (see Sect. B.2 and Remark 1 below), can not exist with entropy in any hierarchy of inequalities. This rules out even vague notions that entropy may uniquely measure uncertainty at some level of granularity.

Guesswork is sometimes called guessing entropy, though as far as we are aware, never without enclosing quotation marks.

[droidmonkey]

This has been debated before, this is not the place to discuss such matters.