Keepassxc: Check passwords against hacked password databases [$300]

[ghost]

haveibeenpwned.com has an API to check if passwords have been released in a previous dump.
They also provide a sha1-hashed download of their password dump at https://haveibeenpwned.com/Passwords .
Their API guideline is available here: https://haveibeenpwned.com/API/v2

Expected Behavior

Ability to check all or a selection of passwords against a password dump (either downloaded or online)

Current Behavior

Currently, KeepassXC does not check against a list of passwords that has been previously compromised.

Possible Solution (bash)

#!/usr/bin/env bash
PASSWORD=('p@55w0rd' 'P@55w0rd' 'password')
ONLINE=false
RELDIR="../pwnedPasswords"
OFFLINE_DATABASE=("${RELDIR}/pwned-passwords-1.0.txt" "${RELDIR}/pwned-passwords-update-1.txt" "${RELDIR}/pwned-passwords-update-2.txt")
check() {
    if ${ONLINE} ; then
        RESPONSE_POST=$(curl -s -o /dev/null -w "%{http_code}" --data "Password=${1}" "https://haveibeenpwned.com/api/v2/pwnedpassword")
        sleep 1.6
        RESPONSE_GET=$(curl -s -o /dev/null -w "%{http_code}" "https://haveibeenpwned.com/api/v2/pwnedpassword/${1}")
        RESPONSE=${RESPONSE_GET}
        sleep 1.6
        if [ ${RESPONSE} -eq 200 ]; then 
            echo "Bad password: ${1} (GET: ${RESPONSE_GET}, POST: ${RESPONSE_POST})"
        elif [ ${RESPONSE} -eq 404 ] ; then 
            echo "Good password: ${1} (GET: ${RESPONSE_GET}, POST: ${RESPONSE_POST})"
        elif [ ${RESPONSE} -eq 429 ] ; then
            echo "Too fast (wait >1.5s)"
        fi
    else
        if ! ${2} ; then
            CHECK=($(echo -n ${i} | sha1sum))
        else
            CHECK="${1}"
        fi
        LINES=$(cat ${OFFLINE_DATABASE[@]} | grep -i ${CHECK} | wc -l)
        if [ ${LINES} -gt 0 ] ; then
            echo "Bad password: ${1}"
        else
            echo "Good password: ${1}"
        fi
    fi
}

for i in ${PASSWORD[@]}; do 
    PASSWORDHASH=($(echo -n ${i} | sha1sum))
    check ${i} false
    check ${PASSWORDHASH[0]} true
done 

Note: Above script checks offline for security (slow). It can be modified to check online for testing.

Context

I would like to check for passwords that have been compromised in a breach or set of breaches.
I can currently do this manually with a modified version of the above script, but it is cumbersome and not as secure.

EDIT:
echo ${i} -> echo -n ${i}
Add note to script that it is meant for proof of concept and can be modified for offline use.
Modify script to check offline

[TheZ3ro]

I don't really like sending plaintext passwords over the web. Ok it's https but you need to really trust haveibeenpwnd. Sending sha1 is slightly better but still a no-no IMHO.

I think the best choice is to let user import a wordlist of pwned password and let KeePassXC do the comparison.

Also I will prefer this instead: https://haveibeenpwned.com/API/v2#BreachesForAccount

This is related to #551

[weslly]

Quoting haveibeenpwned.com/Passwords page itself:

Do not send any password you actively use to a third-party service - even this one!

[ghost]

I had been looking at using the downloaded password hashes, but I figured that online would be faster/easier to test against (the password hashes, when downloaded and unzipped are about 13 GB).

That is what I had intended on suggesting, but I haven't been able to figure out why my sha1sums are different from haveibeenpwned.com's hashes.

EDIT: needed to use echo -n instead of just echo.

[droidmonkey]

Honestly if you are using a randomized password greater than 12 characters the probability of being on that list are miniscule. It's not worth the effort to incorporate this. The entropy meter is far more useful.

[weslly]

Sending passwords to any third-party that isn't its own target website is just a really bad idea from a security standpoint and we shouldn't even offer the possibility to do so, IMHO.

But if you really want to do it, you can export your database to a CSV file and parse it with your script.

[mihaiile]

I would also vote against implementing this, it is not a good approach to send passwords/hashes of passwords to unknown websites on the web. Having the files locally would not help since they are huge and if you use a smaller version then what is the point in checking against a subset...

[ghost]

@weslly @mihaiile When testing, I don't like waiting 5 minutes to parse 13+ GB of text (especially when testing password). And yes, I agree that it is a really bad idea to check a third-party site directly.

@mihaiile I think it should be possible to implement a fast binary search on the text files (I believe they are in alphabetical order), if only by starting at byte (size / 2), reading to next newline, reading whole newline, checking if we need to go up/down, and going from there.

[phoerious]

SHA1-hashed passwords are basically plaintext. Never use SHA1 for passwords.

[TheZ3ro]

Just an update to this issue:
2 days ago Troy Hunt released v2 of his service pwnedpasswords.com with great improvements implementing k-Anonymity search.

Briefly, you perform locally the SHA1 of your password (that you want to check against the haveibeenpwned service), you take the first 5 characters of the hash and make an API request.
The service then respond with all the stored hashes that start with those 5 characters along with the count of how many times that specific hash is frequent.

If your local hash matches one of the returned one, your password SHA1 is already known and you should change it.
If not, the password is free to go.

Note that if you always use a newly random generated password of a discreet length this will be a no problem at all.

---

If you want to learn more check out "Cloudflare, Privacy and k-Anonymity" section in [1] or "How it works" in [2]

[1] https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/
[2] https://blog.agilebits.com/2018/02/22/finding-pwned-passwords-with-1password/

[phoerious]

I am still absolutely against this. Such a database can only be useful in two cases:

• you use and re-use a trivial password (then you are using your password manager wrong)
• you are using a service that is saving your passwords in plain text (don't use them!)

In any other case, all that can leak to an attacker is a properly hashed and salted password and you can't provide a lookup database for that, so the service is useless.

But guess how such a database can suddenly be filled with useful passwords... By you sending them your password to check if it has been compromised. I don't want to discredit the publisher of that database, but do we know what they are doing with our passwords?

I strongly advise against sending out your passwords. EVER! Even if it's just the first five characters of the password's SHA-1 hash. SHA-1 is NOT a hash function suitable for password hashing and the fact that you cannot salt the hash, makes it really easy to pre-calculate rainbow tables. Or just use a GPU brute forcer. With a beefy GPU cluster, you can hash up to 8 billion passwords per second with a fast hash function like SHA-1 these days. For a completely random ASCII password (128 possible characters), ALL possible combinations of an 8-character password can be generated in about 104 days. Taking into account that you will find the correct hash on average after 50% of the time, that's 52 days. That still sounds like a lot (actually, it doesn't, but it's still a bit of time and money blown), but then, we are using a totally random password and if you feel like a database to check your password against is useful, you are probably using a lot less characters. With only English uppercase and lowercase letters and numbers, you crack an 8 character password in 7.5 hours (3.7 on average). Scary, right? So don't use those databases. Use a strong password instead! Actually, use many. You have a damn password manager!

[zatricky]

@phoerious you have a serious misunderstanding/under-estimation of how much thought has been put into the service. Pwned passwords uses k-anonymity. The password or it's hash is never sent to any 3rd-party. Ever:
Local computer makes a non-salted hash of your password, sends the first 5 characters of the hash to HIBP. HIBP responds with all the matching compromised hashes - which the local computer can then use to verify actual matches.

See
https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByRange
https://en.wikipedia.org/wiki/K-anonymity

[droidmonkey]

@zatricky see #551

This application in no way whatsoever will ever silently send password hashes, usernames, or whatever over the network to be checked against a database. We will, however, offer multiple password checking (offline, possibly online too) services.

[zatricky]

"in no way whatsoever" and "possibly online too" contradict each other.

551's initial issue description doesn't mention online services, which is why I hadn't posted there. The other mentions of HIBP have been shot down unceremoniously (and of course unfairly in my mind) as a bad idea.

I'll move further comments there however.

[TheZ3ro]

@zatricky The service is well thought, but It doesn't have much utility if you already use a password manager.

In a password manager you can generate very long random passwords every time (and you should), so the probability of one being leaked is pretty low and the leak needs to be plaintext since you can't crack a very long password easily if it's stored as hash.
We need to teach users to generate new long password every time and never re-use them, instead of avoiding known-bad passwords.
Also PwnedPassword suffer of true negatives, for example "password" is present but "password1" isn't and you will think that the latter is a safe password, but it's not.
More about it: https://keepassxc.org/blog/2018-02-24-pwned-database/

An integration with haveIbeenpwnd is much more usefull.

[zatricky]

Going through #551 I realised it is more about UI than anything else, whereas this topic is more about backend support for things like the HIBP service. Discussion re HIBP there would actually be off-topic/spammy.

I agree that you shouldn't need a service such as HIBP if you only use generated passwords. Legacy dictates however that most users don't exclusively use generated passwords and don't follow password hygiene processes (something #551 will help rectify).

I don't agree with your example as a weakness - in that it addresses "knownpass" but not "knownpass1". It's not ever intended to address "knownpass1". It's intended to address the fact that "knownpass" is a known password hackers can actively use in their password-guessing attempts.

[zatricky]

The concerns I see so far:

• sending passwords out to 3rd-party services
  Don't do that. That would be stupid anyway. HIBP has disabled that specific facility - and with the range lookup, passwords can be checked without sending the password
• doing things silently without user consent/knowledge
  That's nonsense. Why would you do that without user knowledge? Educate the user. Give them "Useful tools". If of course you realise that it's *not sending passwords out, then by all means, do it silently and make the users safe. :P
• I don't like it
  ... that's not a good reason
• I don't want to do it myself
  ... then at least acknowledge that PRs will be given guidance toward acceptance

*Useful tools:

• User types/pastes a password into Keepass -> Give them an option to check it
• User imports passwords -> Give them an option to check it
• User generates a password using the random-pass-generator. Check it's entropy - but don't bother with stupid things like pw databases
• User runs the "hygiene wizard"/whatever-you-guys-come up with in #551: Give them an option to check the passwords

[rugk]

Mozilla announced it's integrating HIBP into (a) Firefox (extension?). And… _drumm roll_ a competitor (i.e. a different password manager) is integrating this feature!

I've explained this in detail in issue https://github.com/keepassxreboot/keepassxc/issues/2073, but here are the main point's on how I consider such an integration a very nice thing:

• obviously, you can make it opt-in, like the favicon fetching that also uses network requests e.g.
• it's way of sending only a part of the hash and returning multiple results make it anonymous so that HIBP can not realistically get any sense of the password
• more services like NextCloud have already integrated it

So you may wonder why use it, if we already use a password manager?

1. I want to know, which services expose my account details. You may say these services in the list save passwords with bad hashes and so on. That's totally true and a good argument to integrate that feature: Before a breach nobody can know their security practices, so getting aware that my password has been breached is a good indicator for the "quality" of that service.
2. I use a password manager, but the service can still be get hacked. I.e. if the password get's leaked, one must still change that. That's what such an integration would help with.
3. I have a lot of mail aliases, so checking each one manually in the web version is just not feasible.

Bottom line is: Please reopen this issue. HIBP's API has been improved quite much, you already use network stuff for unimportant things (favicons), so you may use it for this here, too.

BTW everyone who wants this, upvote the initial issue.

[rugk]

As for the anonymity again, some extracts from Troy Hunt's blog, where he explained that in detail:

By looking at the hash prefix sent to the service, I have no idea what the password is. It could be any one of those 477 or it could be something totally different, I don't know. Of course, I could always speculate based on the prevalence of each password but it would never be anything more than that - speculation.
[…]In response, a collection of hashes is returned that match that prefix (477 on average). By looking at the hash prefix sent to the service, I have no idea what the password is. It could be any one of those 477 [i.,e. the breached ones, he obviously knows, but these are compromised anyway] or it could be something totally different[, because 5 chars of an SHA-1 hash say not really much about the content], I don't know.

The Cloudflare article get's deeper into the math:

Whilst for secure hashing algorithms it is computationally inefficient to invert the hash function, it is worth noting that as the length of a SHA-1 hash is a total of 40 hexadecimal characters long and 5 characters is utilised by the Hash Prefix, the total number of possible hashes associated with a Hash Prefix is 16^{35} ≈ 1.39E42.

(highlighting by me)
Yet again: The number of hashed passwords associated with a 5-char prefix is 16^{35}! If it takes a computer only one millisecond to guess one hash, it would still take 4,42 * 10^31 years. That's much more than the age of the universe…

Small FAQ from me:
But SHA-1 is not secure for passwords!
Yes, but that's not the point here. Of course for storing passwords it is not secure, but here it is just used as a way to not sent the first 5 plain-text chars to the server. These are way too low to reverse it.
But the password is not salted!
Indeed, that's the point here. Actually salting makes the password more unique, which is not what we want. We rather want the part of the SHA-1 hash to be most generalized, so it is the same as many other passwords. As Cloudflare says:

In essence, we turn the table on password derivation functions; instead of seeking to salt hashes to the point at which they are unique (against identical inputs), we instead introduce ambiguity into what the client is requesting.

Also, please don't get into the "I don't want this/have no use case for this. This feature must be crap." attitude. Obviously many people requested it and the initial reason to close this issue (i.e. SHA-1 with full hash) is no longer valid. Please re-open this.I thought KeePassXC wants to do better and integrate nice features compared to KeePassX.

[droidmonkey]

I want to integrate new features, but not feel-good snake oil. The website is literally a giant advertisement for 1Password. If you can't see that, look closer at how many "SIGN UP FOR 1PASSWORD" links there are on every page. The dude is probably getting kickbacks for each referral sign up.

[rugk]

Come on… you don't have to like that "dude", yes. I also don't agree with everything he says, but can we please get over such personal disagreements and rely on facts (I've demonstrated the math and use cases above and you can see it is certainly not snake-oil.). Also, do you think Firefox, NextCloud, etc. would integrate such a feature, if it would not be worth it? (Okay, there they likely also catch many users without password managers, but the principle of changing your password of hacked service does not change.)

Also, sure he mentions 1Password and also states he likes it – after all it is a personal blog, so that's totally okay –, but of course he also mentions Firefox there, so is it a giant advertisement for Firefox, too???
And as for your sign up statement, the only text/link on the site itself is, because of the Disqus comments:

But let me reiterate: This is a personal blog and of course he may like that service and feature it in other articles, but well… that totally does not matter for that feature here.
So please discuss the feature and not random persons. It does not matter at all, whether you like the person there or not.

[droidmonkey]

We can just agree that maybe it will be implemented, maybe in the password analyzer, but not a top priority.

[zatricky]

Assuming #551 completion and that you don't already integrate it yourselves, would you accept a working Pull Request that abides by your code standards?

[rugk]

It's labeled with "help wanted", so I guess PRs are appreciated. :smiley:

[droidmonkey]

I always welcome PRs! If the code exists, putting it into the password analyzer is easy at that point.

[mihaiile]

I said in the beginning that this issue should be closed but the idea of sending first part of hash I would say that it is acceptable to do it given the user consent. So if this gets implemented as long as there is a button that the user specifically clicks to do such a remote request I guess I am more than fine with it. You are after all free not to use the feature if you do not want to.

[rugk]

As for this issue I imagine a simple button/menu entry "Check my passwords with HIBP". Maybe also an option in the settings to automatically check in an interval the user may select (1 time a day, a week or every 30days).

[TheZ3ro]

We wrote a blog post about our opinion on PwnedPasswd https://keepassxc.org/blog/2018-02-24-pwned-database/

Note: PwnedPassword and HaveIBeenPwned are 2 different service with 2 different objectives

Little response to @rugk

I want to know, which services expose my account details. You may say these services in the list save passwords with bad hashes and so on. That's totally true and a good argument to integrate that feature: Before a breach nobody can know their security practices, so getting aware that my password has been breached is a good indicator for the "quality" of that service.

I don't get how searching for your password in a central password database would give you any information about which services expose your details.
It only tells you if the password you submitted it's already in a past leak.
Note:
1) Only password from plaintext and sha1-unsalted leaks can be inserted in PwnedPasswords
2) There are many private/unreleased leaks we don't even know about

So the password list is incomplete and not exhaustive.

Also it's not an indicator of a password "strength" and neither an indicator of a service leaking your specific details (password collision on short human-generated passwords).

There are services developed specifically for password storage and leak presence. (https://pulse.michalspacek.cz/passwords/storages, https://haveibeenpwned.com/)

I use a password manager, but the service can still be get hacked. I.e. if the password get's leaked, one must still change that. That's what such an integration would help with.

Read above, use HaveIBeenPwned and not PwnedPasswords. With the former you only need to send your email.

PwnedPasswords is a good project for services.
A website should check a password from a user registration and tell them to change it according to its password policy, because most of users don't use a password manager and use easy-to-guess passwords.
A password manager should instead suggest for always using long random generated passwords.
Then if a service get owned and your account get leaked, a password manager can query HIBP, not PwnedPasswords.

[rugk]

Do the maintainer's of KeePassXC actually peer-review blog-posts before they are published? Would be good, because while the second part with the math and brute-forcing passwords is correct the first part misses the whole point of the database.
Of course HIBP's database (and it's not called a "Pwned databse" officially, but that does not really matter) is not intended for checking whether you generated a new secure password, i.e.:

So if you want a new and secure password, you can now easily check it against a fairly large collection of known bad and compromised passwords. Neat, right?

No, that's not what it is for. We have much better mechanisms for that, i.e. entropy checking or other password lists, which are in plain-text and just list common passwords. Of course though, it's not the best idea to check any new password against a 8GB püassword list anyway, but yeah…

Shorter answers for your comment here:

So the password list is incomplete and not exhaustive.

Of course, that's obvious and nobody claimed otherwise.

Also it's not an indicator of a password "strength" and neither an indicator of a service leaking your specific details (password collision on short human-generated passwords).

Nobody said that and you just got that idea by your blog post.

Read above, use HaveIBeenPwned and not PwnedPasswords.

Ah, now I see the issue you have: These services are actually the same. They both search for leaked username/passwords, but one queries by password and one queries by username/mail.
I just guess that for many leaks only passwords and no mails may be there, so you may not catch all if you just query by mail.
Also a password leaked for another mail address may anyway not be used for a different service.

---

As for password manager and long passwords: Yes, I also guess most users use long passwords in their PW manager. But do we know? Actually, I could imagine a use case, where one uses a not-so-complex one for quickly typing it when travelling/using another device. Or when they still have passwords they saved from the "pre-password-manager era" (i.e. when they did not yet use KeePassXC and did not change the password).
(But of course we all agree that there should be a password strength check, but that is a different issue and partly already done in KeePassXC. Anyway, we cannot force users to use long PWs and I am not sure everyone actually uses them. Actually one should always assume the worst behavior from users when in doubt about such things… Better save than sorry.)

---

Anyway back to this issue, to make one thing clear. Of course the HIBP integration should be:

• for passwords, as it has been said
• but also, of course for username/mails

In the UI there could just be a checkbox, so I can select what is used for querying the database.

[TheZ3ro]

They are not the same service

Here you can see the description for HaveIBeenPwned that specifically checks if your account is in a leak/breach

Here the description for PwnedPasswords that checks if you are re-using a know-bad password as per NIST policies.
This is not useful if you want to check if your specific account got leaked (password collision again) and it's not useful if you are generating a new password (use a random password or a diceware one, you have a password manager!)

NIST policies are targeted to websites, where users can register accounts, to check that the passwords they are using are good.
Those policies serve the purpose of educating users on using/coming up with safe passwords.

In a password manager:

• If you need to come up with a password, generate it randomly
• If you want to know if you are in a breach, check your email on HIBP

Then you don't need to check if your randomly generated password are safe

Read more on NIST policies https://www.passwordping.com/nist-csf-800-63b-passwords/
Note: PasswordPing is an alternative service to PwnedPassword :stuck_out_tongue:

---

I will stop replying for this issue, I've already explained my 2cent

[rugk]

I've already explained my 2cent

…and did not read my reply in all detail, as it seems. So I just quote myself:

They both search for leaked username/passwords, but one queries by password and one queries by username/mail.
I just guess that for many leaks only passwords and no mails may be there, so you may not catch all if you just query by mail.

Of course, the services are technically a bit different, but basically their aim is the same: Check a mail or password and find out, whether it has been breached. I does not matter what identifier you actually use and of course it makes no sense to integrate it into the password _generator_. Still, nobody talked about that, you just invented it there…

And PasswordPing seems to have an API with costs. They also cannot do more than Troy Hunt is doing, i.e. collecting public breaches, so it is totally stupid to ask for money for such a thing.

[TheZ3ro]

PasswordPing have indexed all common words in wikipedia pages instead of relying only on breachs, because the point in using this services is not checking if your password has been leaked but instead if the password you are using is common and easy-to-guess.
Anyway it was just an example. Nobody care about PasswordPing, PwnedPassword is the snake-oil trend.

They both search for leaked username/passwords

This is not true as I explained in my previous comment. You are not reading as well it seems, so I will try to make this clear for the last time.

I does not matter what identifier you actually use

It does.
For example, a breach can include payment details along with email and password.
If I search for my email, I know that only I can use that email and so I'm sure that my payment details were leaked.
If I search for my password maybe someone else use "helloworld" as password (as I do :stuck_out_tongue: ) and their payment details were leaked instead of mine.

But the most important point is:
Go to HIBP, insert your email and it tells you in which exact breach that email appears.
Go to PwnedPassword, insert "hello" as your password and it tells you the following:

This password has previously appeared in a data breach and should never be used. If you've ever used it anywhere before, change it!

[rugk]

Okay, for that payment example it makes a difference, sure. Anyway, can we just conclude they may have slightly different use cases? I don't actually care about which one to use, but you obviously do. So let's just offer both in KeePassXC.

As for PasswordPing it seems to be bit different and even more ridiculous. These password lists they use are actually also available for free for anyone to download, because they are used for dictionary attacks. So actually their service is a "pay for getting an API for querying password lists, that you could also get for free and use offline". IMHO, non-sense.
And compared to HIBP they have a different use case – similar to how you differenciate between username/password query. HIBP collects breaches, PasswordPing collects passwords. PasswordPing may want to be used for checking whether you use a common password, HIBP may only be used for checking whether you use a password that has been leaked to the public. These are different things, because when services store passwords in plain-text, also your very-long-secure4738274&RR&/"§&)-password can be leaked.

So yes, these things are slightly different, but all related, because when you want to check a password (strength), you may check all or some of them. Let's stop arguing what is better. Instead focus on the issue…

It has a clear plan what to do and some ideas. All other things should be redirected into https://github.com/keepassxreboot/keepassxc/issues/551, where any password strength/check may be included.

[thombles]

There is an interesting debate about this in the comments of Troy's latest post. I've read this GH issue pretty carefully and I'd like to highlight one use case (@rugk alluded to it but I'll state it more clearly):

• If my email address appears in a new breach, out of hundreds of passwords, how can I determine which account it was and which password needs to be changed?

Current situation: I need to hope that my risk is somehow "contained" because I was using long and unique passwords.

Ideal situation: I can somehow use KeePassXC and HIBP together to 1. identify the service that originally lost track of my password (they might not even realise!), and 2. re-secure that specific account. I _know_ that there is a password list in the wild and even if it affects only one account I would like to be able to fix it.

[green-nl]

Interesting topic is being discussed here.

Just few cents on use cases / user stories.

---

Find pwned entries

• Bob finds out from the news about breach of the service he used for years. He remembers that he used the same password on multiple occasions (sorry guys, but this is a fact, many users reuse passwords on multiple services, especially, when they don't know about existence of password managers :D )
• With the help of KeePassXC search function, he finds very fast entries that are compromised and changes passwords on all affected services

---

Find entries with the same password

• Alice learns that it is bad to reuse passwords on multiple services
• With the help of KeePassXC database analysis tool she finds entries with the same password and changes passwords such that there are no duplicates anymore

---

Check [subset of] the database entries against local / remote database

This has been discussed in length already. Maybe it is time to introduce yet another tool?

---

I was learning a bit the code... Searching for the passwords as well needs one line change altering behavior of current search widget. There are issues with my one line "fix" of current search widget though:

• It does not mask passwords
• It does not search through passwords only

So, I will be certainly looking into improving this...

[zatricky]

@green-nl: hopefully you've already seen #551, which this issue depends on. :)

[kwah-gh]

@zatricky: Thanks for the link.

Upon further thinking/reading submitted issues, it looks like there is time for Advanced Search / Filtering mechanism...

[Nerdy314159265]

@thombles That's exactly what I was thinking. The most important use case, in my mind, is automatically checking if a password of yours has been released in a data breach. I'm not interested in checking new passwords, since we obviously can just generate random 32 char keys in the manager, but in checking that any current passwords haven't been leaked and providing an alert mechanism for when they have been.

If the option is enabled, and I think it could be by default, an automatic check would be run occasionally, possibly after every new release on HIBP, and, if any passwords match, the entry would be highlighted in red until the password is changed and an alert box would pop up to let the user know the basic details of the breach (e.g. Company Name, URL, What was leaked and link to further details) which should hopefully be able to be gotten through the site.

[NikolausDemmel]

Came here after I got notified about my email appearing in the latest giant credential list added to HIBP and also reading about the recent integration of checking "Pwned Passwords" into 1Password.

Firstly, I'm a bit disappointed at the condescending dismissals ("snake oil") of some here on feature requests that are IMHO well formulated and reasonable. Of course you have to discuss what such a feature is useful for and in which situations it might give a false sense of security or be counter-productive, but it could maybe be done in an object / factual way.

I would just like to second the use cases for checking against a "pwned passwords" database from my personal prespective as a user.

• A while back I migrated from firefox password manager to keepass (and more recently to keepassxc, which I love, so big thanks to all contributors!) and I imported literally thousands of entries. I have started to go through them and update passwords with randomly generated ones, but it takes a looong time and (though I probably should do it asap) I won't likely complete this soon. Of course I already prioritised important and frequently-used services for this process, but an automatic check of potentially leaked passwords would give me another great way to prioritise this list of "passwords to update". Of course I realize that any password that does NOT appear on the pwned passwords list still needs to be changed!

• Even once I have strong random passwords for every service, it would still be great to notice when this (unique) password appears on a leaked password list, so I can change it, or re-evaluate if I want to keep using the service that leaked it. Some have said, one should use the email address to check for appearance in leaks, which of course I do as well (and an automatic check would also be a great optional tool for a password manager), but as others have pointed out in many cases that is not useful:

  • some leaks might not have email addresses associated with the passwords
  • I have many email addresses and aliases; hard to check them all manually
  • My email address already appears in multiple leaks. For some specific services I don't know which password was used at the time of the leak (and yes, I might have reused that password for other services at the time, shame on me), while other leaks like the recent Collection #1 is aggregated from many sources and the info "your email appears in it" is nice, but doesn't help me in the slightest to act on it (except for maybe "update all the passwords", which is just not feasible).

[rugk]

@NikolausDemmel For the first use case, you may also have a look at https://github.com/keepassxreboot/keepassxc/issues/551, which is IMHO the panel, where this here can be integrated.
As for the second, i totally agree. 😃

[NikolausDemmel]

@rugk, thanks for the pointer. Such an analyser tool as you describe it in your recent comment would indeed be very helpful for me for the first use case, and maybe also for periodic manual password hygiene once I updated all the old ones from the initial import.

[rocketraman]

I also came here after being notified by HIBP that my email address was contained in the same leak mentioned by @NikolausDemmel . My main use case is the second one mentioned by Nikolaus -- what I really want to know is, which of my strong unique passwords is in the credentials dump, so that I can identify which service I subscribe to that leaked my password.

IMO, this is one of the main benefits of having a unique password for every site, which is of course enabled by tools like KeepassXC. The fact that my address was leaked is not helpful at all -- I use the same address on hundreds of sites. But the fact that I can potentially identify which of those sites was compromised via my strong unique password is amazing!

So for me, this has absolutely nothing to do with password creation or checking hygiene of existing passwords (though those would be useful too), but rather with post-leak identification of accounts.

The fact that the API provided by https://haveibeenpwned.com/Passwords may allow me to do this without revealing my actual passwords is wonderful, and the ability for KeepassXC to leverage this would be super-cool.

[jsoref]

Fwiw, https://github.com/andrew-schofield/keepass2-haveibeenpwned/ is where I'd start...

[rugk]

@jsoref KeePassXC is not written in C#, so this does not help that much. And the HIBP API is quite straightforward, so it's not that this is really needed as a reference implementation.

[Tbaut]

+1 to @rockdreamer

I want to be able to find out (even offline once this list has been downloaded) what service/website leaked my password and change it.

Today with KeepassXC I simply can't.

[teresaejunior]

I believe it could be more useful to have a button to check all password against the API, instead of when creating new ones. Why? Because when we create passwords, we already try to make them as unique as posible, but if a website is hacked, checking all passwords may tell you one of your existing passwords may need to be changed.

[zatricky]

@teresaejunior: See #551, which this issue depends on.

@TheZ3ro Though it pains me to suggest as much, due to dilution and repetitive comments here, I think it's sensible to close this thread to contributors only (which would also exclude myself) until #551 is near completion. :-/

[yeonoson]

I created a simple bash-script for Linux that allows to check if any password stored in KeepassXC has been leaked by querying the HaveIBeenPwned database (https://haveibeenpwned.com/Passwords)

The script creates the sha1-value of the KeePassXC password and transfers the first 5 characters to the public API on https://api.pwnedpasswords.com. Thus, the password is kept safe locally. The script has been inspired by following Blogpost: https://medium.com/@monliclican/bash-one-liner-to-check-your-password-s-via-pwnedpasswords-coms-api-using-the-k-anonymity-method-a5807a9a8056

The script works on the CSV-exported data from KeePassXC. To create it, use the "Database > Export to CSV file" function and store the file as keepassxc.csv

Note: The script does not do proper CSV parsing, thus if the title, username or password contain a ; the script will fail.

To use the script you have to download it and make it executable "chmod +x hibp.sh.txt": hibp.sh.txt

[droidmonkey]

Your script should really use the keepassxc-cli

[telepath]

I'd like to check my passwords against HIBP, but I also don't want to submit any part, or hash, or part of a hash to anyone.
So I'm going with https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2724 to test against a local, bloom-filtered list.
I'd like this as an integrated feature, something that could periodically check my passwords against new leaks.
For now, I'll cobble something together with the cli.

[seanbreckenridge]

Despite 2.5.0 adding support for comparing against the HIBP database, that requires you to download the entire password hash database.

If someone would rather check their database against the Pwned Passwords API, I have some python here that does that.

[OLLI-S]

I am using the HaveIBeenPwned Plugin in KeePass (https://github.com/andrew-schofield/keepass2-haveibeenpwned).
Here I just need to start the check (via the menu entry) and everything runs automatically.
So such a feature for KeePassXC would be fantastic!

[droidmonkey]

@wolframroesler this would be an excellent thing to add to the password health screen. Willing to post a bounty to this.

[wolframroesler]

@droidmonkey agreed since there's obviously considerable demand, judging from the amount of discussion that has been going on here. Which surprises me, because I was under the impression that people who use a password manager do so because it allows them to use unique long random passwords for everything. (Well, even these can get pwned, e. g. when a service is hacked that stored them in plain text, even if that won't endanger any of the user's other accounts.)

The only issue I see about integrating online checks into the health panel is that the analysis could take considerable time, so we need some sort of caching, parallel queries, etc. Also, we need to consider cases in which the online service is not available (I'm using KeePassXC on one machine that isn't connected to the Internet, for example) -- we don't want "everything green" to mean "either nothing has been pwned or I can't connect to the validation service", and we certainly don't want to wait for dozens or hundreds of queries to time out. These requirements don't make it impossible but add to the challenge.

Anyway, a bounty would definitely help. Let's see how many are willing to add to it.

For reference: The health panel we're talking about is #551, currently awaiting approval (#3993).

[droidmonkey]

I would only do it when demanded by the user. A button on the health panel that initiated the check would be perfect. Then the results would be output to the panel itself. Bounty added!

[phoerious]

I am still off the opinion, that the HIBP password check is not extremely useful for users of a password manager (other than the HIBP username check), but perhaps I am totally wrong about this and 95% of the services leak passwords in plaintext and no usernames, who knows. It seems to be a quite heavily demanded feature for sure. I still wouldn't submit a SHA1 prefix of my precious passwords to some online service (particularly not my PGP passwords and other offline stuff), but that's just me.

[OLLI-S]

Sorry if this question sounds silly: what does it mean when there is a "bounty" tag added to the issue and a price added to the title?
Where can we add donations for this feature?

health panel

Where in KeePassXC is the health panel?

[droidmonkey]

Bounties for this and other issues can be added at https://bountysource.com/teams/keepassxc

Bounties are awarded to a person who submits a Pull Request that meets the requirements of the issue and gets merged into the code baseline.

[OLLI-S]

If I understand this correctly I can donate money just for the whole project, not for a specific feature?

[droidmonkey]

On Bountysource you donate per issue. To donate to the project go to https://keepassxc.org/donate

Some proceeds from donations go to issues we want help with (like this one).

[OLLI-S]

@droidmonkey can you please explain me the donation process (by answering the following questions)?

Some topics (like this here) have a bounty-tag and also a money-value in the title like [$250].
If I understood you correctly then any programmer, that codes the requested feature, gets the money-value in the topic title?

When I look at Bountyssource for this topic (ww.bountysource.com/issues/50410294-check-passwords-against-hacked-password-databases) then I see that there is a bounty of $250.
When I add $10 is then the total bounty increasing (to $260) or is it like cround-founding (I pay $10 so only $240 are remaining)?

Greetings from Germany

[droidmonkey]

1. Yes
2. The money shown is what has been donated to the issue. If you add $10 then it will go to $260

[aha999]

If you're worried about sending passwords to unknown websites, Keepass could be hosting the latest haveibeenpwned password database/passwords file, and by checking, you would check the passwords via keepass website/database

[OLLI-S]

@aha999 Currently I am using KeePass and also the HaveIBeenPwned plugin (see my posting above).
But I consider switching to KeePassXC, so it would be nice to have this functionality here...

[phoerious]

@aha999 That doesn't solve the problem. You can already download the password dump and use the CLI to check your passwords against it offline. Putting it online on our server only delegates the problem from Troy to us.

[wolframroesler]

@OLLI-S

Where in KeePassXC is the health panel?

It's an upcoming feature (#551), currently undergoing review (#3993). It will hopefully be rolled out with KeePassXC 2.6.0.

[aha999]

@phoerious yeah, but unless you are ready to download 13gb of passwords and some said that they don't trust 3'rd party websites, i don't see what's wrong with using the keepass' website as a passwords host & checker, since that's the program you're using, plus it can probably better integrate into the app.

[nazar-pc]

I'm not sure it was discussed before, but in order to check password you don't need send it anywhere.
Typically you hash it, send a few first characters of the hash and receive back a bunch of full hashes with known compromised passwords.

Just take s look at HaveIBeenPwned API, it is not as dumb as you may think: https://haveibeenpwned.com/API/v2#PwnedPasswords

[phoerious]

I know how it works. But I said I don't want to send partial SHA-1 hashes of very sensitive data. They could have used any other better password hashing scheme.

[OLLI-S]

@wolframroesler
Thank you for sharing the Issue-ID and the Review-ID containing the screenshot.

Here I see that the column containing the colors only offers colors to differentiate the values.
If you have a user suffering on Color-Blindness, (8% - 10% of all males are affected) they will see it like this (I used the "Color Contrast Analyzer to simulate color blindness):

In our software-ergonomics reports we would report this as an issue, because color should never be the only criteria to identify information.
There should also be a text, a icon, a shape or something else.

I see that the colors are different when you simulate color blindness.
But depending on the user that is suffering on this, he can se more or less red or more or less green.
So the colors can be very similar depending on the user.

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

So please consider an option where I can select what should be checked.
Idea: add some checkboxes like "duplicate passwords", "weak passwords" etc. so I can uncheck "Expired Passwords".

It is really amazing how active this community here is and how KeePassXC is making progresses.
So thank you all for your fantastic work!
I love to help here with my crazy ideas and my donations.

[wolframroesler]

@OLLI-S Your ideas are welcome and so are your donations.

The shades of yellow in your screen shot don't look too bad to me. Seems like the lightnesses of the colors are sufficiently distinct to convey the information. I'm thinking about adding icons to indicate severity along with the color (after the new icons are available, cf. #475). About your expired passwords, you could simply delete them and retrieve them from the history when needed. But let's discuss Health Check in the Health Check issue (#551).

[telepath]

I know how it works. But I said I don't want to send partial SHA-1 hashes of very sensitive data. They could have used any other better password hashing scheme.

I have the same concern. But after reading the background of the used method, I'm now reassured that there is no risk here:

• https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/
• https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/, and I quote:

it is worth noting that as the length of a SHA-1 hash is a total of 40 hexadecimal characters long and 5 characters is utilised by the Hash Prefix, the total number of possible hashes associated with a Hash Prefix is 16^{35} ≈ 1.39E42.

Anyone still afraid of those odds should not be on the internet at all.

[wolframroesler]

Given the latest news about SHA-1, I'd expect HIBP to support alternatives hashes sooner or latter, just to avoid the poor reputation (à la MD5).

[nazar-pc]

I do not think so. You wouldn't be able to extract password from 5 characters anyway and matching collision doesn't mean actual password is the same. So either way, the way their API works is perfectly fine.

[wolframroesler]

I've been thinking about how to integrate HIBP (or a similar service) into the Health Check panel and/or Reports menu. Will write down my ideas here when I find the time. Will begin the implementation after #551/#3993 have been merged, so that I can branch off develop (don't like one branch to be branched off another branch, it only leads to trouble and seat wetting. Merge conflicts, I mean.)

[ImUrX]

@wolframroesler care to "start" the bounty when you can? I read a lot of text BEFORE finding out its going to be done by someone more experienced in the repo

[wolframroesler]

@ImUrX is there anything like "start the bounty"? AFAIK you claim the bounty after finishing, but you don't start it when beginning.

[ImUrX]

Yeah, you can just claim it without saying you started it, I just use ctrl
f to see if someone started it so I don't make a battle to the death with
someone

On Friday, January 31, 2020, Wolfram Rösler [e-mail]
wrote:

@ImUrX https://github.com/ImUrX is there anything like "start the
bounty"? AFAIK you claim the bounty after finishing, but you don't start it
when beginning.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/1083?email_source=notifications&email_token=AA4G4PKMYMCCYAFSOQBD4LLRAR5ZZA5CNFSM4D7Q4LY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKPZD7I#issuecomment-580882941,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4G4PPNOSIQ4C7VIEW3PB3RAR5ZZANCNFSM4D7Q4LYQ
.

[wolframroesler]

Claim the bounty before having started? What's your opinion on that, @droidmonkey?

[ImUrX]

Wait wait, I meant started it as the button "get started" in bountysource,
I don't know how it exactly works but if everyone that funded votes yes,
you can receive the money

On Friday, January 31, 2020, Wolfram Rösler [e-mail]
wrote:

Claim the bounty before having started? What's your opinion on that,
@droidmonkey https://github.com/droidmonkey?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/1083?email_source=notifications&email_token=AA4G4PMJKWFR6IXDI3AEZSLRASDEJA5CNFSM4D7Q4LY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKP5ISI#issuecomment-580899913,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4G4PJKGZPXAG5XXV3WP3LRASDEJANCNFSM4D7Q4LYQ
.

[droidmonkey]

You can't claim the bounty until the associated PR closes the issue (or the issue is closed manually). We have it here recorded that you are going to work on it. I'm merging the health report PR tonight, so you can claim _that_ bounty.

[wolframroesler]

Tried to set "get started" on https://www.bountysource.com/issues/50410294-check-passwords-against-hacked-password-databases but it says "issue already taken". Do you know if anyone's already working on this, @droidmonkey?

EDIT: Now it says that it's me who's working on it. Seems like the bountysource website is a little confused. Sorry for bothering you.

[wolframroesler]

Here are my thoughts about how to do it, and some questions.

Which service?

I think we all agree that by "hacked password database" we mean "have I been pwned" (HIBP, https://haveibeenpwned.com/). It offers an API for online checks, and offline checks (against a previously downloaded HIBP database) are already implemented in the KeePassXC CLI. What we want here is integration of HIBP into the GUI part of KeePassXC.

Online or offline?

Offline checks require a downloaded HIBP database. The problem is that the database is several gigabytes, and that's too much for users with slow Internet and/or small harddisks. Also, remember that the database keeps being updated and thus needs to be re-downloaded once in a while. Another question is if downloading can (or should) be automated; users may not have the skills to download it manually (and asking them to do so would be horrible UX).

Online checks require an API key from HIBP, which must be purchased for US$ 3.50 per month (details on https://haveibeenpwned.com/API/Key). @droidmonkey: Does KeePassXC already have an API key? If not so, is the expense tolerable? Can you manage the API key purchase/subscription thing?

For the online check, some information about the user's passwords (e. g. a hash) needs to be sent to the HIBP server. Even if this information cannot be used to recover the password, the query still exposes user data (IP address, number of passwords, etc.), so users may chose to check offline even if we make online checks possible.

My suggestion is: Purchase the API key, make online checks the default, allow offline checks for users who really want them, and let them manage the downloading themselves (e. g. allow them to enter the HIBP database file name somewhere in the KeePassXC settings and leave the rest to them).

GUI integration

It seems natural to integrate it into the new Health Check (cf. #551). Here's what Health Check looks like:

Health Check works by assigning a score to every database entry. The score starts with the password entropy and is reduced if the password has issues (minus 15 points every time the password is re-used, etc.) Health Check reports all entries below a certain score.

So, my first idea was simply to further reduce the score when a password has been hacked according to HIBP, and thus make HIBP an an integral part of Health Check.

I don't think that's a good idea, however. First, if we decide for online checks, HIBP may not be available (no Internet, site down, etc.), or the user may not want to have information about his passwords sent to an online service, so we'd need a setting to turn HIBP integration on and off. Second, the existing Health Check appears instantly but checking (both online and offline) will take time, so after turning it on the user will have to wait while his passwords are being checked. The problem I see here is that we're getting two versions of Health Check, the regular one (database-only) and the HIBP-checked one. No matter how we implement the switch, people will confuse the two, forget to turn HIBP on, get different results on different machines (because one does the HIBP check while the other doesn't), will search for HIBP results and not find them because they're hidden in Health Check, etc.

I'd rather have Health Check stay as it is, and add HIBP as a third option in the "Reports" pane (which you invoke with the menu item "Database -> Reports" that was introduced along with Health Check). Something like this:

The "HIBP" report does the following:

1. If online checks are to be used, display a warning message telling the user that information about his passwords is about to be sent to an online service for validation. I feel bad about sending anything to the Internet without asking for permission first.
2. Validate all passwords either through HIBP's online service or against the downloaded database. This may take some time (even if parallelized).
3. Display the results in a table similar to Health Check. (Be smart and display results as they come in while the remaining passwords are still being checked.)
4. Maybe cache the results somehow to make the report come up faster the next time. (Not sure yet if and how to do that, though.)

Does that sound reasonable to you?

[wolframroesler]

Requested a HIBP icon from the "simple icons" repo (https://github.com/simple-icons/simple-icons/issues/2516).

[droidmonkey]

Wait HIBP costs money now? Man I called that one!!!

[droidmonkey]

Ideas:

1. This should be a selection process where you can select which entries to send (with a select all/none toggle). Perhaps also by group.
2. You can cache the results in the entry's custom data. HIBP_FINDING = [value]. Upon subsequent checks if the finding it true then we don't send it to HIBP anymore (we know its pwned). If the user changes the entry's password we reset the finding.

[wolframroesler]

Not only does it cost to use the HIBP API, but there's a rate limit of one API query every 1.5 seconds per API key. https://haveibeenpwned.com/API/v3#RateLimiting That means that online checking is essentially unusable for us unless we require users to purchase their own API keys, which I consider a total no-go.

[droidmonkey]

Perhaps we can abandon this before too much effort is put in. That rate limit is ridiculous.

Edit: Looks like the rate limit does not apply to pwned password searches. Only breach and pastes.

[wolframroesler]

1. This should be a selection process where you can select which entries to send (with a select all/none toggle). Perhaps also by group.

That should be the same setting as "exclude from Health Check" (#4186).

[phoerious]

Or we have to bootstrap a service ourselves.

[wolframroesler]

Or we have to bootstrap a service ourselves.

Which I'm afraid will sooner or later suffer from the same problems that made Troy introduce the rate limit and API cost (https://www.troyhunt.com/authentication-and-the-have-i-been-pwned-api/).

[ImUrX]

The pwned passwords API is free, its said at the end of this blog
https://www.troyhunt.com/authentication-and-the-have-i-been-pwned-api/

On Saturday, February 1, 2020, Wolfram Rösler [e-mail]
wrote:

Or we have to bootstrap a service ourselves.

Which I'm afraid will sooner or later suffer from the same problems that
made Troy introduce the rate limit and API cost (https://www.troyhunt.com/
authentication-and-the-have-i-been-pwned-api/).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/1083?email_source=notifications&email_token=AA4G4PJKLB6GXMBTHVOF7CTRAXQJ5A5CNFSM4D7Q4LY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRGVYI#issuecomment-581069537,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4G4PI3EVRN6WNBJPZTT6LRAXQJ5ANCNFSM4D7Q4LYQ
.

[wolframroesler]

Looks like the rate limit does not apply to pwned password searches. Only breach and pastes.

You're right, I hadn't read that part yet. Searching breaches (=compromised accounts) would be nice but searching passwords should do.

That leaves us with the problem of how to protect our API key. On https://www.troyhunt.com/authentication-and-the-have-i-been-pwned-api/ he writes,

Rich client apps designed for consumer usage ... will need to proxy API hits through their own service. You don't want to push the HIBP API key out with the installer plus you also need to be able to control the rate limit of all your customers so that it doesn't make the service unavailable for others (i.e. one user of Secrets smashes through the rate limit thus making the service unavailable for others).

which means we end up with @phoerious' suggestion of running our own service.

[ImUrX]

@wolframroesler ouch, the api does not use a key lol
Here have an example link https://api.pwnedpasswords.com/range/21BD1

The pwned passwords API is free, its said at the end of this blog https://www.troyhunt.com/authentication-and-the-have-i-been-pwned-api/
…

[OLLI-S]

First of all: @wolframroesler I really like your concept you descrobed here: https://github.com/keepassxreboot/keepassxc/issues/1083#issuecomment-581065795
It covers many features that I had in mind for this idea.

In the past (before I switched to KeePassXC and became a huge fan of it) I used KeePass and also the HaveIBeenPwned Plugin for KeePass (https://github.com/andrew-schofield/keepass2-haveibeenpwned).

So here are my thoughts about this feature:

Offline/Online Checks

I think it is a good idea to let the user decide if he wants an online check or an offline check.
But you should tell the user what his decision means:

• That for an offline check a larger database (xx GB) has to be downloaded but here no data must be sent to the HIBP servers
• For an online check no database must be downloaded but here hashed passwords will be uploaded to the HIBP servers.

About the costs/query limit:
Maybe you look closer at the HaveIBeenPwned Plugin for KeePass how this plugin handles this limitation or if they have an API key.
I think they have no API key and I don't recognize any limit here (under the aspect of a normal user).

Separate option/integrated in the Health Check

I think the HIBP check should be a separate option, like @wolframroesler suggested in his screen shot:

The reason is that a PWNED password is more dangerous than a duplicate or weak one.
So I think the HIBP check should be a separate check to the Health Report.

Chek for several conditions

The HaveIBeenPwned Plugin for KeePass allows to check for several conditions:

Check for breaches based on site/service

The HaveIBeenPwnd plugin for KeePass checks your websites (URLs) against the HIBP database.
If one of your websites is affected (breached), then the plugin determines the password modification date for the KeePass entry (it gets the date when the entry was created and checks in history of the entry when the password was last changed).

If the user changed the password after the breach date, then the entry is not reported.
If the breach date is after modification date, the entry is alerted.
This feature was first implemented in the plugin.

The marked options are important, the first option checks for HIBP and for Cloudbleed:

When I deactivate "Only check entries that have not changed since the breach" then I get all breached entries, also those where I changed the password after the breach:

You see that the "Password Changed" date is after the "Breach Date" so I changed all affected passwords after the breach date.

In my opinion this check is very important!
Even if I have used a unique password for the breached service, it is important to know that the service was hacked and that I should change my password immediately!

Check for breaches based on username

If I run this report in the HaveIBeenPwned Plugin for KeePass then I get the following message:

So we now know that the HaveIBeenPwned Plugin has no API key and that the check for sites is possible without an API key.

In Bitwarden I have the "Data Breach Report" where I enter an username/email address and get the results shown:

The problem here is, that I have to enter all usernames manually.
It would be more comfortable if KeePassXC gathers all unique usernames in my database and checks them against the HIBP database.
One click for the user instead of many clicks and having to enter all usernames manually.

Check for breaches based on password

If I start this report, then the options dialog is shown but here option "Only check entries that have not changed since the breach" is not checked (this can also not set by the user):

If I start the check, then a progress bar is shown (the entries are changing very fast, so there is not 1.5 seconds delay between each password):

The results look very similar to the check by website/service:

In Bitwarden I also have the "Exposed Passwords Report" where my test-password was found as exposed:

Let the user select...

You should add the following radio buttons above the table with the results:

• check by website/service
• check by username
• check by password
• check all (may take while)

So the user can select what service should be checked.

I would not offer these options in the UI (by default they are checked so users see only entries where he has to do something):

• Only check entries that have not changed since the breach
• Ignore deleted items
• Ignore expired entries

Maybe you have a button "Advanced Options" where the user can set these options.

What the results mean

The user might be confused about the results and not know what they mean.
So you should show in the column "Recommendations" (the column "Reason" that has been renamed) what the user should do next.
Like "Change the password immediately for this site".

Conclusion

My thoughts and the thoughts of @wolframroesler (https://github.com/keepassxreboot/keepassxc/issues/1083#issuecomment-581065795) show that this is a very complex topic. But it really increases the security of the database so all check conditions (site, username, password) should be implemented.

EDIT:
And of cause you should show a warning that some data (like hashed passwords) are sent to the HIBP service and what this means (that there is no way to calculate the password form the hash).

[ImUrX]

Checking against breaches for services without a key seems possible but the api only lets you do it one breach at a time and you may need to take care of it because of rate limiting.
The hashed password one can be done without an API key too, so I think the work should be focused on both of them if it’s possible.

[droidmonkey]

KeePassXC will not register an api key. It is up to the user to register their own and enter it into the settings, then their KeePassXC can use their own key to do breach checks (rate limited).

[OLLI-S]

You should implement all checks that are possible (with or without an API key).
If an API key is required, show a message explaining this to the user (see screenshot above).
But some checks are possible without the API key anyways.

[wolframroesler]

As others have noted, online-checking a password against the HIBP API doesn't require an API key and isn't rate-limited, so we can use it freely. Another free API function is to download the list of all (400+) breaches (=services that suffered significant data leaks in the past). Other API functions (e. g. check if an e-mail address has been compromised in a breach) require an API key and are rate-limited (no more than one query every 1.5 seconds). So, it's actually a lot better than I feared at first.

Thanks @OLLI-S for your analysis, from which I took some of the following ideas.

My plan for the implementation is to go through several stages:

Stage 1: Add new item "HIBP" to the "Reports" panel. After asking the user for permission, it checks the passwords of all entries against the online API and reports all entries with a compromised password (in a way similar to Health Check, including double-click to edit).

The stage 1 feature is available to all users who have Internet access.

Stage 2: Add the name of the downloaded HIBP database file to the KeePassXC settings. Modify the HIBP report so that it uses this database file instead of the online API. If no downloaded HIBP file is configured, the online API is used.

The stage 2 feature is available to all users who have downloaded the HIBP database file.

Stage 3: Modify the HIBP report to include warnings about services that have been breached before the password was last changed. The list of breaches is downloaded via the HIBP API; a default version of the list is shipped as part of the KeePassXC distribution (the current version is 411 KB).

The stage 3 feature is available to all users; Internet access is required to download updated breaches lists.

Stage 4: Modify the HIBP report to include warnings about accounts compromised in breaches and "pastes". Those are queried via the HIBP API which is subject to rate limiting (no more than one query every 1.5 seconds), so we'll probably have to use a different or extended user interface.

The stage 4 features are available to users who purchase their own API key from HIBP.

Internally I'm planning a "stage 0" in which I'll modify the KeePassXC CLI's "analyze" command to use online API calls instead of a downloaded HIBP database file. The goal is to use a shared implementation of online and offline HIBP checking in CLI and GUI.

I prefer to keep the UI as simple as possible. No settings that aren't necessary, no checkboxes if we can avoid them, etc. It's easier to add options later than to remove them.

I suppose the majority of users will not buy an API key and will thus not be able to use the stage 4 features. (Also note that checking if an account has been compromised requires the account name to be exposed to the API, which is something not everybody might wish to do.) I suggest we handle stage 4 in a different issue in which we discuss the details (how to do the UI, how to handle the rate limit, etc.), and in which we also assess if there are enough users to justify the effort of implementing it at all.

I'd like to cover stages 1 and 2 in this issue here, and also 3 maybe (although I'm not sure if stage 3 belongs here because the title says "check passwords" only, and I'd rather have many small issues that are finished quickly than few big ones that take forever). What do the backers think about this?

[ImUrX]

Not a backer but +1 for the part that says "I prefer to keep the UI as
simple as possible. No settings that aren't necessary, no checkboxes if we
can avoid them, etc. It's easier to add options later than to remove them."

On Sun, Feb 2, 2020 at 1:44 PM Wolfram Rösler [e-mail]
wrote:

As others have noted, online-checking a password against the HIBP API
doesn't require an API key and isn't rate-limited, so we can use it freely.
Another free API function is to download the list of all (400+) breaches
(=services that suffered significant data leaks in the past). Other API
functions (e. g. check if an e-mail address has been compromised in a
breach) require an API key and are rate-limited (no more than one query
every 1.5 seconds). So, it's actually a lot better than I feared at first.

Thanks @OLLI-S https://github.com/OLLI-S for your analysis, from which
I took some of the following ideas.

My plan for the implementation is to go through several stages:

Stage 1: Add new item "HIBP" to the "Reports" panel. After asking the
user for permission, it checks the passwords of all entries against the
online API and reports all entries with a compromised password (in a way
similar to Health Check, including double-click to edit).

The stage 1 feature is available to all users who have Internet access.

Stage 2: Add the name of the downloaded HIBP database file to the
KeePassXC settings. Modify the HIBP report so that it uses this database
file instead of the online API. If no downloaded HIBP file is configured,
the online API is used.

The stage 2 feature is available to all users who have downloaded the HIBP
database file.

Stage 3: Modify the HIBP report to include warnings about services that
have been breached before the password was last changed. The list of
breaches is downloaded via the HIBP API; a default version of the list is
shipped as part of the KeePassXC distribution (the current version is 411
KB).

The stage 3 feature is available to all users; Internet access is required
to download updated breaches lists.

Stage 4: Modify the HIBP report to include warnings about accounts
compromised in breaches and "pastes". Those are queried via the HIBP API
which is subject to rate limiting (no more than one query every 1.5
seconds), so we'll probably have to use a different or extended user
interface.

The stage 4 features are available to users who purchase their own API key
from HIBP.

Internally I'm planning a "stage 0" in which I'll modify the KeePassXC
CLI's "analyze" command to use online API calls instead of a downloaded
HIBP database file. The goal is to use a shared implementation of online
and offline HIBP checking in CLI and GUI.

I prefer to keep the UI as simple as possible. No settings that aren't
necessary, no checkboxes if we can avoid them, etc. It's easier to add
options later than to remove them.

I suppose the majority of users will not buy an API key and will thus not
be able to use the stage 4 features. (Also note that checking if an account
has been compromised requires the account name to be exposed to the API,
which is something not everybody might wish to do.) I suggest we handle
stage 4 in a different issue in which we discuss the details (how to do the
UI, how to handle the rate limit, etc.), and in which we also assess if
there are enough users to justify the effort of implementing it at all.

I'd like to cover stages 1 and 2 in this issue here, and also 3 maybe
(although I'm not sure if stage 3 belongs here because the title says
"check passwords" only, and I'd rather have many small issues that are
finished quickly than few big ones that take forever). What do the backers
think about this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/1083?email_source=notifications&email_token=AA4G4PJTMYRBYIXNJGDN57TRA32ABA5CNFSM4D7Q4LY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKR3DOQ#issuecomment-581153210,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4G4PLKKLWJAHEHTVBNTK3RA32ABANCNFSM4D7Q4LYQ
.

[OLLI-S]

@wolframroesler
Wow, what a cool stage planning, I really like it.
I also like the idea to have a separate issue for stage 4, but maybe it is also a good idea to make separate issues for each stage?

[OLLI-S]

If this issue here is very complicated, then you might start with the topic
Suggest TOTP for entries using a web service #4096
Maybe #4096 is easier to implement...

[wolframroesler]

maybe it is also a good idea to make separate issues for each stage?

That sounds reasonable. Anyway, given the considerable bounty, we should agree upon a "definition of done" that specifies what is to be covered in this issue. Stage 1 definitely, stage 4 definitely not (IMHO), how about the other two? (Note that stages 2 and 3 are independent from one another and can be implemented in any order.)

[wolframroesler]

@OLLI-S There's definitely some synergy with #4096. Also it's a much nicer number than 1083. I'll keep it in mind, maybe I can kill two birds with one stone, or prepare something here that can simplify work there (or vice-versa).

[lectrode]

As a backer, I think this request should include stages 1-3 (3 features, $100 per each). However, since stage 3 requires a slightly different data source, it may be justified to put it in its own issue. I guess it depends on the amount of work involved.

If you need to choose between stage 2 and stage 3, stage 3 seems like it'd be more useful for more people. Ideally, if the work needs to be split up, stage 1 and 3 would be completed before stage 2 and 4.

@droidmonkey should probably have the final say as the largest backer...

[OLLI-S]

For me Stage 3 is more important than Stage 2 because:

• Stage 2 is the offline version of Stage 1
  With Stage 1 and Stage 2 we get the same results, so Stage 1 is increasing the security of the KeePassXC database a lot, where Stage 2 is "just" adding offline functionality (not adding more security to the KeePassXC database)

• Stage 3 is adding much more security to the KeePassXC database
  Stage 3 informs me about hacked websites and even if my passwords are all safe (not breached because salted) I should change the passwords immediately after the breach.
  So Stage 3 is a complete new check where Stage 2 is "just" the offline version of Stage 1

I know that Stage 2 is very important for privacy reasons (no hashed passwords are sent to the HIBP datbase), but not for security reasons (I get the same results in Stage 1).

If I had the choice I would start with Stage 3 (including adding the new "HIBP" item to the "Reports" panel) and then go to Stage 1 (check for breached passwords).
But this is just my personal opinion, maybe Stage 1 is more important under security concerns.

Edit:
So in my opinion this issue is done when Stage 1 and Stage 3 are implemented.
Stage 2 and 4 will be implemented later on.

[lectrode]

(no hashed passwords are sent to the HIBP datbase)

@OLLI-S Just for clarity for anyone reading this: at no point is the full password hash sent to HIBP, just the first part of the hash. You get back many more results that don't necessarily apply to you in order to further obscure which hash is yours. The full hash is then locally compared to that set of results to see if it matches any.

[droidmonkey]

Technically the back end for stage 2 is already in the code base. This would be a GUI only addition. Stage 3 and 4 are out of scope from this specific issue and carry additional requirements for both the developer and user. I would consider definition of done for this issue to be stage 1 & 2. A new issue should be created to support breaches and pastes api.

[OLLI-S]

If you look at the title of this issue, it says:
Check passwords against hacked password databases
So unfortunately @droidmonkey is right if he says that this issue covers only Stage 1 and Stage 2.
:sob:

And thank you @lectrode for the clarification that only parts of the hash is uploaded.

[wolframroesler]

Received the HIBP icon from the simpleicons guys (https://github.com/simple-icons/simple-icons/pull/2517): https://github.com/simple-icons/simple-icons/blob/develop/icons/haveibeenpwned.svg

[wolframroesler]

I would consider definition of done for this issue to be stage 1 & 2.

OK from my side. Stage 1 is online checking of passwords against the HIBP server, and stage 2 is the same against a previously downloaded HIBP password file, so this issue deals with what's in the original description only (checking for hacked passwords). Any objections, @lectrode?

@OLLI-S IIRC it was you who brought up stages 3 (check password modification date against online breaches list) and 4 (check user names against breaches and pastes), would you mind creating new issues for these?

[OLLI-S]

@wolframroesler Damn, you caught me! :stuck_out_tongue_winking_eye:
I will create the entries these days.

[lectrode]

@wolframroesler Fine by me. Thank you for your work on this

[OLLI-S]

@wolframroesler As you requested I created the following two issues:

• HIBP - Check Password Modification Date against Online Breaches List #4298
• HIBP - Check User Names against Breaches and Pastes #4299

I just hope that the first feature request (check by modification date) gets implemented, because this is my favorite feature in the HaveIBeenPwned Plugin.

Edit:
And thank you @wolframroesler for suggesting descriptive titles for the two issues.

[wolframroesler]

Here's a first screenshot. Just the UI, not actually accessing the HIBP online service yet (but some online access takes place just to see if everything works).

[rugk]

"Hover for details" is not really possible on touch devices and also not that intuitive, given that you have to provide a help text for that. :thinking:

[lectrode]

Looks nice. What kind of details would be provided on hover?

[wolframroesler]

@rugk, @lectrode That's just a message I copied and haven't cleaned up yet. I don't think the finished HIBP report will have any tooltips.

[OLLI-S]

@wolframroesler Wow, this looks really awesome!
Really love this dialogue.

What about adding the following columns:

• Breach Date
• Password Changed (this is also a date)

So users see at once when the website was hacked and when they changed the password.

Will you show only negative results (when the breach happened after I changed my password and where you recommend to change the password ASAP)?
Or do you plan to show also positive results (where I changed my password after the breach and where you write something like "No action required")?

These both features (showing the two columns and showing both results) make the complete process transparent.
So maybe you add a checkbox "Also show resolved breaches" (or any better wording) that is not checked by default).
In KeePass I also have this checkbox available in HIBP plugin.

[lectrode]

@OLLI-S
AFAIK, the API for checking passwords does not provide any information about breaches, with the exception of how many breaches they've been involved in (see the documentation). There's no way to include breach date for passwords without checking the sites for breaches (which will likely be addressed with your request)

The date of the last password change isn't very useful for checking if a password was breached: if the password was, it needs to be changed regardless of the last time it was changed. The next time the password is checked, the new password would have different breach results.

@wolframroesler "Leaks" might be a useful column. The more leaks a password is involved in, the more crucial it is to change it. Or, if not a separate column, maybe have it in the 3rd column: "X Leaks! Change password ASAP!".

(IMHO "leaks" might be a better descriptor than "hacked" - less ambiguous. "Leaks" directly says it was made public, whereas "hacked" could mean a number of different things)

[wolframroesler]

Thanks everyone for the feedback :)

@OLLI-S Just like in Health Check I'm going to display findings (entries with a leaked password) only. Showing entries that don't require attention would just clutter the report. Breaches, password change dates etc. will be handled in the other issues.

By the way, what I'm showing are positive results. As in medicine, when the outcome of a test is positive, it's usually bad for you. :)

@lectrode I'll check which term (hacked, leaked, etc.) HIBP uses and stick to the same terminology. Showing the number of leaks in the "Reason" column is really a lot better than the generic message I'm displaying now (which isn't useful because it's the same for every row in the table).

[OLLI-S]

@lectrode Sorry, it was my fault.
I received an email telling me that @wolframroesler replied to one of my topics. So I clicked in the email the link to open the issue in GH.

Here the posting of @wolframroesler was focussed and the first thing I saw was the cool screen shoot.
I thought that the screen shot shows the feature HIBP - Check Password Modification Date against Online Breaches List #4298 (a feature I am very excited to see).
So I started to write my comment (of cause without reading the topic title).
My fault!

The date of the last password change isn't very useful for checking if a password was breached: if the password was, it needs to be changed regardless of the last time it was changed. The next time the password is checked, the new password would have different breach results.

I totally agree with you, if the password was breached, then it must be changed no matter when I changed it the last time.

Just like in Health Check I'm going to display findings (entries with a leaked password) only. Showing entries that don't require attention would just clutter the report. Breaches, password change dates etc. will be handled in the other issues.

I also agree that showing all results will clutter the report.

[wolframroesler]

Someone wrote a highly optimized library for offline HIBP search (search in the previously downloaded HIBP file): http://stryku.pl/poetry/okon.php The repo is here: https://github.com/stryku/okon

I'm thinking about integrating it into KeePassXC to replace the existing offline search routine, which seems to be essentially un-optimized.

@droidmonkey: Is there a procedure for integrating a library like this one into KeePassXC? And, it requires C++17, how about that?

[droidmonkey]

Please do not integrate that. It is totally unnecessary, the current implementation is more than sufficient. The offline file process is obscene from the start. It looks like okon merely preprocesses the giant file and splits it among the hashes building a search tree.

[wolframroesler]

First milestone achieved! Online check against the HIBP service is implemented. The following screenshot is from an actual check of the demo database, reporting exactly those passwords I deliberately set for this very purpose.

Now, two questions. The text in red is created from the "count of how many times the password appears in the data set" as reported by HIBP. That count can be anything between 1 and many millions, and I generate the text like this:

count==1 ? tr("Password was hacked once") :
count < 100 ? tr("Password was hacked several times") :
count < 100000 ? tr("Password was hacked many times") :
    tr("Password was hacked very many times")

I'm not sure if those texts, or the numbers they are based on, are adequate to make the user understand what they mean. For example, password "1234" comes with a count of 12 millions, which means that 12 million accounts with that password are part of breaches recorded by HIBP (no, not exactly, because some of these accounts may be in more than one breach). But how do we put that into a few words? I could of course simply display the number, but I don't like that because it'd circumvent the question by shifting the burden of interpretation to the user. Any ideas how to improve the message are welcome (especially from native English speakers).

Second question. The HIBP service supports a "padding" mode that is supposed to enhance privacy but comes at the cost of transmitting additional data to the client (details: https://haveibeenpwned.com/API/v3#PwnedPasswordsPadding). I could activate padding mode easily, however I'm not currently planning to because I think the gain in privacy isn't big enough to justify the cost in speed. Opinions?

[OLLI-S]

Wording

When I saw the "many times" in the screen shot I asked myself "wat does many times mean?"

• More than 5?
• More than 10?
• More than 100?
• More than 1000?
  So you should give the user more specific values/explanations.

I also would replace "many times" with "often" (I am German and English is not my mother tongue but "very often" sounds better for me than "very many times").
And I also would add "Thousands Separator" to make it more readable.

First I thought about a range (between x and y):

count==1 ? tr("Password was hacked once") :
count < 100 ? tr("Password was hacked several times (2 - 99 times)") :
count < 100000 ? tr("Password was hacked often (100 - 99.999 times)") :
    tr("Password was hacked very often (more than 100,000 times)")

But this is cluttering the messages and also making them "technical".
Not easy to read.

So what about the following:

count==1 ? tr("Password was hacked once") :
count < 100 ? tr("Password was hacked several times (less than 100 times)") :
count < 100000 ? tr("Password was hacked often (more than 100 times)") :
    tr("Password was hacked very often (more than 100,000 times)")

But I am also not really happy with that.
My first intention was to show "more than xxx times" so users see the urgency.

But when it was hacked 2-99 times then it would be "more than once" and this does not show the urgency. Also the text "less than 100 times" does not really be a good solution...

I am posting my thoughts here so maybe they inspire others and help finding a solution.

Padding

At the linked documentation they write

Padding ... ensures that all responses contain between 800 and 1,000 results regardless of the number of hash suffixes returned by the service.

So if I understood this correctly then the service returns between 800 and 1,000 results also when you only check 5 passwords.
This should increase the security:

anyone able to intercept encrypted responses to the API cannot reasonably determine which hash prefix was searched for

@wolframroesler Do you have any numbers how much speed / data this will cost?
If the service normally runs 5 seconds and with this feature it runs 60 seconds, this is a lot more time. But if it runs 15 seconds instead of 5 seconds, this is acceptable.

[droidmonkey]

Technically the message should simply be: Password may have been exposed in a hack

On the tooltip hover you can list the specifics: This password was found XX times in the HIBP database

[lectrode]

"Password may have been exposed in a hack"
This should be a definitive statement, since the password definitely was exposed, not just a "may have been".

Of course, if you just fill that column with a generic statement for every entry, it's kinda useless. Every entry in that list has been exposed at least once.

I think something along these lines would be more useful:

[droidmonkey]

@lectrode this is a good point, especially the same statement on every line. I like your mock up.

I say "may be" because it is not definitive that the person's password was hacked for that particular entry's website. We just know that a password with that same SHA1 was hacked at some point.

[phoerious]

Why is the highlighted HIBP icon not white?

[OLLI-S]

I would name the column "Result" and write in the cells:
"Password exposed" and then the counters you see it at the mock up of @lectrode.

Example:

Title | Path | Result
------------ | ------------- | -------------
IFTTT | Root/Internet | Password exposed 1 time
Stack Oveflow | Root/Internet/Coding | Password exposed 100 times
Mastodon | Root/Internet/Social | Password exposed 100,000 times

Reason: average user does not know what "Password found in HIBP".
So my idea is to keep it simple and descriptive.

[wolframroesler]

@phoerious dunno. The sidebar icons are never white for me when highlighted. Here's another screenshot:

[wolframroesler]

Thanks for your feedback on that third table column. Here's what it looks like now:

I like the powers of 10 as a compromise between unnecessarily precise and meaninglessly abstract.

Is "exposed" a good term to use here? "Hacked" sounds too much like "this account has been hacked", which is not necessarily the case; "found in HIBP" is precise but unintelligible to the average user, "pwned" is 1337 jargon. "Exposed" sounds OK to me.

[wolframroesler]

About HIBP padding mode.

So if I understood this correctly then the service returns between 800 and 1,000 results also when you only check 5 passwords.

Not exactly, it affects every single checked password.

The idea behind padding mode is that a malicious party may see that you are querying HIBP but not see the exact URL (which contains the first five hex characters of the password's SHA1 hash), and might see the size of HIBP's reply but not the contents (due to encryption). They could then query HIBP themselves to find out which five-hex-characters prefix results in a reply of that size, and thus figure out the first five characters of your password's SHA1. To prevent that, HIBP supports "padding mode" in which HIBP adds random padding data to its result.

I don't think that padding mode would significantly increase privacy in our use case. It would, however, increase the number of bytes that have to be read from the HIBP server for every single password we check. Multiply that by the number of passwords in the database, by the number of KeePassXC users, and by the number of times each of them uses the HIBP report, and you've got significant overall cost for no real benefit. That's why I'm not using padding mode at the moment.

OTOH, security and privacy is what KeePassXC is all about, and these always come with a price tag. If anyone thinks that we should use padding mode just because we should use whatever privacy-enhancing features a service provides, I'll put it in.

[rugk]

If anyone thinks that we should use padding mode just because we should use whatever privacy-enhancing features a service provides, I'll put it in.

Maybe optional, i.e. opt-in?

[droidmonkey]

Given that HIBP uses https there is literally zero gain to add padding. If you are a victim of MITM attack scenario then the first five characters of your password's SHA1 is the least of your concerns.

[OLLI-S]

Given that HIBP uses https there is literally zero gain to add padding. If you are a victim of MITM attack scenario then the first five characters of your password's SHA1 is the least of your concerns.

I agree, then you really have other problems...
So from my side you might skip padding or make it an optional feature (checkbox) that users can activate.

Back to the column header:
I still recommend using unique column headers. In the Health Check the column is called "Reason" because it explains the reason for the score. This label is short (one word) and not part of the data (in the cells below).

Your title contains more than one word and is a part of the data below (means you have to read the header in combination with the headline to get the result). So I would recommend to write the text "Password has been exposed" (or the short form "Password exposed") in the data cells and rename the column header to "Result".

[wolframroesler]

Thanks for the input again. Great community here :)

Now sorting the HIBP table in descending order by how many times a password has been exposed. Also shortened the title a bit (don't want to use more horizontal space than necessary, in both the table header and cells).

Won't use HIBP padding mode, it's not worth the cost (not even to add a checkbox to offer it as an option -- very few users would understand what the checkbox is about, and KeePassXC settings have more than enough checkboxes already.)

So, I'd call online HIBP checks done. Will submit a PR so you can check it out yourselves, and then continue with offline checks.

Stay healthy everyone.

[wolframroesler]

@droidmonkey How's the current planning for release 2.6.0? Would you like HIBP online checks in 2.6.0 already? Asking because from my point of view the PR could be merged, yet it's marked as WIP because offline checks aren't implemented yet. If you wish I'll un-WIP the PR so that online checks can go into 2.6.0, leaving offline checks for the 2.7.0.

[droidmonkey]

This will make 2.6.0. We are coming close to feature lock, perhaps in 2 weeks. Leave offline checks for another version.

[wolframroesler]

Awesome. PR un-WIPed. Looking forward to your review. Will submit a second PR for offline checks when they are done (probably not within the next two weeks).

[rugk]

Your BIOS password has been exposed "millions of times"… :rofl:

[wolframroesler]

@rugk we really need the option to mark entries as "I know this is a bad password, you don't have to tell me anymore" (#4168), which would exclude them from Health Check as well as from HIBP. My ATM PIN has also been exposed millions of times (just like any other sequence of four digits) but there's nothing I can do about it, so there's no point in reporting it over and over again.

[OLLI-S]

I know that this topic is closed, but there are no column headers in the HIBP report:

Users don't know what the columns mean...

Edit
And I recognized that expired entries are also reported in the HIBP report...

[droidmonkey]

Oops that might be my fault

[OLLI-S]

I really appreciate your work, @droidmonkey and @wolframroesler .
You all at KeePassXC are really doing a fantastic job...

[wolframroesler]

@OLLI-S

And I recognized that expired entries are also reported in the HIBP report...

Of course, why should they not be?

[OLLI-S]

I have 116 expired entries in my database. All of them are for services, that I no longer use and some of them are services that are no longer available.
But I don't want to delete them, it might be the case that information stored there (the old problem: if you don't delete them, then you never need the data, but after you deleted them you need some information that is no longer present).

So I moved them all to a folder called "Abgelaufen" (what means "Expired") where I also set "Search" and "Auto-Type" to "Disabled" (so they are not found and not used for Auto-Type.
I did not want to move them to a new database (want to have everything in one file).

So these entries are old, mainly never used but it is disturbing if they inflate the health check.
So here I see the following possible solutions:

1. You implement a feature in the properties of a folder called "Health Check" where I can select that this folder should not be checked in the health check.
2. You implement an option "Exclude expired entries from health check (either in the settings of KeePassXC or in the Health-Check window)
3. You tell the maniac user that is writing these lines to move the expired entries into a new database. 😋

I really hope you implement 1. or 2. because I think there are other people that have expired entries and want to exclude them from the health check and HIBP checl.

[droidmonkey]

I like option 2, could also be a database setting that is stored in the custom data.

[droidmonkey]

See #4531 for fixes.

[OLLI-S]

When I wrote the last comment, then the 4th option did not came into my mind:

1. After you implemented Health Check - Exclude entries from check (#4168) I just need to select the entries and exclude them from check.
   This requires that I can select multiple entries in the password list, right click and then exclude them all. So I will create a new issue for this idea....

I think this is the best and simple solution.

[OLLI-S]

I created the new issue Health Check - Exclude MULTIPLE entries from check (#4533)

[droidmonkey]

Locking this conversation as it is very long and multiple other issues have spawned from it.