Hacker News Reader

Comment by JamesCoyne | Hacker News Reader

Anybody have thoughts about where to store the encrypted database for backup? Would it be foolish to keep the database somewhere publicly accessible?

View on HN

I store the .kdbx (database) file on a network synced folder (e.g. like dropbox or gdrive). However, I use a "key file" in addition to a password. The key file is not synced and remains on computers that I control. I also have a backup copy on external media.

Aren't you worried about that fact that any program you run could potentially read all your passwords using the key file?

You can have a composite password to unlock consisting of keyfile + passphrase.

Ah, I see! That makes sense.

keyfile in addition to a strong password.

There is one gotcha that you need to think about that hasn't been mentioned. If you back up your password database online, and your master file is lost in a fire, you need to be able to access the online backup service without requiring your password manager.

You either need to remember the password for the online backup service, or you need to have another copy of the file in a remote location that you can access physically, like on your work PC if you don't work from home, or at a family/friend's.

That's a good one to be prepared for.

I don't know what Dropbox's account recovery procedure is (which does have a support ticket system available), but if you also back it up to Google Drive; you can recover the Google account by an automated phone call to a specified number.

Accessible off-site backups are obviously good, but for various reasons it's unlikely everybody does this so I think the method above should be reasonable.

If it's something as dire as a fire where all devices including the phone are lost (by the way, for Android I favour Keepass2Android which comes with Dropbox syncing & fingerprint reader support), you would probably need to get replacement identity documents as well as a new phone & SIM card for the same number (it's probably quicker in the meantime to have the Google Account Recovery robot call another number you've previously listed to reset a 2FA/password).

Additionally, I don't think using a Diceware passphrase is a bad idea so long as it's never reused. After all, a solid passphrase is required for the password database, so learn two (or three - quick local system login might also handy). The process with real dice is quite fun to do and feels meaningful enough that it's adhered to and memorised.

I think a combination of no more than a few Diceware passphrases combined with password manager-generated passwords for all other sites is a balanced option. For typed passphrases, I no longer use anything except Diceware - not only are they easier to remember and enter, they're also more "expendable" and don't require any particular attachments to be formed since the generation process is robust and unbiased (unlike "hashed" passages from books and song lyrics).

For English-speakers, I recommend the EFF's list linked at http://world.std.com/~reinhold/diceware.html

It's not ideal for your encrypted db to leak because, should you mistakenly leak your master password (which can happen simply through a keylogger for example), all the contents are now at risk.

However, something like Google Drive is fine. Trust Google engineers to secure your data. Dropbox also fine if you don't like Google.

This makes sense. Presently my database lives on dropbox and is not in view of the public.

Assuming you chose a strong passphrase, which you safeguard properly, and barring keyloggers, you should have absolutely no issue having your encrypted database published on the front page of google.com and offered to everybody.

Just ensure you have a few million key transformation iterations to really harden it against bruteforcing attempts.

In reality, though, given that you can never be 100% sure you don't have a keylogger or other malware, you shouldn't really volunteer half the keys to the kingdom (= the database) to the world.

Actually, if you handle third party data this could even be a breach of regulations (think HIPAA)

I've bounced between a number of cloud drives/sync folder services over time.

I'm currently happy with Resilio Sync, fka BitTorrent Sync. It uses peer-to-peer sync ala BitTorrent, where the only "cloud" shares are peers you build/authorize. It supports encrypted shares where some of your peer devices, such as your "cloud" share, may participate in syncing the swarm without being able to directly decrypt its contents.

https://www.resilio.com/individuals/

I use Resilio Sync to get the database to my phone, to my laptop, to my workstation at work and to my ZFS FreeNAS box at home. The NAS box does snapshots so any mistakes are easily reversed if needed.

The key file I just keep with me, doesn't follow the database, even though I own the cloud storage.

Btw. this is definitely the best password manager I've used. A simple QT interface and and I have it available from Mod+Shift++ in my i3 setup.

I would be leery of storing the DB file somewhere public (e.g., a public Github repo) even if it's encrypted with a private key file. I prefer the method mentioned by @nas which is what I personally do.

I store mine on a personal NextCloud with davfs, but any secure online storage should do.

I use Spideroak (https://spideroak.com/one/). They encrypt your data. That coupled with the DB being encrypted means it's about as secure as you can get while cloud syncing.

Reply on news.ycombinator.com