[asquabventured]

A solution I have found that (I think) is relatively secure. Setup a keepass database that requires the use of an unlock password and key file. Sync the database to Google Drive but never sync the key file! Only store the keyfile on a locally ecrypted thumb drive or only stored locally on the devices (preferably encrypted) that you need to access keepass from.

In random time/day intervals reset your key file and keepass password.

The key to this method "working" which should be "secure" barring total ownage by a state actor or well funded individual is to never sync the key file and database to the same service. Additionally, sync up a "false flag" key file if you want some additional level of obscurity.

tl;dr:

1) Setup Keepass database to require password and key file to unlock.

2) Sync database to cloud service but never the key file.

3) In random time intervals (t=60+days) Randomly change both the password and generate a new key file for your database.

4) Keep your key file on an encrypted drive or on the device (preferably encrypted) that needs access to Keepass.

[andrewaylett]

I'm concerned (but not qualified to judge) that changing your password and keyfile may not be as beneficial as it appears.

A password for an encryption key is very different to a password for a server. Once you change your password on a server, there's little harm in publishing it -- it can't be used any more. But the key is a file that may still exist (see also Wikileaks' key being published by David Leigh).

Consider: your database exists as a file. If someone is able to gain access to a copy, that copy remains valid as long as at least one password within it remains unchanged. So you need a strong key, because it's subject to offline bruteforcing. Now they get a second copy of your database, with a different password. If any of your passwords are ever published or cracked, your database is exposed. If you have to change your password regularly, it's going to be tempting to make it weaker, or to store it somewhere less securely. If you're using key files, they only need to get one of your files. It seems to me that the more key material you need to secure, the more difficult it's going to be?

Anyone who knows better want to chime in?

[asquabventured]

The key it seems to me is by using both a master password and a key file. If a site gets cracked and they find your site specific password that won't help them determine your keepass database master password &/or generated key file that you only store offline and never sync to the cloud.

In order to open the database you need both the correct master password and the correct keyfile. If the attacker doesn't have both, they should not be able to get into the database.

[jcline]

I'm also no qualified to judge, but I would say it's important that in addition to rotating the password and key file used to encrypt the password database, one also rotates the all the passwords in the database regularly. This way, if someone obtains a copy of your database, they have a limited time before all the passwords in the database become useless.

[asquabventured]

This is true, as well as enable 2-factor authentication for sites that support it.

[jmcphers]

I do something very similar to this, but I sync the key file to a second service (both services have 2FA logins). Keeping it off "the cloud" entirely is indeed safer from a security perspective, but think about how many copies of your key file you have, and what would have to happen to destroy all of them. If you've just got the key file locally on e.g. your laptop and maybe a smartphone, it doesn't take much more than a petty theft to cause you to lose access to every service in the database (in which situation of course you'd paradoxically want access to those services right away!).