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.
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
However, something like Google Drive is fine. Trust Google engineers to secure your data. Dropbox also fine if you don't like Google.
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'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.
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 have not tried KeePassXC yet (I'm under Windows), but I wonder how it compares for this kind of setup.
It could be better with good browser plugins, but then you have the same security tradeoffs as more polished services like Bitwarden or LastPass.
This latest version KeePassXC has a whole new browser plugin:
https://github.com/keepassxreboot/keepassxc-browser
So maybe it has reached that point now? Not that I've tried it, but it's at least promising that they've been working on it.
Not exactly. The database is handled with an independent program. With the new model, AFAIK, the browser extensions have no idea what records exist and can only query - and record matching is actually authenticated before plugin sees anything.
My wife, parents and in-laws all use it. The only thing that is a gotcha is sync. It's isn't obvious to folks that when you open a synced vault on an iOS device that it may not sync back.
I used KeePassXC for a period, but from these release notes, the UI/UX still isn't great. If you're on macOS, I recommend MacPass, which feels more native to the system, is compatible with existing KBDX databases and most-importantly, is also open-source: https://github.com/MacPass/MacPass
Given that I use multiple computers, and the extensions are synced, I want to use the same mechanism on all of them.
[0] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Na...
I suppose you meant that MacPass is open source, unlike some other Mac password managers?
I didn't really check until someone downthreads mentioned that KeePassXC is (basically) a superset of KeePassX, which I know is open source because I use it as my password manager. So that means it's time for me to check out KeePassXC :) See what it does for me :)
I can finally give this a shot without having to use the weird custom AES-based KDF Keepass used to use. Awesome.
Congrats on the release.
Does anyone knows where is the specification for KDBX 4.0?
EDIT: Found it — https://github.com/keepassxreboot/keepassxc-specs
The other changes are done to the binary format as you say. Also to make the file smaller, attachments are now stored compressed "as is" instead of encoding them in base64 and adding them to the XML structure.
Code for the old KDF is here if anyone's interested: https://github.com/keepassxreboot/keepassxc/blob/7a55ab64d83...
KeePass 2 seems to still be hosted on Sourceforge, and I'm not even sure where to get a copy of the latest (non-release) version of the source. The [Sourceforge repo][1] seems to be an outdated SVN repo which was last updated in 2009, and I don't see any description of how to contribute code to the project anywhere. As a result I'm not really sure how to gauge the level of activity on the project itself. Similarly, the website is ancient and doesn't seem to have kept up with the times; I seem to recall it was only recently that it even got HTTPS support.
In contrast, KeePassXC is hosted on GitHub, development is done out in the open, and it's trivial to see that in just the last year there were [dozens of individual contributors][2]. The website looks clean, is user-friendly with up-to-date documentation, and a [contribution guide][3] is plainly visible in the README on GitHub.
As a result, I feel a bit better about the long-term prospects of KeePassXC over KeePass 2.
[1]: https://sourceforge.net/p/keepass/code/HEAD/tree/
[2]: https://github.com/keepassxreboot/keepassxc/graphs/contribut...
[3]: https://github.com/keepassxreboot/keepassxc#contributing
They do make the source available with each release, and a user has mirrored them onto GitHub [3]. I also cannot find the source for older releases.
[1] https://sourceforge.net/p/keepass/discussion/329220/thread/0...
[2] https://sourceforge.net/p/keepass/discussion/329220/thread/b...
With KeePassXC for example, even though the latest release came out less than a day ago I can see that there have already been [14 commits][1] to the `develop` branch since that release. I can't find the equivalent of such a branch for KeePass 2.
[1]: https://github.com/keepassxreboot/keepassxc/compare/2.3.0......
On Windows, KPXC might actually be a step backward since KP2 is quite stable and has more plugins. I'm not sure which is more secure between the two.
Electron apps ...
I've tried the offline versions, but I find myself often on the go - without my laptop.
The tools for mobile don't seem to support updates - read only. Keeweb does both.
If you use Keepass on something like Dropbox it's a blessing.
> I was going to add tests for "concurrent" access of the same file in phase 2 of these changes. Phase 2 is refactoring the saving process entirely to make it asynchronous and robust to file sync services.
Did they just copy paste every different license they could find into the repo?
This comment is really funny and made me laugh.
Anyway we are following the Debian guidelines. The full copyright for each component and file is specified in the COPYING file in the root of the repository along side with each author.
[1]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
> The full source code is published under the terms of the GNU General Public License. We see open source as a vital prerequisite for any security-critical software product. For that reason, KeePassXC is and always will be free as in freedom (and in beer). Contributions by everyone are welcome!
https://leclan.ch/password-managers/
TLDR: Download KeepassXC and start using it. :)
KeepassXC got Qt 5 support, a bunch of misc QOL improvement patches, is actively maintained (unlike KeepassX) and also received some nice extra features such as TOTP 2FA support. It's a superset of KeepassX, so there's no real reason to use KeepassX at this point.
KeepassXC doesn't work on iOS. It is just a replacement for KeePass2
I switched to Bitwarden for that reason alone.
With that said, Bitwarden has it's issues: https://github.com/bitwarden/browser/issues/77
Probably you mean KeePass (the "original" one), which is written in C# and requires Mono in Linux ? KeepassX has always been native C++ and cross-platform.
I was thinking to use this with Dropbox, Chrome, and iOS client (MiniKeePass?)
Let me try to make it a little bit more detailed.
====================
Bitwarden:
- Is essentially a service (with FLOSS client software and FLOSS server code).
- Quite polished browser integration (to the extent browsers allow it).
- Third party server holding the encrypted data. Proprietary (in a "completely unique, not compatible with anything else" sense) sync protocol.
- Symmetric encryption key is encrypted with master key but it is NOT changed (with re-encrypting all the entries) when master password is changed. I'm not sure if there is an option to re-encrypt the data in case the symmetric key is compromised, although this should be doable via APIs.
- Data is encrypted and signed, but some of the data structure (folder layout, TOTP existence, revision dates) is (theoretically) accessible to the service owners. Check out snippets at https://github.com/jcs/bitwarden-ruby/blob/master/API.md for info.
- Has some nice extras built-in, like domain equivalence logic.
- Self-hosted option is available (official Docker images using .NET Core and Microsoft SQL Server and unofficial third-party implementation in Ruby). I'm not sure how this works with licensing.
====================
Keepass:
- Is primarily a standalone application. Or, better say, applications, as there are multiple independent implementations for many platforms.
- Has browser integration, but all options (KeepassXC-Browser and PassIFox) are feel somewhat less polished.
- Has composite credentials (in addition or instead of master password it can use i.e. keyfiles). Supported mechanisms vary with implementation.
- If the encryption keys are compromised you can trivially re-encrypt the database to avoid further leaks.
- File format is essentially a large encrypted and signed XML file (data block) with some extensible header that defines the crypto details. https://keepass.info/help/kb/kdbx_4.html
- You handle the sync however you want it. For KeepassXC you need make database available in a filesystem. For Keepass and Android app there are also SFTP, WebDAV, Dropbox, Google Drive and some other options available. The only sync that's in the app is a logic for merging databases.
====================
Please correct me if I got something wrong. Thanks.
Q: Why KeePassXC instead of KeePassX?
A: KeePassX is an amazing password manager, but hasn't seen much active development for quite a while. Many good pull requests were never merged and the original project is missing some features which users can expect from a modern password manager. Hence, we decided to fork KeePassX to continue its development and provide you with everything you love about KeePassX plus many new features and bugfixes.Another thing I'd like to have is a details view for each key in the list view (https://keepassxc.org/images/screenshots/linux/screen_002.pn...). Something like the bottom panel here: https://keepass.info/screenshots/keepass_2x/main_big.png (but please more beautiful). I have a scenario where I need an additional authentifiction factor besides that password that I store in KeePassXC, too.
https://chrome.google.com/webstore/detail/keepassxc-browser/...
Or put it in git even, if you want better traceability.
I do recommend that anyone without PW manager atm either try KPXC or Keepass itself. It's worth it for your security.
It really looks like AppImage is taking the lead among these new packaging technologies. When the project does provide these sorts of packages you always see AppImages, but rarely see Snap or Flatpak based images.
