10

Where do you store the KeePass-DB?

Where would you recommend me to store a Keepass-file? Usually I have my personal documents in my cloud account - but i am not sure if this is safe. Would it be safe to use the cloud for this file? Can i secure it even further, by adding another (extra) layer of security by encrypting the file. General question; How safe is this? What risks do I need to know about?

What can I do with the KeePass password file, there are several arguments to decide where to store it. In my humble opinion, if the passwords are really, really important to someone, one should make the decision based on:

  • the risk of the file being hacked - what can we do if we consider to get hacked
  • the risk of losing the file because of having a bad hdd - what do you do if you face disk errors. And sure thing -. there are more things to think
  • what if someone may compromise the file
  • is it preferable that the DB file not get in the wild,
  • there may be more and other risks - which one do you take into consideration"?
  • what if my cloud storage account is getting compromised then having the credentials recovered by either brute force or some other attack vector.

What if someone may compromise the file?

  • Options; can I secure it even further, by adding another layer of security by encrypting the file i am going to store in cloud storage online.
  • regarding the master password: master password provides pretty good security as long as i choose a difficult to brute force password (long and truly random),
  • on the other handside - a masterpassword still can't compete with an actual long encryption key.
  • we can increase the resiliency of the KeePass database to brute force by increasing the number of PBKDF2 iterations
  • we can do this in KeePass under File > Database settings > Security: Personally, I use around 10,000,000 rounds (2 s delay).

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

What can I do with the KeePass password file? Which of the arguments do you take into consideration, to decide where to store it?

  • 1
    I think "a long and truly random masterpassword" actually is "an actual long encryption key", just usually in ASCII – Xen2050 Dec 26 '18 at 18:14
  • 1
    Are you asking about storage of the KeePass _database_ file, a _key file_ used to decrypt one of those database files, or both? – Michael Dec 26 '18 at 19:48
  • 1
    I have a keepass database stored in dropbox that I use to sync between systems. Each system has a local keepass database file and triggers to sync changes to/from the central file in dropbox. –  Dec 26 '18 at 20:01
  • 1
    Possible duplicate of [Storing KeePass database in cloud. How safe?](https://security.stackexchange.com/questions/45272/storing-keepass-database-in-cloud-how-safe) – gerrit Jul 11 '19 at 08:43

3 Answers3

6

The best place to store your Keepass DB file is wherever it is most convenient for you. With a sufficiently strong password, you could even post your DB online publicly and still sleep well at night. Just make sure to:

  1. Use a long password (20+ characters) that is not guessable outside of brute force.
  2. Set a high number of iterations used to generate the key from your password. (I use 5 million iterations for mine.)

I personally like storing my Keepass DB in Google Drive because it allows me to easily access my DB from both my phone and my laptops. As a bonus, it also is automatically versioned every time I update it. Tip: if you do use Google Drive or another service that versions your file for you, I recommend deleting the version history (or delete the file and re-upload), every time you change the master DB password.

TTT
  • 9,132
  • 4
  • 19
  • 32
  • This *really* depends on the complexity of the password and the number of iterations for the KDF. With too few iterations and a weak password, this approach could be terribly insecure. On the other hand, with good values, it is extremely convenient and most likely very secure. – caw Dec 28 '18 at 17:33
  • @caw when you say "this approach could be terribly insecure", which approach are you referring to? – TTT Dec 28 '18 at 17:44
  • I was referring to “stor[ing] your Keepass DB file […] wherever it is most convenient for you”, e.g. “in Google Drive”. At least some time ago (I haven’t checked again), KeePass used a very small number of iterations by default. And we all know that “non-technical users” rarely change defaults. Combined with a weak password, such as “horse06”, which has a quality that many non-technical users regard as sufficient, that is most likely not secure enough for some basket that you put all your eggs in. If stored on remote servers, there could even be data breaches outside of your control. – caw Dec 28 '18 at 17:52
  • @caw - I didn't think one could read my first sentence and assume that would apply to a weak pw after reading the rest of the answer. But OK, I changed some wording to make it clear that "my approach" includes the strong pw. ;) – TTT Dec 28 '18 at 18:18
4

In theory, you can store the database file anywhere, it's encrypted with it's own passphrase (or keyfile).

If you're worried about someone trying to guess your passphrase or otherwise break into it, you're free to encrypt it a second time with any other reputable encryption method. GPG/PGP is good, or a TrueCrypt successor, or a dm-crypt/LUKS container (though LUKS are generally >2MB, a KeePass database could be under 100k), there's a lot to choose from.

Encrypting the file a further 3rd, 4th... nth time should multiply your protection (provided the encryption itself isn't broken), but it also multiplies the number of passphrases/keyfiles you have to remember, and the time to decrypt them all.

In case someone modifies a KeePass database file, even one byte difference, KeePass should notice and warn you. I tried modifying a single byte in the middle and it complained:

The following error occured while opening the database:
Hash test failed.
The key is wrong or the file is damaged.

Modifying the very first byte complained:

The following error occured while opening the database:
Wrong Signature

Modifying a byte in a gpg file gives a similar complaint (but still decrypts the file, with about 8 bits changed - KeePass would then complain again refusing to open it):

gpg: WARNING: encrypted message has been manipulated!

You can always keep your own checksum/hash of the file too (sha sums are popular, md5sum still, even a CRC32 should detect corruption), just to verify that it hasn't changed.

Xen2050
  • 227
  • 1
  • 7
  • 3
    Encrypting the file multiple times with separate passwords doesn't give much extra security if each of the passwords can be brute-forced separately. For example, encrypting the file four times with 8 character passwords each time is much less secure than encrypting it once with a 32 character password. (log2(26^8*4) = 40 bits of entropy vs log2(26^32) = 152 bits for simple alphabetic passwords.) – Jacob Bundgaard Dec 26 '18 at 19:47
  • @JacobBundgaard Everything can be brute-forced, but I'm assuming one would use sufficiently long passwords so that guessing the password wouldn't be much faster than brute forcing the encryption directly. Then each time it's encrypted should add some significant guessing time – Xen2050 Dec 27 '18 at 00:11
  • If guessing the encryption keys directly is easier than guessing the passwords and deriving the keys, the same argument just goes for the keys: One encryption with a longer key is better than multiple separately crackable encryptions with shorter keys. (The point is moot, of course, if your encryption algorithm or software doesn't let you choose the key length.) – Jacob Bundgaard Dec 27 '18 at 08:21
  • @JacobBundgaard KeePass does not let you choose the key length (only KDF iterations & algorithms, 256 bit AES or Twofish seem standard). How long of a type-able (US keyboard ASCII) password would you pick for KeePass's 256bit key encrypted database? [This answer](https://security.stackexchange.com/a/117621/63902) says 100 bits (or 8 diceware words) would be sufficient, does that sound right? – Xen2050 Dec 27 '18 at 19:04
  • I think that sounds sensible, but my comment was really just about the part of your answer that states that "Encrypting the file a further 3rd, 4th... nth time should multiply your protection". It's technically correct, but if you're already remembering multiple passwords/phrases, why not just concatenate them, encrypt once, increasing the key size if necessary, and exponentiate your protection instead? (This is assuming that it's possible to check if you've found the correct key for the outer layers of encryption, for example by looking for a fixed header in the decrypted data.) – Jacob Bundgaard Dec 27 '18 at 23:21
1

Few things:

  1. Keep the master passPHRASE not passWORD on somewhere NOT in the cloud.

  2. Consider using some form of pki if you plan to have copies in the cloud of some other format/location ( like a safety deposit box ) so that compromise is easier to spot as well. If someone were to play funny with it the key (PGP/PKCS or similar) would be all sorts of screwed up playing the needed aspect of canary.

  3. look into rate-limiting inside and outside of KeePass application

  4. if possible for networked devices or separate hard drives set locks on users and credentials that would be allowed to access this.

  5. The RINGER: in the event of a compromise of YOU, illness, captive or whatever, does a trusted party have a way to access without giving them your personal key(s) or full access unless needed (a lawyer, doctor for example)

alecxe
  • 1,565
  • 5
  • 19
  • 34
linuxdev2013
  • 119
  • 3
  • 1
    By pki do you mean public key infrastructure? How would it assist with keeping copies online? Or be useful, since you're the only one who's encrypting and decrypting the file? – Xen2050 Dec 26 '18 at 17:58
  • Even if you are the only one, you must assume you will be accessing or have a need to from multiple machines/terminals or the cloud allows for access from virtually any network connected device with access to said cloud provider. This is where using PKI ( yes Public Key Infra) would help making sure it is ACTUALLY you (assuming you have not allowed the credentials to be also compromised) – linuxdev2013 Dec 27 '18 at 00:05
  • If you're planning on accessing your KeePass database from multiple (any?) machines or the cloud, how would you have your secret key to decrypt your file? And if you had your secret key, why not just keep your KeePass database too? – Xen2050 Dec 27 '18 at 00:16
  • A USB token or secure hardware token, I'd recommend looking into and reading up on 2FA/MFA solutions if you are truly serious about rolling out such a schema for your keepass and keeping the highest level of accessibility and security/confidentiality for it as well. – linuxdev2013 Dec 27 '18 at 00:22