You can sync it over Dropbox or a similar service. I actually prefer it that way, since it decouples the password manager from the syncing/sharing service.
I currently use KeePass (regular one, not XC) with a trigger to sync with dropbox. It works very well to share passwords with my wife but it requires a bit of effort to setup (I mean for non tech people).
I have not tried KeePassXC yet (I'm under Windows), but I wonder how it compares for this kind of setup.
I trained my parents to use KeePassX 2.0 and they do OK with it. They're very tech non-savy but do fine with it because they only have to remember one password. I also made sure they use Timemachine for OSX so they don't lose their database. Prior to this they had a physical notebook and sticky notes with passwords written on them.
> but then you have the same security tradeoffs as more polished services like Bitwarden or LastPass.
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.
Wasn't it shown recently that LastPass literally downloads JS from their servers to run on specified pages for compatibility? I suppose that's good for ease of use, but pretty scary from a security tradeoffs perspective and indeed KeePassHttp doesn't require you to make any sort of tradeoff like that.
It's not too bad at all. You need to walk through it with many users.
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.
On Linux it made a big difference, esp. because KPXC does not require Mono. The GUI feels more natural, is stable and plays well with the system tray (which was a sore point with KP2).
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.
Yeah, it is. KeepassXC supports 2FA. (Note however that keeping your 2FA seeds in the same database as your passwords reduces the security aspect of a second factor)
I'm strongly considering it just based on the community surrounding each project.
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.
That's just a zipped snapshot of the source code as of the current release; it doesn't necessarily reflect current development on the project.
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.
The threads found on this are disappointing as well ([1] and [2]). The author(s), as far as I can tell, only make the source available for each release. They do not want a public repository and are very resistant when others ask.
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.
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
I just switched from MacPass to KeePassXC for the reason mentioned in release notes: it obsoletes the HTTP Connector and uses another mechanism. MacPass keeps using HTTP, and it is uknown, when it will do the same switch.
Given that I use multiple computers, and the extensions are synced, I want to use the same mechanism on all of them.
The new mechanism uses Native Messaging[0], with the native application being keepassxc-proxy. The old one used HTTP, with the server (the password manager) listening on localhost.
I was a little confused by your comment at first, maybe you didn't intend it that way, but I got the impression that you meant MacPass is open source, unlike KeePassXC. Except that KeepassXC is in fact open source: https://github.com/keepassxreboot/keepassxc/
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 :)
Well, in my amateurish opinion - there was nothing wrong with the existing AES encryption implementation. But they also had a key derivation function based on running many iterations of AES, which was weird and non-standard, I mean it seemed like it would work, but it's not proven in the cryptographic community. Now they've switched to Argon2 which is a very well reviewed KDF and I have a lot more faith in that.
The XML Format has changed. Entries and Groups now support custom data. This was only supported on the database in KDBX3.1. Also, the settings now have a modified date which makes synchronising them when merging databases a lot easier.
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.
is it stable again? Last version was constantly crashing when modifying a new passwort entry again. This is something which is unacceptable for a password manager IMHO.
the bug is still there. 2.3 can still crash after creating a new entry and reedit the password. I will try to reproduce the error with a new kdbx and report the bug.
I highly recommend https://keeweb.info/ if you're looking for an attractive, easy to use, cross-platform and Open Source solution. I've been using it on Windows and MacOS for years without any major issues. It's by far the best looking front-end for keepass databases I've seen.
I love KeeWeb, especially when used together with Nextcloud. I can access my passwords in a buch of different ways, all synced and all secure (the kdbx has a password and a file key).
1. In KeeWeb from inside Nextcloud (there's an app)
2. In external KeeWeb over WebDAV (great when using it as a PWA)
3. In KeePass proper using desktop file sync
4. In a KeePass-compatible app from the Nextcloud app
All of these sound janky, but they work better that any other free software self-hosted cloud password manager.
KeePassXC can read KeePass2, so it only needs to replace that. That said, I haven't found a Kee replacement I like, so I'm still on KeePass2 (and it's fine for my needs).
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.
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.
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 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.
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.
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.
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)
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.
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).
Since it got a lot of positive attention last time, here's a rough guide on getting started with password management, aimed at readers here who are not currently using a password manager:
I address that at the bottom of my post. Keepass is the original, KeepassX is the Qt rewrite.
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.
Is it worth moving to this from 1Password? I mean I don't have any problems at all tho I use an old version (6 on Mac, 4 on Win), the permanent license version not this new subscription.
I was thinking to use this with Dropbox, Chrome, and iOS client (MiniKeePass?)
- 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.
Bitwarden has a desktop app(electron .. sigh but is cross-platform) and has integrations with all the major browsers (Safari, Firefox, Chrome, IE)
Bitwarden also has Mobile support (iOS, Android & UWP).
KeepassXC only does Chrome(and family) and Firefox I believe.
Running your own bitwarden server is not difficult, and there are 3 implementations that I know about:
The original .NET: https://github.com/bitwarden/core
The Ruby one: https://github.com/jcs/bitwarden-ruby/
The Go one: https://github.com/VictorNine/bitwarden-go
FYI: the new browser extension KeePassXC-Browser relies on native messaging which is not supported by Safari. IE/Edge support could be done in the future.
KeepassXC supports KDBX4 so any client that can read KDBX4 can be used alongside it. KeepassXC is also definitely a desktop app, it can do autotyping and similar things.
There is Android and iOS support via keepass2android and <insert ios app name here>.
You can safely put your KDBX file on dropbox/gdrive/nextcloud/ipfs.
Does anyone know of an iOS client that supports Argon2? The amazing Keepass2Android already supports it, but I can't move to it until there is also an iOS solution…
> 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!
Not all parts of the source code are available under the same license. The individual source code files include the applicable license. Doing this is fine for compatible licenses and not unusual for projects, though it can make certain things more complicated. Here's an example of what GNU says about GPL compatibility[1] - roughly meaning the whole work is published as GPL.
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.
I was a longtime user of KeePassX. The UI was terrible, but it was free, open source and most importantly cross platform.
After KeePass2 made the DB incompatible and rewrote everything in C# it stopped being a proper cross platform product and I investigated aternatices. I've since moved to enpass and I'm very happy. Enpass is a great, native app on Win/Mac/Linux and has native Android/iOS apps (with fingerprint support etc..). Great UI, no subscription fees, no cloud hosting (though it syncs to your personal dropbox, gDrive, OwnCLoud etc..). I couldn't ask for more.
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.
The mentioned issue has the following statement which makes me wonder whether concurrent use on sync services is supported atm:
> 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.
From my experience, it already works somewhat. Atleast, whenever I overwrote the file in Nextcloud and my desktop pulled the update, it would merge the changes automatically.
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.
It's in my opinion just a straight upgrade from KeePassX. Not a significant upgrade, but switching is probably not going to require significant effort either.
I always find it interesting to see which of the new distro agnostic packages these applications provide. In this case AppImage and Snap.
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.
The thing that keeps me in 1Password is its Team Vault support. Nothing works quite so well for maintaining a shared password vault. If I didn't need that, I'd drop 1Password for KeePass in a heartbeat.
I really wanted to switch to using KeePassXC instead of the original one, as it's definitely a better user experience for the most part when you're flipping between OSes (Windows 10 and various Linux distros in my case). But my workflow requires I keep my kdbx in a git repo in order to sync between work and home, and I cannot get used to the missing "Synchronise with File" feature, which the original Keepass has, but KeePassXC omits.
I'd prefer if a password would be generated by default, when you create a new entry. That's the way KeePass works and it encourages to use strong generated passwords (instead of user created passwords).
Actually it's cool that it was forked. But qt5 apps have pretty bad fonts view on my xfce desktop especially with black themes like Ark dark. That's why I am on KeepassX so far.
104 comments
[ 5.6 ms ] story [ 161 ms ] threadI 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.
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.
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.
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 do recommend that anyone without PW manager atm either try KPXC or Keepass itself. It's worth it for your security.
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.
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
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......
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...
[3] https://github.com/dlech/KeePass2.x
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.
Code for the old KDF is here if anyone's interested: https://github.com/keepassxreboot/keepassxc/blob/7a55ab64d83...
Does anyone knows where is the specification for KDBX 4.0?
EDIT: Found it — https://github.com/keepassxreboot/keepassxc-specs
https://keepass.info/help/kb/kdbx_4.html
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.
https://chrome.google.com/webstore/detail/keepassxc-browser/...
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.
KeepassXC doesn't work on iOS. It is just a replacement for KeePass2
However, something like Google Drive is fine. Trust Google engineers to secure your data. Dropbox also fine if you don't like Google.
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/
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.
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)
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
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.
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.
Bitwarden has a desktop app(electron .. sigh but is cross-platform) and has integrations with all the major browsers (Safari, Firefox, Chrome, IE)
Bitwarden also has Mobile support (iOS, Android & UWP).
KeepassXC only does Chrome(and family) and Firefox I believe.
Running your own bitwarden server is not difficult, and there are 3 implementations that I know about:
There is Android and iOS support via keepass2android and <insert ios app name here>.
You can safely put your KDBX file on dropbox/gdrive/nextcloud/ipfs.
Bitwarden is basically identical across all the platforms. KeepassXC is not, since it's totally different apps for mobile, etc.
Did they just copy paste every different license they could find into the repo?
> 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!
[1]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
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.
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.
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.
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.
Or put it in git even, if you want better traceability.
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.