The “backup to paper” option is intriguing and I thought at first this would be as a series of QR codes instead of plain text. Will definitely be looking into the CLI options as well.
It runs locally, and if the attacker has that much access, in most scenarios there isn't anything stopping your adversary from just logging your keystrokes and curling the keystore to a remote server.
Hey bscphil, if you'll recall you made a comment about 5 months ago saying that you were playing around with augmenting CarpalX to allow moving around the symbol keys in the model. I am interested in breaking down the model. Is there a place I'd be able to contact you?
AFAIK, that feature has been available for some time (I've been using it, and can confirm that it works flawlessly). You can find it under Tools -> Settings -> General -> File Management -> Automatically save after every change.
Anyone here have opinions on or pointers to the KeePassXC team's rep, creds or track record? I've been using KeePassX partly because Tavis Ormandy said it "looked sane" in a tweet once. How careful is the XC team when adding features?
What kinds of issues are you expecting? Short of actively writing malicious code, I feel like it's hard to get things terribly wrong in an offline password manager when adding a new feature? There are various mitigations you can put in against some potential attacks, but they're generally secondary lines of defense that require other breaches to occur first.
I've seen enough security bugs that I don't want to trust the gut feelings of a non-expert, such as myself. One example I can think of is another password manager that used random numbers incorrectly putting a bias in the random passwords it was generating.
Well something like that is core to the password manager, and already introduced into the product since the beginning. If the maintainer has been competent enough to use (say) a secure RNG until now, he's not going to suddenly mess it up when adding a new feature.
Which is not to say it's a bad idea to get expert vetting for something like this (it's obviously an ultra-safe approach), but it helps to try to put things in context yourself, so that you don't have to find an expert every time you need to make a security decision. In the context of a desktop password manager, there isn't a terrible lot that can go wrong by accident and suddenly result in password exposure once the core product is formed and secure. If it happens, it'd be almost certainly due to a new maintainer coming along and somehow checking in unsafe code, rather than the current maintainers (say) suddenly forgetting they shouldn't call rand() or accidentally saving plaintext passwords on a disk.
If I can't use it on my phone I need to run two different password managers, which is awkward at best. Seems like iOS/Android versions could help a lot with traction.
KeePass saves passwords in a single encrypted file by default. This means that an attacker has no idea about the structure of your entries and usernames.
Plus, it's easier to setup on multiple machines, as you don't need to export/import your PGP keys from your initial machine.
Features and ease of use are subjective to each user.
At least in Debian-based distros, the CLI version ships with the ``keepassxc`` package. I've used it on the odd occasion for password retrieval, and I can confirm it worked for my needs. You can find the manpage to give you some indication of what's possible: http://manpages.ubuntu.com/manpages/eoan/man1/keepassxc-cli....
45 comments
[ 2.4 ms ] story [ 99.8 ms ] threadThere is also keepassxc-cli and kpcli.
KeepassX is no longer maintained.
KeepassXC is maintained and more featured, it's also not dependant on .NET.
KeypassX is a rewrite in C++, using QT. KeypassXC is a fork of KeypassX, as KeypassX was felt to be unmaintained.
KeypassX was abandoned 3 years ago
I've lost a lot from KeepPassX by being spoiled by other auto-saving managers over the majority of this century.
I've seen enough security bugs that I don't want to trust the gut feelings of a non-expert, such as myself. One example I can think of is another password manager that used random numbers incorrectly putting a bias in the random passwords it was generating.
Which is not to say it's a bad idea to get expert vetting for something like this (it's obviously an ultra-safe approach), but it helps to try to put things in context yourself, so that you don't have to find an expert every time you need to make a security decision. In the context of a desktop password manager, there isn't a terrible lot that can go wrong by accident and suddenly result in password exposure once the core product is formed and secure. If it happens, it'd be almost certainly due to a new maintainer coming along and somehow checking in unsafe code, rather than the current maintainers (say) suddenly forgetting they shouldn't call rand() or accidentally saving plaintext passwords on a disk.
In security you are considered incompetent until proven otherwise.
I don't want some random dude to protect my passwords just to realize a year later that he did a "little mistake"
> In security you are considered incompetent until proven otherwise.
And didn't my quote literally say "if the maintainer has been competent enough"?
https://f-droid.org/app/com.kunzisoft.keepass.libre
KeePass saves passwords in a single encrypted file by default. This means that an attacker has no idea about the structure of your entries and usernames.
Plus, it's easier to setup on multiple machines, as you don't need to export/import your PGP keys from your initial machine.
Features and ease of use are subjective to each user.
Important accounts are sharedd between my wife and I, and I back everything up to my NAS regularly.
For work, we're looking in to vault by hashicorp.
https://github.com/keepassxreboot/keepassxc/issues/3675