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.