Keepass Hacked

[Adriana Gowen]

Ihave been using keepass2 for 3 months and everything was find until today, when my google, amazon, and twitter account were hacked simultaneously. No doubt my KeePass file has been compromised as the three passwords were strong and different. Also my keepass pasword was strong and store on paper were nobody could find it.

I also used keepass tusk (chrome extension) and keepass2Android app on my phone. My KeePass file is stored in dropbox. My dropbox account has not been compromised as there are no strange sessions on it.

I dont have deep knowledge of cybersecurity but I suspect that either the chrome extension or the android app may have vulnerabilities that have led to the hack of my keepass database. (For example the chrome extension asked you for your master kee and after that it will keep the database unlocked until the browser is closed)

If you didn't use a "Master password" protection then you invited trouble and keepass wasn't the responsible party for this problem. Dropbox not compromised how did you even verify that since it stored your database? If you didn't Master Password protect it then it's too late now and you will have to go through all your login and change the passwords.

Also if your using the Admin/Owner account without password protection you already permitted any keylogger/malware to get your data. Any scans at this point is not going to work if malware/virus has gotten past any security software. In this situation would require a computer shop to find and remove the problem. I know how people tout 2FA but I've had bad experiences with 2FA locking out of account and no one could help. So unless you know your 2FA in-details and keys - I say don't use this only as last last resort.

Next thing: Did you use the Gmail for registering your Twitter and Amazon accounts? Because, if the attacker gains access to your e-mail, passwords for other services can be reset using it. Maybe there was a suspicious application linked to your Google account, and from there hacker proceeded with password reset? Especially I'd take a look what is installed on mobile phone.

If you entered your mobile phone number on Google account creation, you should be able to start password recovery by sending reset request via SMS. Then proceed with recovery.

On each service, review the security settings:

- reset the password

- remotely log out all sessions after password change

- review the list of linked applications - Google, Dropbox or Facebook offer the API and third party apps may be using it without the need to know your password. Unlink whatever you don't know.

- review e-mail settings. For example, an attacker may set mail forwarding to his inbox. In this case, even if you change the password and log him out, he will still receive copies of your e-mails, including password reset mails

- enable 2FA wherever possible

You mentioned that you use KeePass Tusk. I have never heard of that and it is NOT Keepass. It would appear to be a third party addon for Chrome that is compatible with KeePass and this could be the route by which your passwords have been compromised rather than the KeePass program.

I do not recall ever seeing any confirmed reports of passwords contained within KeePass leaking and I don't recall ever seeing any mention previously about Tusk perhaps this should be the first suspect.

Today many websites get hacked and passwords get stolen.

1Password and LastPass offer a breach check.

They check for each entry in the database if the website of the entry was had a breach.

If yes, they check if the modification date of the password (not the modification date of the entry) is newer than the breach date of the website.

If the user did not change the password since the breach happened, the password managers alert the user.

I would not trust a date, from HIBP or any other date. Anyone can lie about date, companies to avoid embarassment, hackers can lie to trick users. Bulk-breaches have a lot of various sources, so it would be impossible to reliably alert users.

Troy (author of HIBP) has a new API for checking if a specific password has been compromised. There is a way to hash a portion of the pass and send it to the service without giving up the password that you are testing. Not completely clear on the details, but this blog post by Troy lays it all out. Something to look into.

Last August, I launched a little feature within Have I Been Pwned (HIBP) I called Pwned Passwords. This was a list of 320 million passwords from a range of different data breaches which organisations could use to better protect their own systems....

Recently, Mozilla also started its new free service Firefox Monitor allowing users to check if their email or other details are being breached by third parties. this service seems really helpful and also offers to generate notifications to selected users who enroll with the service by signing it up. for more details, check the news here.

Firefox Monitor Data Breach Service Launched

image.png740279 32.5 KB

But how is this information helpful for users?

I have to open every entry (8 entries) manually in Bitwarden and check if I have changed the password after the breach date.

And if I run this report again, I still get the 8 results.

Chrome password manager has a feature that alerts you every time you login using a potentially compromised password/account. While Bitwarden has a feature like this its buried in the menu and not as effective. Some sort of notification would be better at alerting people that there password might be compromised from a known breach & they should change their password.

In my first posting I suggested that Bitwarden checks for breached services too.

So when for example StarTribune has a data breach, then I get informed by the KeePass plugin because I have the URL in my entries.

This plugin warns me no matter what email address I am using.

Meantime much happened in Bitwarden and many new features were implemented.

I am not a security expert, but IMHO I think that this report (Check by Breached Accounts) would be still very useful.

Or am I completely wrong?

If someonelse could get your password db file (e.g. .kdbx file for keepass), maybe due to a hacking attack, how threaten is your security in fact? Of course this is a problem and you should change all your passwords, but how "dangerous" is this really? Is there any value without having the master password?

If you've picked a strong master password, they've effectively got an encrypted blob of data which they can try brute force your password from, but may never succeed (Assuming that the password DB format is free from errors).

However, unlike with a website password or other online service (Chat/ssh/etc), there are no limits on how many times they can try different passwords, or on what speed the password comparison runs at - they can send copies of the file to thousands of machines and try to brute force starting from different places to minimise the time to find the password. With a website, the web server is the limiting factor - even with thousands of source machines, it will only do comparisons at a rate it can support, or it'll fall over.

For a really good password, this doesn't matter - the number of potential passwords is far too high to try them all in a useful time (assuming for the purpose of argument that whatever data you have is probably not very useful to anyone in a few thousand/million years). Picking and remembering a really good password is harder though, so it's possible that it is actually a quote from a book or common phrase, which might be tried sooner than pure brute force would suggest.

As Andr says, if the hack occurred on a device where the database is used, as opposed to one where it is just stored (main PC vs. backup server), there is a chance of a keylogger being used to find the master password. As a result, it would be recommended not to open any password databases on machines which are suspect until they have been completely rebuilt from a clean state. Most password managers try to prevent passwords being read from memory, although this is not 100% perfect, but again, this can be avoided by not opening the database on suspect devices (or ones which you don't have control over).

It certainly would be more convenient to store my KeePass database on either S3, Dropbox, or better yet SpiderOak. My fear is having my cloud storage account compromised then having the credentials recovered by either brute force or some other attack vector. How safe is this? What risks do I need to know about?

It is hard to quantify exactly, but if you have the DB on a mobile device then I wouldn't say this is particularly any less secure. KeePass encrypts the DB because the file remaining secure isn't expected to be a guarantee. It's certainly preferable that the DB file not get in the wild, but if your security depends on the encrypted file remaining confidential, then you have bigger problems than whether to use cloud storage or not.

A sufficiently strong master password should prevent brute forcing at least long enough for a breach to be detected and for you to change the passwords within it. In this way, it may even be slightly preferable to having a local copy on a mobile device as someone may compromise the file if you take your eyes off your device even momentarily and it would be much harder to identify that breach occurred.

If you want to secure it even further, you can add another layer of security by encrypting the file you store in cloud storage online. The master password provides pretty good security as long as you choose a difficult to brute force password (long and truly random), but it still can't compete with an actual long encryption key. If you encrypt the file that you store online and then keep that key with you protected by a similar master password, now the online component alone is much, much harder to decrypt (likely impossible if done correctly) and if your key file gets compromised, you simply re-encrypt your online DB immediately with a new key. You're still in trouble if someone can compromise your cloud account first and get the file, but it requires two points of compromise instead of one.

3a8082e126