Earlier quoted context omitted.
> Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much. Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords. I'm certainly happy to accept a bit more inconvenience than most. I only do banking…
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 keep…
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?