#1205 Quality estimation for Spr-variant passwords

[Ilia Barski]

The password strength is not correctly calculated, if the password is given as a reference. The quality in both the bits counter and coloured strip is made dependent upon the length of the reference formula but not upon the password itself.
For example the password field content {REF:P@T:blablablablabla} is estimated as more qualitative as {REF:P@T:bla} independent on which real passwords are contained in "bla" and "blablablablabla".

[Dominik Reichl]

KeePass currently doesn't dereference passwords before computing their quality. However, I agree that it would be a good idea to do so.

Moving to open feature requests.

Thanks and best regards
Dominik

[Dominik Reichl]

I've removed the duplicate that you posted in the Help forum on 2009-05-11 10:25.

Best regards
Dominik

[Gene Pavlovsky]

I want to vote for this feature being implemented one way or another. As a temporary measure, I think it would be better to not show anything at all in the quality meter, than to show some meaningless and irrelevant number of bits and character count.
I also think there's no reason to show password as asterisks in this case, it's better to show the actual reference, and it would be wonderful if the Repeat field would change to display the name of the reference target entry, and Show/hide button would change to follow reference button, allowing to open the target entry.

[Dominik Reichl]

For consistency, KeePass would need to Spr-compile the password (instead of just resolving field references) before estimating the quality. Implementing this would be rather complicated:

• Some placeholders can change frequently (for instance the {DT_SECOND} placeholder, which changes every second), thus the quality estimation would need to be updated all the time.
• KeePass would need to create temporary entries all the time, such that placeholders like {USERNAME} are correctly replaced by the currently entered data in such controls of the dialog.
• In order to handle field references to the entry itself, a temporary entry would need to be injected into the database. This is error-prone, especially in relation with multithreaded plugins.

Due to the high complexity and minor gain, I'm not planning to implement this in the near future.

However, I like the idea of disabling the quality estimation when detecting that the password is Spr-variant, and have implemented this now (for KeePass 2.33).

Here's the latest 2.x development snapshot for testing:
http://keepass.info/filepool/KeePass_160427b.zip

Thanks and best regards,
Dominik

[Gene Pavlovsky]

All right, that's better. If you say it's hard to implement, I understand you're reluctant, since it's not that important feature.
However, how about my suggestions:

I also think there's no reason to show password as asterisks in this case, it's better to show the actual reference, and it would be wonderful if the Repeat field would change to display the name of the reference target entry, and Show/hide button would change to follow reference button, allowing to open the target entry.

[wellread1]

I also think there's no reason to show password as asterisks in this case, it's better to show the actual reference,

I assume the idea is to override the hide password setting, and the Unhide Password policy if active, only for field references. It is already possible to reveal the password/field reference by pushing the reveal password button to the right of the password field. Also the new suppress password estimate option will indirectly indicate the presence of a field reference in the password field even if the password field is hidden.

If this feature is implemented, perhaps it could be a consequence of the new option.

it would be wonderful if the Repeat field would change to display the name of the reference target entry,

The UUID contained in the field reference, not the parent entry title, uniquely identifies the parent entry. It does take a small amount of effort to copy it, but it is already visible in the field reference and can be used to find the parent, and all entries that reference it.

To find just the parent entry using the UUID use the find command.

[Gene Pavlovsky]

Thanks @wellread1, I know that already.
Regarding asterisks, they just don't make sense because the text in the password field is not actually a password. There's no reason to hide it. Asterisks imply something hidden, secret, in this case it's just a reference to another item, nothing secret about that (probably the same UUID is referenced in the name field as well). This is just semantics, not related to usability.
The jump to referenced UUID button, though, would directly contribute to usability.

[wellread1]

There's no reason to hide it.

I am ambivalent. There are already leaks indicating that the hidden value is a field reference (e.g. 42 char length and atypically high quality).

The field reference UUID is an information leak. For example if five entries representing 5 different accounts have the same field reference in the username and password fields then someone inspecting the database knows that those five accounts use the same username and password. Whether this is a significant leak, given that the database is already unlocked is something to debate.

The jump to referenced UUID button, though, would directly contribute to usability.

Right, I missed that you want a jump to the referenced entry button. That would be nice, but it requires that the current modal Edit Entry dialog be closed automatically when the button is pressed. A non-standard button that closed the Edit Entry dialog would seem to me to be problematic. Additionally it is not clear what the button behavior should be: Save changes or dump changes.

[Dominik Reichl]

I don't really want to unhide Spr-variant passwords by default. What if the field contains secret data in addition to Spr-variant parts like field references? Even if the field contains just one reference, the information which entry field is referenced can be seen as secret information (not that much entropy, but anyway secret). Furthermore, it's not good from an UI experience point of view (for users it's already not that trivial to realize that the password field in the 'Edit Entry' dialog by default inherits the view setting of the main window); such exceptions should only be implemented in rare cases where it's really worth it. If the goal is to be able to quickly determine whether a password field is Spr-variant, maybe this could be communicated differently (e.g. by showing 'Spr-variant' on the quality estimation progress bar). Actually, it already follows from the fact that the quality estimation is disabled, but it's not mentioned explicitly.

For a 'Follow Reference' button, it's not clear how to "open the target entry". Closing the dialog of the current entry (with OK, Cancel or asking) is probably not a good idea, because the user likely wants to continue editing the current entry after having seen the reference target entry. Instead, a second dialog could be opened. However, this results in a chain of dialogs, and we run into similar obstacles as with the quality estimation (for example: in order to allow the second entry referencing data from the first opened entry, the first entry would need to be injected temporarily into the database). I don't think it's impossible, but again one of the cases where a huge amount of work would be required to get it right, with only a minor usability gain. Note that you already can click on a field reference in the entry details view of the main window to follow it; here are no problems, because the main window is not a modal dialog.

By the way, if this will be implemented in the future, a button probably is not a suitable control, as all entry fields may contain references and neither an exception for the password field nor buttons right of all fields makes sense. Maybe a context menu command would be a better approach, but then custom context menus for all fields would be required. Multiple field references within one field also would need to be handled properly (e.g. by making the command dependent on the cursor position).

Best regards,
Dominik

[Gene Pavlovsky]

Yes I get all your points.

Note that you already can click on a field reference in the entry details view of the main window to follow it; here are no problems, because the main window is not a modal dialog.

I didn't know that, this is actually the feature I was looking for. I don't really care if I do it from the dialog or not, maybe even better how it is now. All right I think I'm happy with the current solution.

[Gene Pavlovsky]

May I ask one thing? You keep mentioning Spr like it's some common knowledge thing, but I've never heard about it, nor did searching google reveal anything beyond Keepass-related mentions of Spr. I couldn't find some definition or explanation. What is that?

[Dominik Reichl]

I've now added a definition on the top of the page http://keepass.info/help/base/placeholders.html .

Thanks for the hint that this was missing.

Best regards,
Dominik

[Gene Pavlovsky]

Ok that is helpful. Thanks!

[Ilia Barski]

Well resolved. It is better to have no quality indicator as a misleading one.

Thanks,

[Ilia Barski]

I have found now in the Version 2.36 a function "Password Quality Report" which estimates the PW references in very correct way. Thanks.
Due to the new function it is now easy to isolate entries with unnecessary automatically generated passwords( they have all the same PW strength ).