Keepassxc: Integrated Password Analyzer and Health Check [$170]

[andkopp]

Another point for the wish list: I am looking for an integrated password analysis tool that evaluates the passwords in my database both for their equality or similarity among themselves, their password strength as well as their age.

Regarding the implementation, I can imagine several variants. It could be a separate menu point, over which a test procedure can be started. At the end of the check, the result per database entry is displayed in a list. The list should be filterable according to problem type and criticality.
Another possibility would be to always check the passwords in the background. For each entry, a kind of traffic light (eg green, yellow, red) and, if necessary, a warning message is displayed which indicates how secure the password of an entry is.

Examples of warning messages:

• The password is used several times in the same or similar form (the entries x, y, z... use a related password)
• The password is not strong.
• The password is quite old (the older a password, the higher the probability that it could be stolen in an attack on the vendor).

Edit: The following plugins for the original Keepass try to achieve the same or similiar goals.

• Password Counter
• StrengthReport
• QualityColumn
• QualityHighlighter

[droidmonkey]

Also add support for displaying expired passwords.

[tycho]

Was about to file an issue requesting this feature. The password strength estimation stuff is already in there, this seems like it would be mostly UI work.

This could be partially solved by adding a new Entropy column to the list of entries. It could probably be a combination of numeric entropy value and the visual indicator used in the password generator. To find weakest/strongest passwords, I could just sort by that column.

To find old passwords we can already sort by the Modified date column, although that is potentially very misleading, depending on how you manage your entries. It changes with -any- modification, including changes that don't touch the password field at all (e.g. adding a TOTP or icon would count as "modification", so you might think that a recent modification timestamp means the password was changed recently but this isn't necessarily true). The history of each entry is tracked though, so it should be possible to discover the last time the Password field was modified and have that as another column ("Last Password Change", "Password Modified"?).

[TheZ3ro]

I like the Entropy column approach.

For expired password I think it's for passwords that are explicitly tagged as expired, this will be easier to develop

[tycho]

Well in my case I haven't ever touched the "expiration" field, but I probably should start using it. It would be nice to just have it track how old the Password field is so that I could slowly work through the list of the oldest passwords and start changing them.

[TheZ3ro]

@tycho I think it needs more effort but indeed it's doable.

[droidmonkey]

Just sort by modified time, not perfect because any modification changes it, but better than nothing.

[tycho]

Already talked about that. I don't think sorting by Modified is at all useful for the purpose of identifying old passwords. See my comments above.

[droidmonkey]

There is no built-in mechanism in KDBX to store the last modified time of just the password field so there is nothing useful to use unfortunately. Expires is the best method without diving into custom data/attributes.

[tycho]

What about the modification audit log attached to every entry?

[droidmonkey]

Are you referring to the history?

[tycho]

Yes?

[droidmonkey]

That is not meant for determining individual changes, it is a literal copy of the entry in case of an error/typo/whatever. If you want to continue this please lets take it to the keepassxc-dev IRC channel. Thanks!

[tycho]

I get that it's not deltafied, but my point is that the data is there. You can walk history entries to figure out when the password value last changed.

[Skycoder42]

I think sticking to the expired field would be the best approach, too. Using the history would propably get way to complicated. Sorting by generelly last modified (the Entry, not the PW field) however seems to be a good idea. For most cases that's close enough to the "last time password changed", I think.

[z3ntu]

For me it's mostly that I still have the same passwords on some old sites I made an account very long ago (and imported my Chrome password store into Keepass back then).
I just checked the hash of that password on pwnedpasswords.com and apparently this password is included 15 times in dumps which is bad.
So just having the functionality of the db telling me, that I am using duplicate passwords would be a huge benefit for me as currently I have to manually go through each entry (and there are lots of them) and check the password.

[andkopp]

The last modification timestamp column is a good start for this topic. Thanks a lot for that.

I have never used the expiration field for several reasons: I didn't know if it refers only to the password field or to the whole entry. I also wasn't sure about if anything happens automatically once the password is expired (password gets deleted automatically?). I thought this field only makes sense for subscriptions (example: a one-year subscription for a backup service then I would fill in the expiration date of the subscription). And how would I find all expired entries before the column was added?

I like the approach of the entropy column. You can just sort all your entries after this column and change them one by one. And it works for all your existing entries in your database.

[phoerious]

Expiry is a property that is set on an entry. Expired entries are marked with a red cross, that's all.

[tycho]

@phoerious, I think @andikade is aware of that. What they're describing are user interface design concerns, first impressions. Reasons the average user would avoid the feature on intuition. And some of the impressions are the same thoughts I had when I first saw the feature.

[Skycoder42]

I agree with @phoerious on that. But we should definitly not forget the expired field, as it is important for more experienced users. Maybe a special sorting in the likes of "show expired entries first, then sort everything by last modified date" with the possibility to sort by other relevant factors like password strength etc.

[thom-nic]

I am more interested in sorting/ "auditing" an entire database based on strength and finding duplicates. I probably have passwords that are more than 10 years old but probably have newer ones that were lazily typed, duplicates. I'd like to find duplicate or weak passwords regardless of age. The original issue combines a number of ideas but so far the discussion has focused on age/ expiry.

[stefan1983]

+1

[ghost]

Might it be possible to include an option for enabling a default (and customizable) expiry delay? This would not help with already entered passwords but would help improve future behaviours?

[rugk]

Might it be possible to include an option for enabling a default (and customizable) expiry delay?

IMHO, this is a new feature request. As such, @hughmlwilliams, please open a new issue.

[rugk]

BTW, some input on how one may imagine this:
You have a button for a new window, which pops up and does a mass-analysis of all saved paswords. Then, it just shows the results ordered by "priority" (i.e. "how bad is this password/how soon does it need change"), maybe also colored by priority. And it should obviously show a description of why this password is bad.
Of course, it should allow you to easily change the password on a click.

The criteria could be:

• password is proven to be compromised, prio 1 (https://github.com/keepassxreboot/keepassxc/issues/1083), optional check
• password is weak (i.e. password strength check, with an optional small indicator as a column), prio 2
• password is duplicate, i.e. re-used, prio 3
• password is expired/"too old", prio 4
• maybe more...
• and maybe show all other passwords in "grey", so you can still check the criteria (see below)

Basically all the criteria can be shown in columns, so you can also manually sort it or check all other critera manually or so.

[ba32107]

Can the 'Show expired passwords on DB open' feature be extracted from this one? I think it should be relatively easy to implement. Something like #623 .

Many thanks
Balazs

[lectrode]

You have a button for a new window, which pops up and does a mass-analysis of all saved passwords.

It might make more sense for the password analysis results to be shown similar to current search results: re-use the top-left pane and the already-existing columns (instead of creating a new window). That way you already have all the same entry-access as in search results (View/edit entry, copy username/password, etc).

The Password Health column could be added to the default columns so it could be shown even when not specifically analyzing all passwords.

Depending on how long it takes to re-analyse individual passwords, this could be something done "on-the-fly" as you browse the different entries. If that introduces too much overhead, then password health could be a static value that is only updated per the following triggers:

• Analyze-all button
• Analyze this entry button (could be included in the right-click menu for selected entries)
• Option to re-analyze all at application start
• Every X amount of time (individual entries would have the last analysis expire - amount of time could be configured (global setting) and also used for gray color below to indicate the analysis is stale)

As for colors, you could have something like this:

• Spectrum: Green to Yellow to Red: Normal to Severity 1.
• Gray: old/stale analysis, or when analysis is being performed
  
  
  
  • (only needed if analysis is not done "on-the-fly")
  
  
  • (specifically when an analysis should be considered stale can be configured: x days, x weeks, x months, or never)
  
  

[rugk]

I argued for a new window, because:

• I see no use-case in analyzing only a subset of the passwords, i.e. when I want to analyze, I want to analyze all of them.
• I want much more columns than one "strength" column, also because this is hard to measure/express in one number or so. I know you think of a colored icon, and I would also like that as _one_ column, but it's very rough then. I'd rather want all the specific criteria as it's own columns (too).
• You may not want to leak details about your passwords/strength of passwords without a special confirmation, because someone behind you could see it and then try to exploit/break that "weak" password (i.e. "shoulder surfing" attack). Thus you would have to hide it (by default) as the password column itself (as with dots as the password), and I think this would be ugly.
• As for HaveIBeenPwned at least it can also check mail addresses, which would be hard to integrate/combine with one value/column of "password strength".

[lectrode]

• I see no use-case in analyzing only a subset of the passwords, i.e. when I want to analyze, I want to analyze all of them.

I can think of 2 off the top of my head:

• If analyzing takes a while, users may not immediately have time to analyze all of their passwords. A selective option would allow a user to analyze their most crucial accounts to see if any of those need to be changed right away.
• If a hypothetical forum has a data breach, and only has the information for the one account the person has with it, you wouldn't necessarily have to re-analyze all passwords right away, just the one(s) associated with that forum.

• I want much more columns than one "strength" column, also because this is hard to measure/express in one number or so. I know you think of a colored icon, and I would also like that as _one_ column, but it's very rough then. I'd rather want all the specific criteria as it's own columns (too).

The health column doesn't have to be very specific: it would provide a quick indicator that a password requires attention and should be changed, without bombarding the user with details. More information could be visible via tooltip, and maybe another tab in View/Edit entry (which would add another button for the bottom left panel to view that info when the entry is selected). You could still sort by most critical to least critical without additional columns.

• You may not want to leak details about your passwords/strength of passwords without a special confirmation, because someone behind you could see it and then try to exploit/break that "weak" password (i.e. "shoulder surfing" attack). Thus you would have to hide it (by default) as the password column itself (as with dots as the password), and I think this would be ugly.

A column that solely contains a colored bar/dot shouldn't be a risk, as a color doesn't really convey exactly what issues the password has. Red/critical, for example, would not differentiate between poor password, and one that has been leaked online. I don't think that's enough of a risk to hide by default, although the user could still do that per their preference (if they didn't want to see all the red without fixing their passwords).

• As for HaveIBeenPwned at least it can also check mail addresses, which would be hard to integrate/combine with one value/column of "password strength".

Email addresses can be similar to usernames: they're often intended to be public/shared. I don't think I have any email addresses that have not been involved in a leak, but that doesn't stop me from using them (after changing associated passwords). Not to mention that the only way to fix the "issue" would be to create a new email address, which is not something that's generally required or recommended.

I'd also argue that an email check is not as important as the password check and is out of scope for this issue, therefore it should not be a road block for implementing the password check. After all, this issue is specifically for an "Integrated Password Analyzer", not an email analyzer.

[lgallindo]

Is someone working on this?

[droidmonkey]

Not that I am aware of, you want to take it?

[lgallindo]

Not that I am aware of, you want to take it?

Yes, I'm going for it.

[ba32107]

Has the UI look and feel of this feature been decided? I think that the offending (weak) passwords should be prominently displayed on database open, either in a separate group, or a popup window, anything that attracts attention. The application should keep nagging the user until the passwords are fixed.

On a related note, may I get an approximate ETA on this? I don't want to rush Igallindo in any way, but if this feature is not expected to be completed in the near future, I would argue that #623 should be reopened as a separate, minor feature, as it was requested by several people over the past years. If people agree with this, I am happy to start working on it.

[tycho]

The application should keep nagging the user until the passwords are fixed.

No. Absolutely not. The password manager is not there to impose policy on the user. It's there to store the user's passwords and advise the user when they've asked it to do so. It should never ever nag the user for anything, barring extreme circumstances[1].

I don't like having weak passwords but sometimes there is no other option. Some institutions impose absurd password requirements (such as a low length limit or minimized character set) and there's nothing I can do about it. My password manager can tell me these passwords suck if I ask it to rate the quality of my stored passwords, but it should never ever nag to fix them.

[1] For example, if there was some weakness discovered in an older version of the password manager, it may be reasonable to alert the user about the issue and recommend that they take action.

[ba32107]

Well, then make this alert optional. I would definitely want the application to nag me (or to use another word: remind me) to fix these passwords, and I know I am not alone. There is no harm in adding a setting to show these alerts. My point was to give such option to those users who want this. I regularly have expired passwords because the application doesn't do anything to let me know.

[tycho]

That sounds like an orthogonal issue. I'd suggest creating a separate issue to track adding a user-configurable "nag policy" around those kinds of things (max age, min strength, whatever).

[ba32107]

That sounds like an orthogonal issue.

I agree, it's a separate issue. That's why I'm arguing to reopen #623 and offering to look into it.

Generalizing the alert is a good idea, but I can't think of anything that is not related to the passwords themselves and worth reminding the user about.

[wolframroesler]

Working on something related (#2034).

[wolframroesler]

@lgallindo are you still working on it? I'd like to get involved. Also, whatever the solution is, I'd like to integrate it somehow with the database statistics panel (#2034).

[droidmonkey]

I'm going to toss a few more dollars on the bounty for this

[wolframroesler]

Here are my solution ideas, based on what @rugk and @lectrode wrote above.

• Define a "password weakness score". The precise definition remains to be worked out; for this discussion, let's assume it's an integer that's 0 for a "perfect" password (whatever that may mean) and that's greater the "weaker" the password is.
• Colors are assigned to the weakness score, e. g. "0=green, 1-2=yellow, 3-5=orange, >5=red".
• Introduce a new menu item "Database -> Password Health Check". It pops up a new pane similar to Database Settings.
• Health Check displays entries in decreasing order of their weakness score, each with the associated color and with one or more reasons (e. g. "expired", "re-used too many times", "poor entropy", etc.)
• Health Check doesn't display "good" passwords (score 0). Of course, it also doesn't display the passwords themselves, only the group and entry names.
• The indicator color can also be displayed as a column in the regular entry table (top right pane).
• The indicator color is also shown in the entry form whenever the user edits an entry.
• The number of entries per weakness score is summarized in the statistics panel.

The idea behind the "weakness score" is that it is cumulative. For example, a short (but unique) password may be yellow and a frequently used (but long) password may also be yellow, but a short and frequently used password may be orange.

I'm assuming that the weakness score can be computed very quickly so that no "analyze this entry" button is required. May need to rethink that when accessing an online service like haveibeenpwned (cf. #1083), but we aren't there yet.

Will not check usernames (only passwords). Will not add nag screens :)

How does that sound for a first specification?

[ba32107]

I like the general direction of the feature and I think it is useful. However, looking at it from the perspective of expired passwords, I'm still unclear of how this helps a user keeping track of them. With the current proposal, I either have to open up a new dialog to perform this analysis, or I need to go through all my password groups, visually searching for the password strength indicator icon (which, for expired passwords is actually already there, as they are crossed out).

If there is no remind screen, how will the user notice the expired passwords without having to proactively look for them?

[lectrode]

If there is no remind screen, how will the user notice the expired passwords without having to proactively look for them?

Maybe instead of (or in addition to) the "Database -> Password Health Check" menu item, have a toolbar button? The button could have a count of passwords that need attention. Maybe it could link to the Database -> Settings -> Statistics. Potentially include checkboxes for which issues to show the count of.

[droidmonkey]

@wolframroesler try not to make this too complicated. A password is either weak or not weak, used often or not used often. We use Zxcvbn as our standard for password "goodness" and have thresholds already. You see this in the statistics page, the code I added. The important take away for the user is a simple way to identify deficiencies in their database and correct them fast. This would most likely include going to the website and changing their password so you should keep that in mind as well.

The password analyzer should also integrate with online API-based HIBP tools.

[ba32107]

If there is no remind screen, how will the user notice the expired passwords without having to proactively look for them?

Maybe instead of (or in addition to) the "Database -> Password Health Check" menu item, have a toolbar button? The button could have a count of passwords that need attention. Maybe it could link to the Database -> Settings -> Statistics. Potentially include checkboxes for which issues to show the count of.

In my opinion that is still too easy to miss. Using the application daily, I don't really glance at the toolbar, I only look at it when I create a new entry.

How about a native notification? Similarly to how Windows update reminds you to install the updates.

[andkopp]

@wolframroesler Thank you for your contribution on this topic! I really like the new statistics panel although I couldn't find it at first glance. I didn't expect it in the database settings and maybe other users won't either?

I think in the next step, users should be able to look into details. The statistics panels shows the number of non-unique, short and weak passwords and maximum password reuse. Now I want to double click the numbers and navigate to a list of the corresponding entries in order to change them.

[wolframroesler]

@andkopp thanks, glad you like it. I agree that "settings" is where you'd look for things that can be changed rather than reporting functions. Maybe we should create a new dialog that contains both health check and the statistics panel.

I've been thinking about a way to jump from the statistics panel (and, in the future, health check) directly into the affected items, or at least list them in some way, but haven't found a good (and doable) solution yet. Will keep it in mind however.

[wolframroesler]

@droidmonkey Great that we have something like a "password goodness" already, will build on it. Do re-use, expiration, and HIBP factor into it already? Because I'd like to see the same goodness criteria applied everywhere. There's no point in, say, just looking at the entropy in Password Generator, including re-use in Statistics Panel, and adding HIBP in Password Health; instead, a "good" password should be good everywhere, and for the same reasons.

Anyway, since we have zxcvbn already, I suggest we proceed like this:

1. Define a new function, work title "passwordHealth", which at this time is nothing but a front-end to zxcvbn
2. Invoke this new function wherever ZxcvbnMatch is invoked now
3. Add a new panel, "Password Health Check", which assists users in spotting and fixing poor passwords, where the definition of "poor" is based on the passwordHealth function
4. Extend the passwordHealth function to consider things like expiration, re-use, and HIBP

Once we have that, we could add other features like the active notification @ba32107 wants (for example, notify if passwordHealth declines suddenly because a password has expired or has been pwned), however we should take care not to pack too much into this issue.

[wolframroesler]

Not that I am aware of, you want to take it?

Yes, I'm going for it.

@lgallindo are you still working on this? Did you implement anything yet that we could build upon?

[droidmonkey]

@wolframroesler my thoughts exactly on the health function.

[wolframroesler]

The first part is very easy, here's a first shot: https://github.com/wolframroesler/keepassxc/compare/feature/healthcheck

Way too early for a merge request, but please have a look and let me know what you think.

i put the the passwordHealth function into the Database class because we'll need the whole database for the re-use check. We can invoke the function for a plain password or for an entry object; don't know if the former will be useful in the end, but so far it's used in the unit test. I decided to put it into a cpp file of its own, rather than into Database.cpp, because it has some includes of its own (zxcvbn for now, HIBP stuff in the future, etc.), and because Database.cpp is big enough already.

[droidmonkey]

Oh no please do not define class functions in a totally unrelated cpp file. I think it is more than appropriate to just make the health function a static function that takes a db shared pointer.

[wolframroesler]

@droidmonkey you're right and it doesn't get us anywhere. I reworked it to use a class (PasswordHealth), which fits much better into the existing applications. I also moved all entropy assessment ("weak if < 65" etc.) into the PasswordHealth.cpp file. Please have another look (same link as above).

[wolframroesler]

About integrating HIBP, it seems pretty easy to integrate, may take some ideas from this: https://github.com/fopina/kdbxpasswordpwned

[wolframroesler]

Added new menu item "Reporting" between "Change master key" and "Database settings" in the "Database" menu. Moved the statistics panel from "Database settings" to "Reporting", so that "Database settings" only contains things that can be changed, and "Reporting" contains information only (I'm sure you'll find it more intuitive that way, @andkopp; I do anyway). "Password Health" is going to be a new page in the "Reporting" dialog.

[droidmonkey]

Database Reports? Reporting is a verb, you want a noun there

[wolframroesler]

Non-native speaker here :) I remember having heard "reporting" in noun context, but that may have been something in the pseudo-English that people speak in this part of the world. Will change to "Reports" ("Database reports" would be too much "Database" IMHO, it's in the menu title and also in the following "Database settings", simple "Reports" will make it stand out better.)

[wolframroesler]

First look at the new "Database -> Reports" dialog. "Statistics" is as before (just moved here from Database Settings). In Health Check, nothing is there yet except the panel itself. Content to be added as I find the time.

I'm not sure yet if a table (as in Statistics) is the best way to display the health check information. Let's be agile and find out later.

[droidmonkey]

Damn I love it! Great icon, haha

[wolframroesler]

It's taking shape :)

This is the new "Database -> Reports" dialog in action. As I said before, "Statistics" is the same as before, just moved here from Database Settings; Health Check is new.

For Health Check, Password quality assessment is based on a score which is computed like this:

1. The initial score is identical to the password entropy.
2. If the password is expired, the score is reduced to 0.
3. Every time the password is re-used in another entry, its score is reduced by 15.

Passwords with a score of 0 or less are marked red ("bad passwords"). Score < 40 is orange ("poor"), score < 65 is yellow ("weak"), score < 100 is "good", score >= 100 is "excellent"; the latter two are not shown in Health Check. The limits (40, 65, 100) are identical to those used for entropy-based assessment e. g. in the password generator dialog.

So far, this is almost ready for a merge request, however I'd like to add one more feature: Double-click a row in the list to jump right into the entry editor.

How do you like it?

[ba32107]

Looks great! Could we also show the color indicator in the entry list? That would make it easy to notice weak entries.

[rugk]

Alos just a random comment and I have no idea how that works/is handled in Qt, but did you consider the accessibility of these colors, i.e. is there an "alt" text or so, so the entry colors can be noticed by screen readers?

[wolframroesler]

Putting the alt text straight into the table cell and setting identical foreground and background colors should do the trick.

[wolframroesler]

@ba32107 That would indeed be possible. I've added a function to the password assessment class that returns the color, that function could be invoked in the entry list. It would also be possible to configure the color column away, in case someone doesn't like it.

Will save this for later, however. I'd like to get the actual health check report finished first.

[wolframroesler]

First version finished, PR submitted. Looking forward to your feedback.

[wolframroesler]

Hello all, do you consider the requirements covered, or is there anything open?

[andkopp]

@wolframroesler Hi. Is there a compiled dmg file to try on MacOS?

[wolframroesler]

@andkopp I'm afraid I don't have one because I'm on Linux, and the automatic build doesn't seem to have created one (https://ci.keepassxc.org/viewLog.html?buildId=42860&buildTypeId=KeepassXC_MacOS&tab=artifacts).

Any Mac users around who can create a dmg from the branch in question (https://github.com/wolframroesler/keepassxc/tree/feature/healthcheck)?

[droidmonkey]

I need to review your PR, was going to wait until we release 2.5.2

[OLLI-S]

Would love to see this feature too

[OLLI-S]

Please add also the following warning message:

• Service/Website supports TOTP but it is not set up for the entry (https://github.com/keepassxreboot/keepassxc/issues/4096)

I would love to see in the tree view a new main knot that is called "security report" with the child elements

• duplicate passwords
• weak passords
• pwnd passwords
• missing 2fa (see above)
• old passwords

The password manager Enpass has this, this is called "Password Audit":

I would donate 20 USD for this feature if you add this feature easy accessible (in the tree or via toolbar button , not in the menu like you have it in KeePass)

[OLLI-S]

@droidmonkey Should I make a separate topic for my last sentence (make the password audit quickly accessible)?

[Nothing4You]

Just to have it noted here, no 2FA secret in KeePassXC does not mean missing 2FA.
Many people don't store their 2FA secret in their password manager to keep the goal of 2FA - actually having a second factor.

[OLLI-S]

@Nothing4You Yes, you are right. So when users store their 2FA keys in a separate app, then they should just ignore the list shown at Missing 2FA.

But even for these people the list can be interesting:
They see what websites they have in KeePassXC support 2FA and they can check in their Atthenticator app if they have set up 2FA for all these websites.

[OLLI-S]

In https://github.com/keepassxreboot/keepassxc/issues/1083#issuecomment-571751841 I suggested:

Next: you report "Expired Passwords".
I have many expired passwords and use them for accounts that I no longer use (where I want to keep the entry in KeePassXC and not delete it or move it to an "Archive" kdbx).

Here @wolframroesler replied:

About your expired passwords, you could simply delete them and retrieve them from the history when needed.

In KeePassXC I only know the history that is available for each entry.
So when I change the password, then I see the old one in the history.

Did you suggest that I delete the passwords of expired entries (so they are not used in any password check)?
Or did you suggest to delete the whole password entry (but where is here a global history?) ?

[wolframroesler]

@droidmonkey can you change the title of this issue to include the term "health check"? That'll make it easier to find it in the future.

[wolframroesler]

@OLLI-S

I would love to see in the tree view a new main knot that is called "security report" with the child elements [...]

The idea is that KeePassXC has only one function (called Health Check) that combines all of these. So far we have "duplicate passwords" and "weak passwords", it seems like we can't do "old passwords" because we don't know how old a password is (as discussed above; the suggested workaround is to use the expiration date), "pwned passwords" are covered in #1083, and "missing 2FA" in #4096. So, I suggest you donate your $20 as bounty on one of these issues.

[OLLI-S]

Password modification date

The HaveIBeenPwnd plugin for KeePass gets the password-modification-date from the history.
It looks when the entry was created in KeePass and checks via the history when the password was changed (when the password is different).
This way the password-modification-date can be used to check if the password was changed after the breach date.

If you get the password-modification-date then this can be used:

• show the password-modification-date in a new filed "Password Modified" in the GUI (Edit Entry -> Properties below the field "Modified")
• use the password-modification-date to check if users changed the password after a breach date (like the HaveIBeenPwnd plugin for KeePass)
• get old passwords

But I read at c't magazine that security experts say that old passwords are OK as long as they fulfill the rules of safe passwords. Changing passwords can also be dangerous...

Donating

I already donated $30 for Suggest TOTP #4096
When I suggested to have all these functions in the tree view, then my intention was to have them all accessible with one click (in KeePass I have multiple clicks).
So if you have one health report than these functions are all accessible with one click (I hope you add a button for this) or with two clicks.
So I increased - as I promised above - the bounty for this issue by $20 (my wife will kill me :-P )

Exclude Expired passwords

I still think, that an option to exclude expired passwords is a good idea (or to exclude a folder from the health check).

New Idea - Export Health Check

Please let me export the health report (CSV and TXT).
This way I open the exported file and go though it line by line and can change multiple passwords before I have to go back to the health report.
Without the export I have to write down 2-3 entries, change them, run the report again, write down, change and so on.
But maybe I should create a new issue here for this feature?

New Idea - Exclude and Entry from Health check

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 KeePass).
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?

[rugk]

So a checkbox "Exclude from health check" when editing an entry would really be helpful!

Generally good idea, but not a checkbox, but rather a context menu item when you select an entry in the health check -> "Exclude from health check".

[wolframroesler]

@OLLI-S If the question is "shall I create a new issue for that" then the answer is usually "yes". :) It prevents dependencies and avoids "never-ending stories" which are never finished because more and more features are requested.

Your donation is very much appreciated :) and give my regards to your wife. I'm sure she'll understand the importance of what we are doing here.

I like the idea of having a toolbar button for Health Check, however that should be yet another issue of its own.

@rugk Exclusion by context menu is great but we'll also need the checkbox, in order to undo the setting in case someone excluded an entry from Health Check inadvertently. Also, I like the idea of being able to exclude an entry from Health Check right when I create it. But let's discuss this in the new issue @OLLI-S is going to create.

[OLLI-S]

@wolframroesler
I created the following issues

• Health Report - Add Toolbar Button #4167
• Health Report - Exclude and Entry from Health check #4168
• Health Report - Export Results of Health Check #4169

I am really keen about this feature!

[wolframroesler]

Let's summarize where we are in the Health Check project.

Current status: Originally requested features are implemented (AFAICT), merge request submitted (#3993), awaiting approval.

Additional features, or new features building on those implemented already, have been requested:

• Check passwords against against online database (#1083)
• Report entries with missing 2FA/TOTP (#4096)
• Periodically remind user to run Health Check (#4167)
• Mark entries for exclusion from Health Check (#4168)
• Export Health Check to CSV or plain text file (#4169)
• Check passwords against a dictionary (#4186)
• Check re-used master password (#4200)
• Password rating column in entry table (#4216)

(EDIT: Updated list according to @OLLI-S's comment below)

In order to keep things nicely separated, I suggest we finish and merge the current issue before beginning work on the others. I've got some ideas about the HIBP thing, for example, and other developers may wish to join in.

So, regarding the current issue, is there anything left I need to add to the implementation before it can be merged?

[OLLI-S]

@wolframroesler in the list of additional features you may add these two features too:

• Health Report - Advanced Check for Insecure Passwords (dictionary) #4186
• Health Report - Check reused Master-Password #4200

I totally agree that implementing all these features separate (in separate merges) is the the best way.
I am so happy that all these features will be implemented (whenever you plan to implement them).

[ba32107]

Hi @wolframroesler, thanks for your work, this feature looks very promising. One question, does your PR include the password expiry warning? If not, which one of the above issues would incorporate this? None of them mention expired passwords explicitly.

[wolframroesler]

Thanks for the thumbs-up @ba32107 :) the expiry warning is already included in my PR.

[rugk]

Maybe you could introduce a new tag for all these features related to that whole thing? (Or a GitHub projects page??)

[LightTemplar]

So, regarding the current issue, is there anything left I need to add to the implementation before it can be merged?

Yep, it's a finding and merging of duplicate entries.
Issue #750, which was included here.

[wolframroesler]

@LightTemplar Health Check already reports duplicated passwords, but I think #750 is about entries that are duplicated as a whole, or very similar to other entries (say, same URL and user name but different password, because an entry was cloned, the clone was modified, and the original was forgotten). While I consider that an interesting feature, I don't think it belongs into Health Check because it doesn't affect password quality or security. Maybe #750 should be re-opened, and a definition of what it means that two entries are "similar" should be supplied.

[droidmonkey]

I don't think such a feature should exist. It is near impossible to tell if an entry is a duplicate or intentionally the same. You might have only 1 field different, is that a duplicate entry? It doesn't make sense to automate that process.

[LightTemplar]

@wolframroesler, I don't mind, if #750 will be reopened.

@droidmonkey, I think, the app should let user decide, what values should be same, to count entries as duplicate. I personally need username and second level domain name, sometimes even without first level, e.g. aliexpress.de and aliexpress.com - they should be in one entry, but now they are in different.

[droidmonkey]

Letting the user decide exponentially complicates the feature and implementation. From a cost benefit viewpoint it's not worth implementing. You can easily search for * and then sort the results by the various columns to find, and fix, duplicates in your database.

[LightTemplar]

@droidmonkey, I have 824 entries in the database. I don't think, that the option to sort them and go through all of them is the best solution.

[OLLI-S]

KeePass offers a feature to "Delete Duplicate Entries":

I have 1002 entries in KeePasXC and if I search for duplicate entries in KeePass, the 2 entries are found/deleted (I did not save the database in KeePass).
Finding these 2 duplicate entries out of 1002 entries manually is much work, so I think #750 should be re-opened. Defining what duplicate means is a total different discussion (that should be made on #750) but I would re-open it.

My plan - besides world domination - is to have some more database-maintenance tools (I will create separate issues for my suggestions).
So maybe you rename the title of #750 to "Database-Maintenance - Find/merge duplicated password entries"

[rugk]

I don't think such a feature should exist. It is near impossible to tell if an entry is a duplicate or intentionally the same.

Well… it is?
Could not you then just offer a list of duplicates and the user can choose:

• to either delete one entry
• or to "link" them (the thing you can do when you clone an entry and check the box "link username" and/or "link password"

This way, they are either marked as unintentional (duplicate deleted) or as intentional (then properly link them).

Use case
E.g. I have the problem with Stackexchange. Their 1000 domains are driving me crazy, as I of course want to have password-autofill on each page, but with same username+password.

--> I anyway wanted to have a solution for that problem too, because the current UX is not that good when you need to clone each entry again just to link them. (Because I still have old entries in there I need to delete.)

(maybe better to put that into a new issue, is not it? Although "duplicate finding" is exactly the problem/process I have here.)

[Techman]

I personally think that this feature should be implemented. Is there a special string that I can copy-paste into the search box to find duplicate entries?

If KeePassXC can report non-unique passwords and maximum password reuse in the statistics area of database settings, there should be a way to deal with that.

[droidmonkey]

What is duplicate to you is not duplicate to the next user. That means YOU need to decide what to search for to find duplicates. If you want to consolidate stackexchange entries, search for stackexchange. If you want to find entries with a similar field (Title, URL, etc) then search for * which shows ALL entries in your database. Then click the header you want to sort by and look for entries that are grouped together.

Aside from finding EXACT duplicates, automating this process is fruitless since it depends on how you define a duplicate between entries you are concerned with.

[OLLI-S]

You should add a feature called "Find Duplicates" and show a list with possible duplicate entries.
In the first column you show the title of the entry, in the second column you show a percentage of equality (100% means all fields are equal, 90% means that all fields except one field are equal).
You also should show the columns Username, Password (masked) and URL and above the table a checkbox to show the password in clear text.

In this form (below the table) you should also show a link to a documentation that explains how to avoid duplicate entries and how linking entries works (and what the benefit of linking is).

@droidmonkey I suggest that we continue the discussion in #750 and that you reopen it. Maybe you also change the title of #750 to "*Database-Maintenance - *Find/merge duplicated password entries"

[droidmonkey]

Fair enough, I reopened #750