KeepassXC – A cross-platform community fork of KeepassX
keepassxreboot.github.io
keepassxreboot.github.io
KeePassXC is a community fork of KeePassX which aims to incorporate stalled pull requests, features, and bug fixes that have never made it into the main KeePassX repository.
But I love KeepassX and I'll certainly try using the fork.
Am I being overly paranoid? How should I be approaching the issue of trusting the developers of password managers?
I would love to audit it but I lack both the time and knowledge. How would I verify that what I've audited is the source for the actual binary that the App Store delivers to my phone?
Welcome to the walled garden.
Hmm. Maybe? The trouble is at some point you have to trust someone and there isn't a good way to measure this. Even if the source of the iOS app was open (I don't know if it is, just a hypothetical) there is no guarantee that the source you looked at is the same that was used to compile the binary itself.
I use one for iOS. I sure hope it's trustworthy. But if it isn't...well I don't really know where to turn to. LastPass? I tried them before but was amazing at how awful the UX was and I was too paranoid that someone would eventually find a flaw, get in and expose everyone's passwords ever because it's a cloud service...I am likely too paranoid.
I upload my keepass and key file to Dropbox (I know, I know) and then export them to MiniKeePass from the Dropbox app. MiniKeepass auto-associates the key file with the kdbx if it has the same filename as the kdbx, but with a .key extension. I can even edit the DB with Minikeepass and upload it back to Dropbox. It's not as sexy as an Android setup, but it works quite well for me.
The new fork is intriguing. Need to take a closer look.
You can disable an app's ability to connect via mobile data in Settings, though that doesn't solve the issue for using the app + wifi.
Does anyone know what happens if you remove the permission from an APK's manifest with apktool etc?
For piece of mind it'd be nice to disable Internet access for certain apps.
EDIT: I know there are solutions when rooted, and also virtual VPN solutions when not rooted. However, in the latter case you have to trust the VPN with all your traffic.
In that context, it seems to me, a paper solution is not totally daft.
The reasoning being that the thief breaking into your home doesn't care about a random sequence of characters, and how it might allow him to steal your online identity if he boots your computer and finds your vault file.
He cares about the resell value of your camera, iPhone and maybe Macbook.
Edit: I believe OP meant this article:
https://www.schneier.com/blog/archives/2005/06/write_down_yo...
I am considering that I should store the keepass database somewhere else as a backup but not sure exactly where (at least the file server at my work) and also that I should tell the passphrase to somebody (perhaps an old university friend I don't see often; he does not live nearby or work with me) in case of my untimely demise
[edit]: oops, confused osx and ios. I'm not a mac person.
Personally, to me that sort of integration has always seemed like a bad idea. I'm glad that my password database can't talk to my browser programmatically. One less thing to go wrong.
Personally the best feature I'm using KeePassXC for is the auto-reload feature. I sync my kdbx file with Tresorit across couple computers, and the auto-reload feature ensures that I'm always modifying the latest version.
This is something lacking in the original KeePassX.
It takes passwords and makes them "unphishable", because the manager knows what domain you're on.
Of course it's also the largest attack surface. Personally, I think that tradeoff is worth it - assuming competent development.
...of every other extension that you use. That is a very bad assumption to make.
That said, I do use Lastpass myself and in fact have a premium membership.
Anyway, it doesn't necessarily protect from keyloggers for a couple of reasons:
1 - The password to the password database will be recorded by the keylogger. The password database can then be copied by the intruder and then opened using the logged password.
2 - Any password you type in to the password management app can be logged by the keylogger, so browser integration does not help.
2. You usually don't type passwords into the password management app, you generate them.
But yes, generally it's best if you don't get your computer infected with malware in the first place. Obviously if your computer is compromised there'll always be some way for sufficiently advanced malware to steal your password database.
2. Generating passwords would help protect them from keyloggers and is a reason to do so. But as far as I know no password manager prevents people from typing in passwords, and I'm sure a lot of people do for a variety of reasons (from importing old passwords or passwords generated on another device to creating memorable passwords or because the password generation mechanism of the password manager is inadequate in some way, etc).
$ decrypt psswd.txt | grep "mywebservice.com"
Not on Wayland.
> From the text it looks like one of the selling points is integration with apps like browsers so you don't have to copy/paste passwords, as with KeePassX.
Can you provide source please? thank you.
This [1] says the opposite: (quoting from the github issue):
"I removed the milestone for now since we are not sure if we actually want our users to expose their passwords over a network protocol with questionable security record. The security of both KeePassHTTP and KeePassRPC is doubtable and in their current state we would prefer not to have them as part of the main KeePassXC product.
This doesn't mean KeePassXC will never support it, it only means that at the moment we don't have immediate plans and an implementation needs further discussion."
[1] https://github.com/keepassxreboot/keepassxc/issues/88#issuec...
What's ugly about it, besides (I guess) .NET part?
Occasionally, text goes some unreadable colour. And it crashes when I click while holding down Super. And it only follows the GTK colour scheme sometimes; enabling night mode ended up with a beautiful mix of black-on-black-with-white-stripes.
Oh, and widgets like buttons look like a poor man's copy of Windows 95.
Though, to be fair, I now seem to be unable to trigger the above bugs in the latest build, so I guess it's no longer quite as much of an issue.
Yes, all of the above. Plus having several hundreds of mono libs installed for just one app. That app runs 100% of time, but still...
There should be a clear and visible Github banner or big link with the logo.
(My second peeve is that the "type the password" feature types the username and password, making it useless for the more annoying disabled-paste password prompts.)
You can also customize the auto-type on a per site basis. Only the default types U + P. It can be anything you want it to be.
At this point we'd even go so far as just using a good Keepass Client that comes with a comfortable "send encrypted password blob to xy email, than call him and tell him this decryption password"-function.
But I really get where you are coming from, as we are also a SaaS Shop that has to walk that particular line.
A quick google search also turns up Passbolt (https://www.passbolt.com/).
I cannot comment on either of them as I have not used them myself, but I would be interested if anyone has.
I mean, I think having a Web UI for your password manager is fucking insane, but some people like it.
hash(strong_master_pass + site + user)
was a perfect solution...
Self-host Nextcloud and use the Keeweb app with Keepass encrypted databases - https://apps.nextcloud.com/apps/keeweb
Run your own Firefox accounts server, and let FF store all your passwords - https://docs.services.mozilla.com/howtos/run-fxa.html
https://www.passwordstore.org/
I've been using it for a few years. Works for me.
I did find one major annoyance; the forced-use of colours for the "Directory" names. I did some digging and found out that within the program it calls the external program 'tree' for the display.
I edited the file (/usr/local/bin/pass) from: tree -C -l to tree -n -l
It was much easier then I expected, and I was pleased I didn't need to use a Hex-editor.
(in two locations)
You could probably even script a KeePass plugin to automate several of those steps.
But... HackerNews hates LastPass for some reason... still haven't quite figured out why. (= It's a great service.
If someone gets my keychain they own me completely and can quite possibly ruin my life.
(Like mine: https://pave.software/ )
Because it's "dumb file sync" with a number of options, there are also some really interesting options with interesting security footprint trade-offs of their own. Resilio Sync, for instance, originally known as "BitTorrent Sync", supports peer-to-peer sync and more interestingly supports "encrypted peers" where you can have a cloud provider participate that "knows nothing" about what is inside the synced folder but can still share/sync it with your devices that do.
Similarly, if someone develops something crazy like a killer secure and somehow user friendly IPFS sync option tomorrow, you could switch immediately.
Most teams (you'll agree?) have horrible aggregate password management. With every person storing passwords their own way... and only a few people actually having good passwords... isn't security at the organization level really crappy? Here's a real world example... you can have all the security you want on your servers... but if someone in legal still has access to the "Passowrd123" for the AWS account... isn't the team at a disadvantage? Another cliche warning: I need to care about forests, not trees.
At least with LastPass (or whatever other system you can think of that's similar) you can setup "pretty good" team-based policies... share passwords with people who need access (and often not even expose the actual password just access to it so you don't have to change everything in the event of turnover)... set up dead man switches on key accounts (for the hit by the bus scenario we all talk about)...
I know that LastPass has made my life significantly easier since adding it to a number of companies I consult for. I don't know of any security issues first-hand, and I've been using their service for 7 years (personally, and 5 years with teams). I like all the self-hosted options I keep reading about -- glad people are taking security more seriously... but at the end of the day if it's not a comprehensive team-based solution, it's just not something I want to put any stock in. If I can't administer it across a team, if it's just another "personal use only" type option... I don't find any value to it in the workplace.
I would consider that a negative, not a positive, for security.
I keep my KeePass database in my Dropbox, behind 2FA, with the main Dropbox password being a random string stored within the KeePass database. I have KeePass itself stored on my Dropbox as well, so I don't even need to install it to other Windows PCs, simply run the program. And the KeePass2Android app works quite well with this configuration.
Dropbox stores the files locally (on the phone, the kdbx file is marked to be cached and updated offline and I use dropsync)
If someone deletes my kdbx file from my Dropbox account, and I don't realize this in time (before all my devices sync _and_ my backups run out, so very small chance given the nature of the file) I'm in a lot of trouble...
Sometimes I get conflict files in the Dropbox folder. Not often, but a few times over the last year.
On iOS I have to open Dropbox and re-export the database file to see new entries. If I ever want to add or change an entry on mobile I have to manually export the file back into Dropbox. If the database in the app wasn't up-to-date, that will loose any entries added on desktop.
The KeeFox extension for Firefox works but is unreliable, especially on Linux.
Under File Input/Output Connections, check the box labelled:
- Do not ask whether to synchronize or overwrite; force synchronization
It's a program option, rather than a database one, so you need to set it on each computer running KeePass.
"Central server" for Syncthing sounds a bit weird though.
It uses a git repo as storage, gpg encrypts passwords, provides perfect completion and there is an android app. Everything is dead simple and open source.
--------------------
The community has even produced a cross-platform GUI client, an Android app, an iOS app, a Firefox plugin, Chrome plugin, a Windows client, a pretty Python QML app, a nice Go GUI app, an interactive console UI, Alfred integration (1) (2) (3), a dmenu script, OS X integration, git credential integration, and even an emacs package.
--------------------
If this weren't the case, I'd agree :-)
I'm very interested in trying it, just a little worried about it's stability. I guess I'm slightly biased against Electron apps due to some bad experiences.
I'm just worried it will corrupt the database or something.
Have you experienced anything like that?
(Used KeePassX in both contexts previously)
How has been your experience?
Makes me think of DOS software from 1998.
How well specified is the kdbx format? Is there a console client? Is the code readable? Keepass seems to have spawned an entire ecosystem of tools and clients, so I'm curious which of these tools are actualy usable.
It's popular because it's the least common denominator for "cross-platform portable encrypted key-value local storage". The sync support missing is actually a feature for most users. There are much better alternatives when you trust a third-party server.
• You get a proper password generator out of the box.
• Vim's encryption is awful: The current default method is documented to be feasible brute-forceable on a Pentium 133 MHz, and the optional "strong" setting is Blowfish (with an undocumented key-derivation function which is presumably awful as well), which Schneier wanted to have phased out 10 years ago – and by now we're seeing an increasing amount of successful attacks. Do not use VimCrypt if you want your data safe. (If you happen to have GPG set up on all your devices anyway, it can be a decent alternative.)
• Never underestimate convenience when it comes to security. Anything that makes it harder for someone to use their password manager increases the risk of password reuse.
It is nothing more than a script that calls the GnuPG binary and the tree command line utility for displaying a tree of files. It uses your GPG-keypair to encrypt text files. You can add as much info as you like, but by convention the first line of each file is assumed to be the password:
# Generate a 32-character random password.
pass generate sites/news.ycombinator.com 32
# Copy the password to the clipboard; this will ask you to unlock your GPG-key.
pass -c sites/news.ycombinator.com 32
# Find stuff.
pass find news
# Edit the file (e.g., add the username).
pass edit sites/news.ycombinator.com 32
There is a rather sweet feature you can use to share some passwords with someone. You can add a list of GPG key IDs in a file called .gpg-id in any of the subdirectories of your password store, and share that subdirectory using a syncing tool such as SyncThing². My partner and I each have our own password store, but share a directory called 'together' via SyncThing. All passwords stored there are encrypted using both our GPG-keys by pass, whilst our private entries remain encrypted just for our own respective keys.
However the lack of a good mobile client is starting to nag me. There are ones that sort of work but appear to be quite clunky.
I'm looking seriously at Enpass[1] as an alternative since it has good multi-platform support (I use desktop Linux, Windows and Mac plus Android).
0: https://play.google.com/store/apps/details?id=com.zeapo.pwds...
You could do almost all of that with a plain text encrypted file, but KeePass keeps it all neat and sorted.
It's not one multiplatform app, but there's an equivalent format app on every platform.
I hope developing an official Android and iOS app is on the list. There are third party alternatives (such as the one I just mentioned), but if the goal is to be completely cross-platform then let's push those out too.
On the flip side, if the file in question contains an account to a questionable site, could you withhold the key/password to it under the clause against self-incrimination? I.e. you're sued for insulting Donald J. Trump's itty bitty tiny handsy-wandsies, but you also have an account at buymarijuanaonline.com, so you can't give them access to your password database, because you'll incriminate yourself in a different crime.
Why should I move from KeePass2 to this? Prettier GUI under Linux?
R: NO, https://github.com/keepassxreboot/keepassxc/issues/148
> Why should I move from KeePass2 to this?
R: KeePass 1.x and 2.x are the official KeePass releases, KeePassX is a community port in C++ originally built for Linux/Unix but now it includes builts for Windows too. Most people that recommend KeePassX over KeePass 2.x is because they are (.NET/Mono)fobics, plain paranoids or just haters of microsoft. KeePassX and KePassXC aren't improved versions of KeePass they are just ports to C++ (for Linux and Windows) of KeePass.
Not yet, but it's planned for the next release https://github.com/keepassxreboot/keepassxc/issues/148
You can even implement the algorithm yourself if you don't trust the app (which does not require any permissions on Android).
There also is a counter used for hashing. So for a new password you just increment the counter. Remembering the counter for every site sounds too complicated, but you could store that in a file without losing much (any?) protection.
* What happens when you need to change any single one of those passwords? Don't you need to change all of them?
[0]: https://news.ycombinator.com/item?id=12889807
edit: "any single..." includes the master password itself & any of the individual site passwords for that master password.
Note that the algorithm/app I mentioned does use the salt mentioned at the end as a possible solution. The counter problem is still there, but I don't feel it is a big issue.
It is rather worrying that they mention "keypasshttp" as being one of the pull request which was never merged, although it is all about functionality and not security, just to point out a few months after in another issue that users should stop using this plugin because of a vulnerability: https://github.com/keepassxreboot/keepassxc/issues/147#issue...
I don't really know how secure KeepassX is, but this fork doesn't look like it is any more secure, at least for the time being.
[0] https://chrome.google.com/webstore/detail/password-hasher-pl...
* No way to change password without storing things
* No way to handle site-specific rules without storing things
* No way to store auxiliary data (URLs, usernames, etc.)
* No way to see which sites you have accounts on
On the other hand, I can change my Lastpass/Keepass password regularly, denying a cracker access to my accounts in the future.
The security of any password manager, including hashers, is not only how secure it is against attacks, but how secure it is after it has been successfully attacked and how easy it is to recover full security without losing too much data.
Even if the data is encrypted, by using 3rd party services such as DropBox you risk someone trying to crack your passphrase without you noticing.
https://github.com/PixelPaws/KeePass-Desktop https://www.pixel-paws.de/en/
But I agree, they should definitely link to it from the FAQ, since a lot of people are going to look there first.
https://www.ghacks.net/2016/11/22/keepass-audit-no-critical-...
The two primary issues I have with KeeWeb on mobile are:
- Typing my master password every time is tedious on a touchscreen, I really miss LastPass's fingerprint reader integration here.
- The back button closes the app entirely, making me have to enter that tedious password again. This can be fixed be reworking the webapp to use the HTML5 history API, but just hasn't been done yet. Issue here https://github.com/keeweb/keeweb/issues/331
Maybe that fixes the downsides of using KeeWeb on Android.
But I get:
> You have OS X 10.11.6. The application requires OS X 10.12 or later.
??
Edit: Looks like this is a known issue[1].
The last password program I used had often, very often a corrupted database.