Closed RustyD closed 4 years ago
We already discussed this in #1083 and after that we made a blog post about it https://keepassxc.org/blog/2018-02-24-pwned-database/
The better password hygiene should be: "generate random password and store them in a password manager", not "come up with a password that wasn't already compromised"
Anyway, checking if an account has been compromised (not pwned password but haveibeenpwned) is tracked by #551
This database is pretty useless if you are using a password manager. If you are using a good password, the only realistic chance of your password being in there is if a) your account was hacked AND b) the service saved your password as clear text.
Checking your username against the haveibeenpwned username database is way more useful. If your password is in the Pwned dump, it's almost certain that your username will be in the database, too. On the other hand, if your account was hacked and the service properly hashed your password, you won't notice if you only check if your password is in the database.
I would not say that it's pretty useless - you are assuming two things:
In addition, having that functionality easily available is useful for other reasons beyond your own personal password security. You could use the feature to demonstrate to family/friends that their passwords are NOT secure. A bit like having a stand-alone random password generate is sometimes useful for reasons beyond generating a password for a website.
Anyway, I obviously hadn't realised that you'd already considered using this service (my search wasn't very thorough!), so I'll not say any more apart from to re-iterate that there are more use cases / user stories than the most obvious (and probably redundant) one.
If a novice user is using an insecure password, because they don't know better, it's highly unlikely that they will check it against a database. Anyway, as I said: checking your password against a database is just plain useless. Even if you are using a bad password, you will ONLY find it in the database if the hacked service did not hash and salt your password. Check your username instead. You will always find it, no matter if the hacked service did their homework on password security or not.
They won't check it against a database - KeePassXC would do it automatically - that is the point. But anyway - I accept what you are saying and realise that it's more 'icing on the cake' than anything really core to password security.
Checking passwords against a database is just the wrong approach. Check the username. That's far more reliable and far more likely to succeed and in case of an online database even more secure, because you are not sending private data or comparable hashes of private data.
Example scenario:
I have a password set on an old service that hasn't been updated in years. I change to start using 1Password and import my passwords from my browser. 1Password notices, without my prompting to do so, that I've used "hunter2" on that service, which is a bad/well-known password. 1Password reminds me that I should action some good password hygiene.
vs
I change to start using KeepassXC ... and none of that happens.
It's a valid approach that should not so callously be dismissed.
@zatricky see #551
This should probably be reconsidered, considering https://www.troyhunt.com/the-773-million-record-collection-1-data-reach/ (which is a case where mere e-mail/username checks are not sufficient to determine which account was compromised).
This should probably be reconsidered, considering https://www.troyhunt.com/the-773-million-record-collection-1-data-reach/ (which is a case where mere e-mail/username checks are not sufficient to determine which account was compromised).
I agree. Also, it's useful to rule out the possibility that the most recent password was breached. I got two different notifications from HIBP for that breach, so checking the username would have notified me. But I would not have any way to know if the password that was breached was the old, before-I-was-doing-proper-password-hygiene or not, or even from which site.
So, :+1: by me for the integration with Pwned Passwords.
I agree too.
I've just received emails for 2 different addresses for this Collection #1 breach. I've got over 200 accounts using those 2 addresses. Checking my addresses as suggested by @phoerious won't tell me anything I don't already know.
If it's a publicised company breach, i.e. Adobe, MySpace, LinkedIn etc, no problem, I'll change it manually. But when it's 773m accounts across goodness knows what services, what I need to know is which services have been compromised so I can secure them again with a different password (and possibly a different email address).
I'm now about to hack together a script that will feed my KeepassXC data (exported as a csv file) into Troy's engine as there is no way I'm doing this manually.
But I would really like my password manager to be doing this for me ... ;)
If you are using a script why not use keepassxc-cli and post as a gist for everyone?
I've found a plugin for Keepass. Any chance that it would work with XC too?
No, KeePass2 is written in C#, KeePassXC is in C++. Although you could just open your database using KeePass2 with that plugin and run the check.
Although you could just open your database using KeePass2 with that plugin and run the check.
That's a good idea for people that are looking for a one-off check, thanks.
I wrote a shell script to check all of your KeePassXC entries against the Pwned Passwords API.
https://gist.github.com/Birch-san/a027bf3ba6327371dffca8a491ddec5d
Caveat: the interface is "export your KeePassXC database as a CSV".
You could use the XML dump feature.
I feel like this has been addressed by https://github.com/keepassxreboot/keepassxc/pull/2707
I believe this one is the "online" version. Which, if I'm a betting man, will become a paid api now that Troy is looking to sell the asset.
Troy isn't exactly desperate for money. Likely one of the conditions of sale would be that it continues to be a freely-available tool.
@zatricky didn't see he was. He was looking to sell the service to a for-profit organization. That organization would likely charge for the API.
Implemented HIBP API calls in 2.6.0
The Pwned Passwords (https://haveibeenpwned.com/Passwords) website recently upgraded to version 2 (https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/) and 1Password provided integration with that service almost immediately. KeePassXC could provide similar levels of feedback to users on the 'quality' of their passwords.
When the user chooses to provide their own password (or uses an existing one), KeePassXC can check against the Pwned Passwords database (online/offline?) to see if the user provided password has been used in a previous data breach, and then provide a warning if it has. The 'k-Anonymity' feature would seem to be the one to use.
This lack of a 'fix' to this issue does not directly affect me (or anyone else) negatively, but it could encourage users to better password hygiene. It might soon become a 'benchmark feature' that all good password managers include.