ghost commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Quoting haveibeenpwned.com/Passwords page itself:

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

ghost commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

TheZ3ro commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

"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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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?

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 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.
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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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: grafik

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 commented 6 years ago

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

zatricky commented 6 years ago

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 commented 6 years ago

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

droidmonkey commented 6 years ago

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

mihaiile commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 istantanea_2018-06-28_16-32-29

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!) istantanea_2018-06-28_16-32-47 istantanea_2018-06-28_16-33-09

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

kwah-gh commented 6 years ago

@zatricky: Thanks for the link.

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

Nerdy314159265 commented 6 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

rugk commented 5 years ago

@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 commented 5 years ago

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

admirabilis commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

Your script should really use the keepassxc-cli

telepath commented 5 years ago

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 commented 4 years ago

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.

keepassxreboot / keepassxc

Check passwords against hacked password databases [$300] #1083

Expected Behavior

Current Behavior

Possible Solution (bash)

Context

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.

Find pwned entries

Find entries with the same password

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