Keepass Pc

[Flocka Bilodeau]

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

Personally, I'd probably end up using my OwnCloud (which is self hosted), but I have the advantage of having my own personal web server and I realize that's not an option everyone can take advantage of. (The only reason I haven't is that I don't have a particular need to coordinate a key database in that manner.) A public cloud based solution should work as a fine second option though.

You can increase the resiliency of your KeePass database to brute force by increasing the number of PBKDF2 iterations when deriving the database encryption key from your password. You can do this in KeePass under File > Database settings > Security. Personally, I use around 5,000,000 rounds (1 s delay). Remember that mobile devices are slower.

I use the KeePass-Dropbox combination. The password database is encrypted using a key derived from a strong master password. Even if somebody acquires your encrypted password database through your cloud account, a strong enough master password renders brute-force attacks infeasible.

The cloud is inherently untrustworthy, and files kept on it should be considered vulnerable, so you need strong encryption to protect you. KeePass offers that. However, you then need to be able to trust every client you enter your password into. If you read them on an iPhone, do you trust the platform? Do you shield your password from the cameras on the subway when you enter it, every time? How about your laptop?

You also need to consider the value of what you're protecting. Is this safeguarding your retirement funds? Your fantasy bowling league scores? Political dissention that is illegal in your country? For some cases it's simply not worth the risk of making a mistake.

Even if your KP database were to be compromised from Dropbox, using both a strong password, and additionally a keyfile not stored in Dropbox should give you security beyond any known means of electronic attack (as long as your devices aren't already compromised).

While a strong enough cipher should be able to resist brute force attack, consider that by storing your password database in the cloud you give the potential attacker much more information than he could get from e.g. a lost phone with the same database.

Every time you modify a password, the attacker gets a new database, which he can use together with older versions in differential analysis attacks. You will need a stronger cipher to resist that, compared to simple COA. If he also happens to have one of your passwords (e.g. by cracking a poorly protected password database from one of the sites you visit), he may be able to identify that password in your database. This would open doors for KPA which may be close to trivial in case you reuse passwords.

As everyone mentioned, having a strong master password for you database file is very important to thwart brute force attacks. But if you combine that with a key file, then it becomes practically impossible to brute force.

If Cloud Storage 1 is compromised, then the database file itself without the key file will be impossible to brute force, unless there's a serious security vulnerability in Keepass's encryption implementation.

I would say that it would be highly unlikely for both Cloud Storages to be compromised at the same time by the same attacker. You'd have to be a high profile individual for that (e.g. Politician, Billionaire, Secret Agent etc.) :)

If you're not one of the above and are willing to sacrifice a bit of security in exchange for ease of access (e.g. you keep forgetting where you put the damn USB disk), then store both Database File and Key file on the local computer. However, in this case the local computer becomes the weak spot, if compromised, the attacker would have access to the key file, so would just need to brute force the master password on the database, so best to set a strong one. This would be the same as not using a key file at all.

If you want to be really serious about things, run Boxcryptor in conjunction with Dropbox. Boxcryptor encrypts everything at your end PRIOR to sending to Dropboxs' servers. All that's at Dropboxs end is a load of encrypted stuff. Your keepass db ends up doubly encrypted!

I personally use a very strong password of 35 characters mixed with symbols and keep my DB file on google drive. If You do not keep millions of crypto or something else that you can not get back you should be fine. So even if somebody will steal Your Db and even if somebody will be able to encrypt it ( I highly doubt it) there are other ways how to protect Your accounts and other important stuff. I personally use Two Factor auth in every Money related and every important account, so its double safe from two sides. I think I'm safe. + while reading this thread I also increased my iterations as @Matrix suggested, so added another layer of security. :) There is another layer that I would add if I would feel threatened in some way and this is services like What additionally encrypt files in your cloud.

Especially (but not only) if you store the database in the cloud, you have to assume that an adversary got a hold of the database at some earlier point in time, with an old password. That may give her the information she is after.

One other option: only use the cloud to transfer your database to your next device and then delete it from cloud storage. This would expose your database for a limited amount of time. Not exactly what you were asking but an option that can be considered depending on your required security level.

I say go with the "encrypted at client" cloud solution of your choice, encrypt with the most PBKDF2 iterations you are comfortable with, largest keyfile you can live with, and most importantly, store the information you keep close to you (locally) on a SELF ENCRYPTING drive. Put an encrypted filesystem on top if you must, but encryption of data that is prone to loss or theft, like a USB drive, needs to be automatic.

If an attacker modifies the xml config file (adding an export trigger on 'Opened database file') he will be able to export all the passwords, without us knowing it. Shouldn't the user be asked to confirm before exporting ?

I a word, yes.

You can turn off "Do not require entering current master key before exporting" under Tools > Options > Policy.

However, an attacker with enough access to add a trigger and then collect the export can turn this off.

Basically, if an attacker has full access to your machine, it's no longer your machine.

Use full disk encryption, make sure your anti virus is up to date and run a regular malware scan with something like MalwareBytes AM.

Thank you Dominik,

But I'm not talking about a virus : a notepad is enough with access to the configuration file (for example by gaining remote access to the file).

As a keepass user I was not fooled since silent export is a standard feature of keepass.

If a password manager is as secure as a plain text configuration file, why should I use it instead of a spreadsheet to store my passwords on my computer ?

Forcing the use of 'require entering current master key before exporting' could be great

Best regards

If your computer is available to others you do not trust perhaps using the portable version on a memory stick that is kept in your pocket is a better choice than installing the app on a that computer?

+1 for password confirming this activity. I've always used a portable version in a [veracrypt] encrypted file mounted only when I'm logged in, to protect against the possibility of the main executable being tampered with when others are using the PC.

Hello wellread1 ,

When I said 'force' I meant 'not be able to disable'.

As Paul also said : 'However, an attacker with enough access to add a trigger and then collect the export can turn this off.'

And the policy to disable export also seems to be stored in the configuration file.

To enforce policies and other settings, use an enforced configuration file (KeePass.config.enforced.xml file) and write protect the KeePass application directory (typical for a version of KeePass installed in a Windows Program Files directory). See _enf.html and

3a8082e126