Storing KeePass database in cloud. How safe?

Question

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?

score 63 · Answer 1 · answered Nov 12 '13 at 08:16

63

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.

answered Nov 12 '13 at 08:16

Matrix

3,988
14
25

5

This is actually the best answer. In fact, what @Matrix suggests is **crucial** to secure a KeePass database. By default it is set to 6000 encryption rounds, which is insufficient to thwart a bruteforce attack. I don't understand why I'm the only one to upvote this answer. – dr_ Jul 14 '15 at 09:02
@dr01 not only you. This happend also with other encryption programs, are setup to maximum speed instead of maximum security. It's so preferable to read slow but remain secure. No problem to read at 50mb/s instead 200mb/s. 50mb are for movies and mega big files, not for sensible data. – m3nda Oct 04 '15 at 21:48
1

Just an 2017 update: 1 second delay on my new machine now corresponds to around 28,000,000 rounds. – Igor Brejc Aug 08 '17 at 14:45
2

This should be right at the top because I was shocked to see the default 6000 rounds **broken in just 0.001s** – Prof Dec 30 '17 at 16:54
3

It should be noted that the new Argon2 KDF, supported since Keepass 2.35 and KBDX4, is probably preferable than AES KDF, as it can also be configured to use significant amounts of memory. – timuzhti Mar 15 '18 at 07:17
We should add that a strong password is a prerequisite, it's necessessary but not sufficient, we also need a good algorithm+iteration as said. I personnaly use a password with 20 characters really random. – pdem Apr 23 '19 at 10:21
dr_ and @Prof, at what key length? Is this still true for a 64 random alphanum characters key in the second slot of a Yubikey? – alchemy Apr 17 '20 at 20:50
It appears @Adi's answer below has equal merit. It would be good to have a comparison between added iterations and added random character length. – alchemy Apr 17 '20 at 21:20
Here is one calculation for a 10 character random password with default 6000 iterations. It takes 50 million years.. https://security.stackexchange.com/questions/8476/how-difficult-to-crack-keepass-master-password – alchemy Apr 19 '20 at 02:31

AJ Henderson · Accepted Answer · 2018-01-30T16:09:44.623

37

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.

edited Jan 30 '18 at 16:09

answered Nov 11 '13 at 14:20

AJ Henderson

41,816
5
63
110

A VPS is worth having for just about every security-conscious person, IMHO. Vultr, DigitalOcean, et al start at $5/mo and you can load up a VPN, OwnCloud, etc on it. – Arthur Kay Aug 20 '15 at 20:09
Security only exists on localhost. Once you put files into a "another's" server you don't control it. The really best option is to use strong password on databases, plus a key file inside mobile or pendrive, plus a yearly change of passwords to put back any bruteforce attempt. – m3nda Oct 04 '15 at 21:41
7

@erm3nda it is true you don't control someone else's system, but you also don't fully control your own. It is a false statement to say security only exists on local host. Your pen drive is susceptible to being lost or stolen. There are sla based providers with security guarantees that let you know what they are doing. You still want to have your own protective measures (line storing the data after encrypting client side) but in some situations a third party is in a better position to fill certain security elements more securely for less cost and effort. – AJ Henderson Oct 04 '15 at 23:20
Lossing a pendrive is not a problem if you have backup the keyfile into another site, another smarter site than just a usb physical device. There's no chance to dropbox (in example) to bruteforce my security if the files has never been on their servers. I cannot be more clear than, mix things and you're done. Never let anyone the full puzzle pieces. – m3nda Oct 05 '15 at 07:37
@erm3nda ah, if you were simply suggesting that you should use something you keep with you to prevent decrypting the files stored online then I agree and think we are saying the same thing. There is a question of when it is enough for your needs, but that's a personal call. – AJ Henderson Oct 05 '15 at 12:59
@AJHenderson " use something " , i say exaclty using keyfile. Keyfile is a special file created from pass/paraphrase and you can't read crypted content without both passwd and file (2 layer security). No matter what they can read, they need your special file to being able bruteforcing it. This technique is used worldwide (usually also with smartcard or pendrives) and as example, Keepass does have that option. While dropbox doesn't hack your computer and do not have access to your physical pendrive your file is safe on their servers. – m3nda Oct 05 '15 at 13:06
See @Adi answer below, it's the same thing and it's the best current option. – m3nda Oct 05 '15 at 13:13
@erm3nda - I say "use something" simply because there are more than one valid way to separate the pieces you need and you can potentially split it up over multiple places as well. You could use a biometric protection, you could use a key you carry with you, you could carry the data with you but store the key offsite (less common, but prevents brute forcing of the data even being an option without compromising your person or a system you use). The important part is making multiple points of compromise required. Key file was ambiguous since we are talking about a password db... – AJ Henderson Oct 05 '15 at 13:19
1

Since you were new to the site and were making a blanket statement like "security only exists on localhost" which isn't true in either the paranoid sense or the realistic sense of the term, I assumed that you may be mis-refering to the password db itself when you said "key file". I see now that was an error on my part, though clarification (which we've done now) is good to avoid others making the same mistake. Adi and I are saying the same thing. He mentioned a strong master password. I just went in to further explanation of why. I'll add a bit about using an actual local encryption key. – AJ Henderson Oct 05 '15 at 13:27
`but if your security depends on the encrypted file remaining confidential,` -- what do you reffer to you? built-in Keepassx password? Or additional encryption by myself? – Incerteza Oct 06 '18 at 19:59
I'm sorry, I'm not sure what you are asking. – AJ Henderson Oct 06 '18 at 20:34

score 24 · Answer 3 · edited Jun 24 '16 at 14:11

24

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.

Simply put: Use a strong master password and stop worrying about this.

edited Jun 24 '16 at 14:11

Bob Ortiz

6,234
8
43
90

answered Nov 11 '13 at 16:41

Adi

43,808
16
135
167

`The password database is encrypted using a key derived from a strong master password` -- how is that done? Do you encrypt your KeepassX db file *additionally*? Or is that the password of your KeepassX and nothing else? – Incerteza Oct 06 '18 at 20:00
This is the just once piece of cross-referencing I found in a Reddit comment, but it would be good to have a quantitative comparison between added iterations and added random character length. "True "brute force" (trying every possible character combination) is completely untenable after around 12-14 characters regardless of iteration count." https://www.reddit.com/r/KeePass/comments/886hm0/question_about_keepass_and_brute_force_attacks/ – alchemy Apr 17 '20 at 21:22

John Deters · Answer 4 · 2013-11-11T17:09:18.423

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.

So yes, as long as you trust KeePass, and trust your devices, and trust your ability to keep your master key secured, don't worry about keeping the database in Dropbox.

Every encryption you use now, would be easy hacked in a couple of years with less than a hour of computing work. I can assure everybody that use both strong password + keyfile is the only real way. Mix digital and physical barriers. Dropbox cant read your usb pendrive. Anyone who stole your pendrive may not know your password. Mix is the key, don't let other to know your way. — m3nda, Oct 04 '15 at 21:44

score 8 · Answer 5 · answered May 23 '14 at 23:05

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

The keyfile should be stored in a separate secure location, such as a USB drive which you can secure physically. This provides 3 layers of protection:

Dropbox account (assume low security)
Your strong password (strong)
Your keyfile (as secure as you make it)

Don't forget to have two or three USB keys with the encryption key on it. Preferably in separate, trusted locations. — Arthur Kay, Aug 20 '15 at 20:07

Dmitry Grigoryev · Answer 6 · 2015-10-05T14:06:25.820

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.

You're also giving the attacker information about your password-related activity. He will know how often you change your passwords, and may be able to deduce which passwords you change.

So, if you decide to store your password database in a public cloud,

Pick a strong encryption algorithm, resistant to differential cryptoanalysis. Make sure every password in the database is individually salted.
Change the master password regularly, preferably as often as you do with your most valued password.
Don't reuse passwords.

score 5 · Answer 7 · answered Mar 14 '18 at 21:13

I would suggest a solution that involves the following:

KeePass Database file stored on local computer with Full Disk encryption (e.g. Veracrypt)
KeePass Key File stored on an external USB disk
Cloud Storage 1 (e.g. Dropbox) to hold the Database file
Cloud Storage 2 (e.g. Google Drive) to hold a backup of the Key File
Enable 2FA on both Cloud Storage accounts (Mobile authenticator app preferable over Text Message codes)

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.

If Cloud Storage 2 is compromised, then the key file itself if useless without the database file. It's just an extension to you master password, it doesn't contain any data.

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.

score 2 · Answer 8 · answered Sep 04 '20 at 20:09

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 https://www.boxcryptor.com/en/ What additionally encrypt files in your cloud.

Side note: Probably KeePass generates a hash from the password, and then uses it as a symmetric encryption key. If it is so, then your long password makes it hard to find the (wait until a crack against the encryption algorithm used by the KeePass comes out) — peterh, Sep 05 '20 at 07:27

score 2 · Answer 9 · edited Aug 20 '15 at 16:10

2

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!

edited Aug 20 '15 at 16:10

S.L. Barth

5,486
8
38
47

answered Aug 20 '15 at 15:41

MikeB

21
1

score 1 · Answer 10 · answered Jul 03 '16 at 21:08

1

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.

answered Jul 03 '16 at 21:08

globetrotter

11
2

i think this is a really interesting idea! it's better to avoid storage in the cloud altogether. tools like Syncthing and Resilio/BitTorrent Sync come to mind, which sync without cloud storage – symbiont May 22 '21 at 22:07

score 1 · Answer 11 · answered Feb 05 '21 at 09:41

KeepassXC now has support for security keys:

https://keepassxc.org/docs/#faq-yubikey-2fa

Using a security key you can safely store your keypass db in the cloud. Change keepass to save the db after each change (so the Challenge Response also changes)

This method avoids the need to store the keepass db inside another encrypted container (which you could possibly forget the password to)

score 1 · Answer 12 · answered Aug 03 '15 at 02:45

I am a strong believer in defense in depth on this.

No matter how strong your password is, it is also one that cannot be changed.

So to protect my Keepass DB, I am using three layers:

The database has a strong pass phrase (not just a password). I am not using a key file because, for me, the risk of losing the key file outweighs the security benefits.
The database is stored on an encrypted file system (I'm using encfs. By itself, it has of course been shown to be insecure, but it still adds a layer of protection).
The encrypted version is uploaded to an owncloud server, running on my own hardware, and of course over HTTPS.

On why the password cannot be changed: of course you can change the password, and it will actually re-encrypt the Keepass database, but you cannot retroactively change it on old copies.

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.

I would really suggest you to upload your keyfile hide as other filetype, so no one can figure out it is your key. Keyfile is intended to add physical barrier, you should never put keyfile inside same drive/service than database. Lossing your key is the same than forgetting your password, so i don't really understand why you fear about. Usually, using key is only more "work" to open files, but adds a LOT of extra security. — m3nda, Oct 04 '15 at 21:53
@erm3nda Unless your keyfile is actually a valid file in another file format, it would be rather easy to find. — timuzhti, Mar 15 '18 at 07:21
That's true in a degree. You can hide things in many ways, you could also create a binary with real exe headers, then split that part when you read your binary data, which is your key. This topic is so much broad at all... but thanks for your comment :D — m3nda, Mar 20 '18 at 19:39

score 0 · Answer 13 · answered Oct 24 '18 at 08:06

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.

Storing KeePass database in cloud. How safe?

13 Answers13

Linked

Related