When password generator is set to "Passphrase", quality meter isn't as dynamic

[sts10]

Expected Behavior

When I manually edit a generated Passphrase, the Password Quality meter should change to reflect the edit. Currently, when the password generator is set to "Password", the meter does change with edits, as expected.

Current Behavior

Currently, the Password Quality meter does not dynamically change when you manually edit a generated passphrase. It only changes when a new passphrase is generated.

Steps to Reproduce (for bugs)

1. Create or edit an entry
2. Click the black die to generate a new password
3. Click passphrase to generate a passphrase.
4. Drag the slider to generate a random 7-word passphrase. Let's say it has 90.47 bits of entropy (Password Quality says "Good" in this case).
5. Click into the password text box and delete some of the 7 words. Entropy is still displayed as 90.47 bits and the Password Quality still says it's "Good".

Context

This isn't a huge thing, as users may not be frequently manually editing generated passphrases, but I could see it might lead to someone thinking a three-word passphrase was "Good". This could also affect users who want to add a few numbers and/or symbols to the end of a generated passphrase, either to meet a website's password requirements or just out of paranoia, etc.

Debug Info

KeePassXC - Version 2.2.0
Revision: caa49a8

Libraries:

• Qt 5.9.0
• libgcrypt 1.7.7

Operating system: OS X Yosemite (10.10)
CPU architecture: x86_64
Kernel: darwin 14.5.0

Enabled extensions:

• KeePassHTTP
• Auto-Type
• YubiKey

I also reproduced this issue with KeePassXC 2.2.0 on Ubuntu 16.04 / Qt 5.7.1 / libgcrypt 1.7.6-beta

[siliconninja]

Duplicate of #861.

I have closed that issue because this behavior is intended - Diceware passphrases are fixed entropy values depending on the number of words. If a dictionary attack with Diceware words occurred (which is possible with similar passwords encrypted/hashed, practical example with base64: https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/), then it would take significantly less time to calculate than if a regular password guess (brute-force) occurred with every character. That's my understanding of why this behavior is intended.

EDIT: https://security.stackexchange.com/questions/10294/can-a-dictionary-attack-crack-a-diceware-passphrase

[sts10]

I'd argue that #861 is a slightly different issue than the one I'm flagging here.

I understand why it's OK to keep the amount entropy the same as the user generates different passphrases of the same length (one word is as random as the other). It's a bit different to have the amount of entropy remain the same when the user manually edits the passphrase, potentially changing the number of words.

I'll need to read up on the Adobe case more slowly (I'm new to cryptography-- but looks like a good example to learn from), but as you write "Diceware passphrases are fixed entropy values depending on the number of words." In the case I point out, the number of words can/does in fact change (by manual edit). As you can see from the screenshot, a user might get the impression that a 3-word passphrase has 90.47 bits of entropy.

EDIT: Actually this has me wondering if it's less than ideal that the same 3-word passphrase displays 38.77 bits of entropy when "Passphrase" is selected, and 52.45 bits of entropy when "Password" is selected. Certainly this disparity provides evidence that the entropy calculator is in fact "calibrated" differently for passphrases, which, as per the comment above, seems to be a very good thing. But excepting some sort of "passphrase auto-detect", or confusingly providing two separate entropy values, I'm not sure what the fix for this smaller issue is.

[droidmonkey]

Wow I never noticed that. @TheZ3ro looks like we may have a problem with the entropy calculation in the passphrase department. When you copy/paste the diceware passphrase into the password box a totally different entropy calculation is spit out.

snip
Did some research... duh! This is because the password field actually calculates the entropy and the passphrase field uses a fixed calculation.

https://github.com/keepassxreboot/keepassxc/blob/develop/src/core/PasswordGenerator.cpp#L33

vs

https://github.com/keepassxreboot/keepassxc/blob/develop/src/core/PassphraseGenerator.cpp#L35

[sts10]

Yeah, it makes sense that they're different, since you make different assumptions about the hypothetical dictionary attack. Thus the only solutions would be some sort of auto-detection, or giving both entropy values, both of which seem to be messy solutions. Apologies if I wasn't clear about that. But still, thanks for giving us a look at how this is handled in the code.

I'm less concerned about the differences in the entropy calculations than I am about the initial issue I flagged.

[TheZ3ro]

Yes, that is the intended behavior like explained in #861 and by @siliconninja above.

The thing here is: If the attacker has more information about the passphrase, like he knows Diceware has been used and knows the specific wordlist the "correct" entropy is the one shown in the Passphrase section.

In the Password section the entropy is calculated by zxcvbn.
If you copy a diceware passphrase in it, the entropy will be calculated without those informations (and the calculated entropy will be more than the entropy in the Passphrase section).

I agree that there is a bug in the actual behavior but it's not about the entropy calculation.

A possible fix can be: when you generate a diceware passphrase shows its entropy, if you edit it change the tab to password and show the password entropy.

[sts10]

A possible fix can be: when you generate a diceware passphrase shows its entropy, if you edit it change the tab to password and show the password entropy.

One possible issue here is if the user generates a 7-word passphrase and then manually removes a word she doesn't like (or for whatever reason), or even manually changes the word separator, the entropy may likely increase, similar to the original problem.

I realize now that one of the underlying issues here is what is the "correct" entropy value for a password like "squad-pull-glutton-diagram-conductor-platinum0!" 77.55? 124.20?

With this question in mind, I've thought up some possible alternatives to Z3ro's suggested fix. They're a little more radical, and from someone who needs to learn more about entropy, but maybe one of them will give y'all some ideas.

1. In "Passphrase" mode, make the generated passphrase impossible to manually edit. It's grayed out, just able to copied. (This is bad for sites that have special character requirements.)
2. In "Passphrase" mode, make only the generated passphrase itself impossible to manually edit, but also provide a text box attached to the end of it. The entropy of the content entered into this text box would be calculated like a Password (by zxcvbn), and added to the entropy of the generated (an uneditable) passphrase (a fix value). By this metric, "squad-pull-glutton-diagram-conductor-platinum0!" would have 85.98 bits of entropy I think (77.55 + 8.43).
3. In "Passphrase" mode, if the user manually edits the passphrase, throw them into a third tab called something like "Combination" or "Word + Phrase" that has an entropy calculator somehow more suited for that situation.

Separately, to be a bit safer in "Password" mode, you could have the code dynamically scan for dictionary words and issue a light warning that "using common words decreases the quality of the password" or something to that effect.

This brings me to another thing that's been bugging me. Currently, if you paste a passphrase into the "Password" mode, and then manually delete, say, the last character of each word, the entropy goes up instead of down, as I would have expected. The same happens as you type out a word (say "establish"). When you get to the last character, completing the word, the entropy goes down. Given what we've learned above, this is smart and desirable behavior. I just can't figure out how return ZxcvbnMatch(password.toLatin1(), 0, 0); does that.

[TheZ3ro]

For zxcvbn "establis" has more entropy then "estabilish" because the first must be bruteforced and the latter is an English word that is easily guessed by a dictionary-attack

I like the 1 suggestion, but then the user need to copy the passphrase in the password field to edit it (my suggestion permit the edit instead)
I was thinking about 2 as well but it will add more complexity to the already complex password generator.

Also think about this. I generate a 3 word passphrase with 38.77 bits of entropy, I then add a new english word (that is present in the Diceware dictionary) manually. Should be ~50 bits but the generator will report more than that (since it will use zxcvbn for the new added word).

Anyway note: there is not a "correct" value for entropy, it depends on information available about the password/passphrase.

I realize now that one of the underlying issues here is what is the "correct" entropy value for a password like "squad-pull-glutton-diagram-conductor-platinum0!" 77.55? 124.20?

Here the information that you are missing is the separator. The first part comes from diceware and the separator is fixed, zxcvbn on the other end gives 6 bits of entropy for each - (6*5 = 30) then there is the 20 bits extra for the multi word. 124 - 20 - 30 ~= 77

[droidmonkey]

I believe a little "info" button that when pressed describes the entropy calculation process in a model dialog would solve most of these concerns. Especially since there is an assumption that an attacker knows you are using standard diceware in the passphrase calculation.

[sts10]

Ah OK, so if zxcvbn is "smart enough" to know "establish" is an English word that is easier to guess by a dictionary-attack, that makes me feel better about your proposed solution to change the tab to password and show the password entropy when a passphrase is edited.

Here the information that you are missing is the separator.

I also see the logic here. Indeed, when I paste "squadpullgluttondiagramconductorplatinum" in to the Password field it gives me an entropy of 73.30, which is pretty close to the fixed 6-word passphrase amount of 77.55. And adding some special characters--"squadpullgluttondiagramconductorplatinum0!"-- bumps it to 84.91, which is pretty close to the "combined" entropy of 85.98 I calculated by simple addition above. Cool!

[TheZ3ro]

So @sts10 the change tab can be a suitable option?

[sts10]

Yeah, I thinks it's the best option of those laid out here. And I think it's a big improvement over the current behavior specifically in regard to the original bug I flagged (i.e. users would, depending on your implementation, no longer be able to reproduce the screenshot I made). EDIT: I assume you prefer that solution to more simply using zxcvbn as the entropy calculator for both passphrases and passwords by default?

But really, I'm neither an expert in password entropy nor in C++ or the KeePassXC codebase, just the user that flagged the peculiarity/bug. Hope I didn't imply otherwise. My opinions should be taken with a sizable grain of salt. Y'all are the maintainers and obviously between us the choice should be yours!

[sts10]

I got curious about zxcvbn the other day I found this fascinating paper and video of an associated presentation and WOW is it interesting and well-thought out. Apparently it was designed to be used on website sign-up pages, which is fascinating to me. The paper compares it to the password strength estimator in the original KeePass and claims zxcvbn is superior to it, so props to whoever chose to adopt zxcvbn for KeePassXC.

While doing my best to understand the paper, I saw how almost-nonsensical the idea of a "correct entropy" is (which I discuss above). In fact, if I understand it correctly, the core of the original zxcvbn uses number of guesses rather than entropy as the measure of a password's "strength". The zxcvbn devs seem to have favored a practical approach over a theretical one: not only do they neglect the concept of entropy, they anticipate common human tricks to creating passwords (l33t) and used a handful of popular password cracking software to test their estimates.

I came away with the view that KeePassXC could use zxcvbn as the password strength estimator everywhere, including in the passphrase tab, and probably serve its user just fine. (This would mean that almost all passphrases of the same word length would display different strengths, but alas.)

But I definitely understand and appreciate this logic, which points to keeping the number_of_words * 7,776 math currently used in the passphrase tab for estimating the entropy of generated passphrases:

The thing here is: If the attacker has more information about the passphrase, like he knows Diceware has been used and knows the specific wordlist the "correct" entropy is the one shown in the Passphrase section.

I can still see how that procedure leads to a "better" estimator of the entropy of the randomly generated passphrases, given that it "knows" the method by which the passphrase was formed.

This is all a bit outside the scope of the original bug I flagged here. Just wanted to add some more context.

[TheZ3ro]

Thanks for the props! :D

The new versions of KeePass use an even better entropy estimator, but zxcvbn is enough for our needs (https://keepass.info/help/kb/pw_quality_est.html)

Your comment is all right.
The entropy depends on what the attacker knows, if he knows for example that the password is all lowercase the entropy will be lower then assuming it's mixedcase.

The old algorithm for password was assuming the second case (the attacker knows nothing), the zxcvbn approach assume the attacker knows everything about the password (even if leet speak is used)

In the diceware meter, using zxcvbn is like the previous first case. It analyze the full password without knowing it's made of N words from a dictionary. Our approach instead calculate entropy assuming the attacker knows everything.

I will adress this issue in the next PR

[phoerious]

To he honest, it is quite irrelevant WHAT the password is if it is long enough and long passwords shouldn't be an issue anymore with a password manager.

In the end, all passwords are made of exactly two different "characters" anyway, which are 0 and 1. It's just a rather long and not entirely unpredictable sequence of those.

[sts10]

Maybe you've decided on a solution to my original issue, but I just thought of a potentially simpler solution: When on the "passphrase" tab, just have the strength measure go grey and remove the entropy number whenever the user removes any text from passphrase field, and only bring it back when a new random passphrase is generated. It's a nice signal of "hey, you're on your own now".

And by only taking this route when the user removes text, we don't punish users for adding special characters to the end of the passphrase, which may be necessary to get around password requirements. When users add characters, you could either maintain the original passphrase entropy or switch to zxcvbn.

(I removed a long paragraph from this comment after doing some more thinking. Might be something worthy of a separate issue.)

[gwillen]

I see this thread is a bit old, but I strongly agree with @sts10: Clear the entropy meter if the user starts with a diceware passphrase and then removes anything from it.

I would go further and say that the practice of entropy estimation for user-entered text is not a good idea without a warning that it's not to be trusted; but I'm going to file a separate issue with my thoughts about what's wrong with entropy estimation. It's along the lines of @sts10's comment further above: "... how almost-nonsensical the idea of a "correct entropy" is [for a user-entered string]".