-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Health Check - Exclude entries from check #4168
Comments
The new flag should exclude the entry not only from Health Check but also from the HIBP check (#1083). |
But once again the question is, how do we store the new flag in the kdbx file so that other KeePass clients stay compatible? Cf. #4293 for discussion. |
A simple flag like that should be stored in the custom data of the entry. Custom data is meant to be non-user editable attributes for plugins to use. Core features like "password modified time" can also be stored there, but it is not appropriate (per the conversation had in that thread). The benefit to custom data is that all KeePass clients read it in and write it out regardless on whether they use it or not. |
@wolframroesler Excellent idea, it makes no sense to check these passwords also against HIBP.
@droidmonkey I like the idea to store this flag in the custom data, also because there will be no problems with other KeePass clients. |
Also for usability: In the health check windows, one should be able to just do a right-click -> "exclude from this check" (probably split it to "this check"/"from all checks" etc. depending on what is useful). |
I rally love this idea @rugk has made. |
While @rugk's suggestion gives the user finely-grained control over the checking process, I'd rather keep it simple and have something like a single "this is a known bad password" flag for every entry. If the flag is set, the entry is excluded from Health Check and HIBP, and a new row "Number of known bad passwords" is added to the Statistics report. Setting and clearing the flag is possible from the entry editor dialog, and maybe it should also be possible to set (but, of course, not clear) it from the context menu of the Health Check and HIBP tables. The flag is stored in custom data; hopefully the authors of other clients will pick it up instead of re-inventing it when they have a similar requirement. Still thinking about ways to document custom fields like this one in a way that other client authors can benefit from (some Wiki perhaps). What do you think about that? |
I like it, the flag should reset if the password is changed though |
Not sure about that. The known bad flag usually means that the user can do nothing to improve the password (for example, my ATM PIN will always be four digits), so if the password changes (=I get a new banking card with a new PIN) it's probably still as bad as before. Do we really want to force the user to set the flag again? Wouldn't silently resetting the flag be surprising, like "why does this come up in Health Check again, I thought I set that flag"? Which brings us to the question where in the edit dialog to put the checkbox for the known bad flag. On the "Properties" pane? Sounds logical (it has all the custom fields already) but people rarely go there, nobody will guess that this is where you set a crucial security flag (if you consider Health Check and HIBP crucial for your security workflow, inadvertently setting the flag for a password would reduce security). "Advanced" maybe? It's crowded already. "Entry" then, so it's in plain sight all the time? My idea is to put it prominently next to the password itself, so we don't need more vertical space. In this case, we don't have to clear the flag when the user changes the password because the user sees the checkbox all the time anyway. |
By the way, how long until the feature freeze for 2.6.0? Would be great if we could get this in along with Health Check and HIBP. |
Just a POC/design suggestion. Checkbox behavior still TBD. Fixes keepassxreboot#4168
Just a POC/design suggestion. Checkbox behavior still TBD. Fixes keepassxreboot#4168
I don't want it on the main page, if anything this is an advanced feature. We can direct the user to the advanced tab to set it to ignore. This is an (rare) exception, not the norm. |
How about this, then? The "Advanced" page is quite full already, the attachment buttons even have some truncation on my system (the Additional Attributes buttons don't, for some reason). On my laptop's built-in screen I can't even make the window large enough to show the "known bad" checkbox without scrolling. Wondering if there really should be a context menu in Health Check and HIBP to set the flag. It would be super easy to set the flag but difficult to clear it, and I'm afraid this asymmetry is going to cause problems when people set the flag by accident. Like, a user right-clicks Health Check and slips the mouse, and suddenly an entry (the one that happened be just under the one the user wanted) is gone from the report. How is the user supposed to find out which entry he clicked inadvertently? We could show a "do you really want to" message box but that would remove the convenience of having a context menu in the first place. |
I really like the idea of @wolframroesler to show the checkbox directly behind the password field, because the checkbox belongs to the password, so these two fields should stand together. Edit Edit 2 |
@wolframroesler By the way, I would name the checkbox Exclude from Security Checks. |
From the context menu we can edit entries and (which is the actual motivation to add a context menu) toggle the "known bad" (aka "exclude from reports") flag. Fixes keepassxreboot#4168
to edit entries and toggle the "known bad" flag. Fixes keepassxreboot#4168
Just a POC/design suggestion. Checkbox behavior still TBD. Fixes keepassxreboot#4168
Previously was: Password is known to be bad, exclude from reports Now is: Exclude from security checks/reports (e. g. known bad password) because this is an entry-level setting and it's not only about the password. For eaxmple, the password might be good but it may be a duplicate of another entry so we want to exclude this entry from Health Check; in this case, "password is known to be bad" would be misleading. Changed internal names accordingly (e. g. OPTION_KNOWN_PAD_PASSWD is now OPTION_KNOWN_BAD). Fixes keepassxreboot#4168
Checkbox now sets/clears the KnownBad custom data field. Fixes keepassxreboot#4168
This realistically excludes ATM and SIM PIN from Health Check and HIBP reports, as requested in keepassxreboot#4168.
Previously, after editing an entry from out of the HIBP report, the entry would only be re-evaluated against HIBP if the password was changed. Now, we also re-evaluate if the "known bad" flag was changed. Fixes keepassxreboot#4168
These are usually excluded from the report. If the checkbox is checked they will be shown anyway, in a lighter color. This is mainly to allow the user to remove the known bad flag via context menu. Fixes keepassxreboot#4168
As Health Check before, HIBP now also has an option to show those items that are usually not shown. Fixes keepassxreboot#4168
Use a shining lightbulb instead of the generic "i in a circle" for "Database -> Reports". The main reason for that is that we need something that indicates "no report" for the "exclude entry from reports" context menu item, and we've got a crossed-out lightbulb. Fixes keepassxreboot#4168
From the context menu we can edit entries and (which is the actual motivation to add a context menu) toggle the "known bad" (aka "exclude from reports") flag. Fixes keepassxreboot#4168
to edit entries and toggle the "known bad" flag. Fixes keepassxreboot#4168
* Fixes keepassxreboot#4168 * Introduce a custom data element stored with an entry to indicate that it is a "Known Bad" entry. This flag causes database reports to skip these entries. * The current number of known bad entries is displayed in the statistics report. * Add context menu to reports to easily exclude entries.
* Fixes keepassxreboot#4168 * Introduce a custom data element stored with an entry to indicate that it is a "Known Bad" entry. This flag causes database reports to skip these entries. * The current number of known bad entries is displayed in the statistics report. * Add context menu to reports to easily exclude entries.
* Fixes #4168 * Introduce a custom data element stored with an entry to indicate that it is a "Known Bad" entry. This flag causes database reports to skip these entries. * The current number of known bad entries is displayed in the statistics report. * Add context menu to reports to easily exclude entries.
Dear @droidmonkey, |
I just tried to figure out where the folders came from, they are from Keepass 1.x (Backup) and Keepass 2.x (Recycle Bin) respecitively. |
Recycle Bin is already excluded as long as it is the official one for your database. We won't exclude folders by name. There is a feature request to apply the exclusion to multiple entries at once, that has not been implemented yet. |
@droidmonkey can you link the feature request? I can't find it. |
The feature has been merged to develop branch. Complete! |
Cool! Thanks! Looking forward to the next update! :) |
If this has been merged for 2.7.0, and the KDBX 4.1 standard has been implemented, don't they both do the same thing? |
No they are the same thing. We pushed to make this a standard and keepass added it to kdbx 4.1. |
Summary
I have some entries, where the password is a PIN (only 4 digits) but here only 4 digits are allowed.
I also have entries where I have unsafe passwords that I can not change (password of the website of my karate teacher, password of the emails of the karate dojo, where I manage the emails, email account of my brother, where I backup his password in KeePassXC).
So a checkbox "Exclude from health check" when editing an entry would really be helpful!
But maybe I should create a new issue here for this feature?
The text was updated successfully, but these errors were encountered: