KeePassXC 2.2.0 released with YubiKey and TOTP support(keepassxc.org)
keepassxc.org
KeePassXC 2.2.0 released with YubiKey and TOTP support
https://keepassxc.org/blog/2017-06-26-2.2.0-released/
131 comments
I use Command-L to lock, for what it's worth.
Can someone explain how the YubiKey and TOTP support is supposed to work? I can't think of a way those could work with a local password manager like KeePass.
Reading it, it sounds like they use HMAC challenge response for the password to the vault. For that to work, you'd insert yubikey, enter a password, and the password is passed through the yubikey and hashed. The hash is then used as the password to open/lock the vault. That gives you a reasonably strong password for the vault. It does not prevent phishing. Therefore, anyone with the hash and access to the vault can still access all passwords without your knowledge. The TOTP thing sounds like a google authenticator sort of feature.
I'm sticking with zx2c4 pass. It is an assembly of gnupg, git, and pwgen. Trusted open source components. Works with a Yubikey (opensc and gpg-agent) to prevent private key theft via software. QTPass is a nice cross platform gui client. PassFF extension provides excellent browser integration. Android Password Store and OpenKeychain allow pass and yubikey to work on my mobile. Strong 2 factor password storage everywhere I need it.
My biggest problem these days is dealing with sites that don't allow 30+ char passwords with full range of special characters. Almost exclusively, banks.
I'm sticking with zx2c4 pass. It is an assembly of gnupg, git, and pwgen. Trusted open source components. Works with a Yubikey (opensc and gpg-agent) to prevent private key theft via software. QTPass is a nice cross platform gui client. PassFF extension provides excellent browser integration. Android Password Store and OpenKeychain allow pass and yubikey to work on my mobile. Strong 2 factor password storage everywhere I need it.
My biggest problem these days is dealing with sites that don't allow 30+ char passwords with full range of special characters. Almost exclusively, banks.
pass no longer uses pwgen as of version 1.7, by the way (changed in 639c46a342466209e9b0600c2b3574bb44a0ff31).
I think Yubikey can be used to unlock the database
I'm trying the snap package, but I don't think the cli is available this way. I can find the binary in /snap/keepassxc/current/bin, but it has library loading problems.
How is KeePassXC comparing in verification/testing vs the original KeePass2?
I was not able to find information on that process on eithers project homepage
I was not able to find information on that process on eithers project homepage
Nice! Excited for future development of this. I'll have to get a Neo soon to try out these new features.
This is by far the best of the KeePassX* lot, incorporating loads of enhancements which, disappointingly after years of development, never made it into KeePassX 2.x proper, and some 1.x features which simply disappeared in the upgrade.
[Edit: missing word]
[Edit: missing word]
Wow thank you for the kind words! Appreciate the support.
You're welcome, it's a very decent effort. And now I'm sort of shamed into actually contributing. Reporting back as soon as time allows.
Yep we are now switching to advising its use for the human rights defenders and journalists that we work with.
I find it almost better than the original KeePass 2.x program.
I say almost because I'm used to the original interface, but I'm sure after getting used to it, it will supersede it on my systems.
I say almost because I'm used to the original interface, but I'm sure after getting used to it, it will supersede it on my systems.
I'm still waiting for it to arrive in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855173
So there's KeePass, KeePassX, and now KeePassXC? (And two different variants of KeePass that have nothing to do with each other.)
Not that there's anything wrong with that. I'm just curious if KeePassXC is yet another fork, or if it's from the same people who did KeePassX. KeePassX has an excellent security reputation, so it'd suck if an unrelated fork ruined that.
Not that there's anything wrong with that. I'm just curious if KeePassXC is yet another fork, or if it's from the same people who did KeePassX. KeePassX has an excellent security reputation, so it'd suck if an unrelated fork ruined that.
There doesn't seem to be active development on KeePass/KeePassX, hence the KeePassXC fork.
The C in the fork title apparently stands for 'community'. It has a lot of support behind it.
The C in the fork title apparently stands for 'community'. It has a lot of support behind it.
KeePass (the original C# version) appears to actively developed. KeePassX (the C++ rewrite) appears to have slowed down. KeePassXC (the fork of the C++ rewrite) is the one under discussion here.
There are two different variants of KeePass: the Windows version, and a KeePassX precursor.
No active development? I'm using KeePass on Windows (and have been for years) and I've just had a new update pushed (2.36)... Am I missing something?
KeePass is actively maintained, keepassx is the non-mono port for unix and is not being developed actively. Keepasssxc is fork of keepassx.
I believe the idea is to merge XC back to X down the road. Not sure if that goal changed.
KeePass is the original, and also not very cross-platform. KeePassX has gone through several iterations and now represents a fairly stable and low-feature release of KeePass with cross-platform support. KeePassXC is where all the new and exciting features are being integrated into KeePassX while fixing latent bugs and cross-platform issues. Hope that makes sense.
Is there any thought to merging efforts with the original KeePass project? I know it's C# based but with .NET Core being an option now, maybe it doesn't require Mono and could be made cross-platform. Or maybe keep the C++ code and fold it back into the original project?
I just hate to have multiple projects spend resources on what is essentially the same thing. I think there are gains to be had by combining resources together.
I just hate to have multiple projects spend resources on what is essentially the same thing. I think there are gains to be had by combining resources together.
The larger problem on cross-platform KeePass was never Mono directly (aside from the FUD), but rather the WinForms UI. One could blame Mono for not having a visually pleasing implementation of WinForms, although .NET core has nothing at all.
Refactoring out a core and building multiple UIs would be an interesting and large project.
Refactoring out a core and building multiple UIs would be an interesting and large project.
It doesn't necessarily have to be multiple UIs (although that's probably better in the long term) but there are x-platform options like:
1) Eto.Forms (https://github.com/picoe/Eto) 2) Avalonia (https://github.com/AvaloniaUI/Avalonia)
1) Eto.Forms (https://github.com/picoe/Eto) 2) Avalonia (https://github.com/AvaloniaUI/Avalonia)
Previous discussion of this: https://news.ycombinator.com/item?id=13468486
Keepass is actively developed but uses .Net so Linux requires mono. So KeepassX was created to use C++ so Mono is not required but the project is inactive.
So KeepassXC was created as a fork of KeepassX for the linux users who don't want an ugly MOno version of Keepass.
So KeepassXC was created as a fork of KeepassX for the linux users who don't want an ugly MOno version of Keepass.
It also now has CSV importing so you can now import your passwords from LastPass (though you'll have to manually recreate the folder structure).
This release looks great. Unfortunately I had to switch to LastPass to get sharing, real sync support rather than blob syncing in, and also easy usage on mobile.
Decent mobile support is the only thing holding me back from switching. The current 3rd party options are underwhelming.
I just wait for Android O Autofill Framework to arrive. Then mobile password managers will finally be useful.
Really?... The syncing and conflict resolution (or lack thereof) is the true problem for me.
Keepass2Android works great for me syncing over OwnCloud (they have several cloud sync options)
Could be a problem with a shared database though as the entire thing is one blob, changes can't be merged.
Interesting, how will it be better? The Lastpass for Android autofill in both native apps and web is already pretty perfect in my experience, it detects the fields and fills in the login. In the very rare case it doesn't, the notification list will have a one-click entry to force-fill the info.
It's not perfect. It is slow because it uses Android's accessibility service to detect fields.
Ref: https://lastpass.com/support.php?cmd=showfaq&id=8166
Ref: https://lastpass.com/support.php?cmd=showfaq&id=8166
You guys rock! Thank you for your hard work.
BTW the Windows portable version link on your download page is 404ing:
Incorrect URL: https://github.com/keepassxreboot/keepassxc/releases/downloa...
Correct URL: https://github.com/keepassxreboot/keepassxc/releases/downloa...
BTW the Windows portable version link on your download page is 404ing:
Incorrect URL: https://github.com/keepassxreboot/keepassxc/releases/downloa...
Correct URL: https://github.com/keepassxreboot/keepassxc/releases/downloa...
corrected thank you! I also added links to the 32-bit variants.
I see it supports Linux, Windows, and macOS, but are there any Android and iOS apps to open and modifty KeePassXC databases?
If you feel like keeping your kdbx file in Dropbox you may use ikeepass[1] on iOS to load and modify it. For Android there is keepassdroid [2]
[1] https://itunes.apple.com/us/app/ikeepass/id299697688?mt=8 [2] http://www.keepassdroid.com/
[1] https://itunes.apple.com/us/app/ikeepass/id299697688?mt=8 [2] http://www.keepassdroid.com/
I use MiniKeePass on iOS and have been very happy with it.
For standard keepass I use keepass2android and nextcloud for syncing. That said I don't believe it supports any of the fun new stuff from KeepassXC. It does work with NFC and HOTP though. I'd love to use TOTP instead.
Thumbs up for Keepass2Android. Extra two thumbs up since it provides also a version without network capabilities for additional peace of mind, I found that a great touch.
How well does it work for teams? Is there issues for syncing the database if two or more people are using it at the same time?
Works OK for small teams. If a user forgets to close the database then other team members are only able to open it as read-only. My biggest gripe is that you don't know who is holding the write lock. We work around this by using a setting in our keepass client to close the db after a certain amount of time.
As someone using Keepass2 (mono on Linux), can someone knowledgeable briefly tell me (and probably others) why should and why should not I switch to KeePassX?
I'm getting the feeling that this uses the older protocol?
I got a good answer to the above question from desdiv so I'm adding an edit:
Is there a reason to use this (and not use this) in place of KeePass2 on Windows?
I'm getting the feeling that this uses the older protocol?
I got a good answer to the above question from desdiv so I'm adding an edit:
Is there a reason to use this (and not use this) in place of KeePass2 on Windows?
1. Unlocking the database takes much longer than it should. Linux Keepass2 is much slower at unlocking than Windows Keepass2 on the same machine.
2. On Linux, after entering the password the windows disappears, giving no UI feedback during the lengthy unlocking process. When you type the password wrong, it takes even longer for some reason, and there's no tray icon when you type the password wrong, so you'd have to minimize all your windows to find the dialog box all the way in the back.
3. Lacking Unicode support in 2017 is simply unacceptable: https://i.imgur.com/X0T46bY.png
None of this is the fault of the Keepass developers, since all three problems are absent in the Windows build. As far as I can tell the problem lies with Mono.
2. On Linux, after entering the password the windows disappears, giving no UI feedback during the lengthy unlocking process. When you type the password wrong, it takes even longer for some reason, and there's no tray icon when you type the password wrong, so you'd have to minimize all your windows to find the dialog box all the way in the back.
3. Lacking Unicode support in 2017 is simply unacceptable: https://i.imgur.com/X0T46bY.png
None of this is the fault of the Keepass developers, since all three problems are absent in the Windows build. As far as I can tell the problem lies with Mono.
Yeah I just downloaded. This seems like a good native drop-in replacement. Even the menus et all seem to be in the same place.
And Unicode works, yeah!
I have a really old computer and keepass2 opens stuff instantly so I'm guessing I'm probably not using good enough security.
And Unicode works, yeah!
I have a really old computer and keepass2 opens stuff instantly so I'm guessing I'm probably not using good enough security.
It might take slightly longer, sure, but just slightly (instant vs maybe 0.5s at most). Maybe my database isn't big enough (~200 passwords) for this to be annoying, but it's certainly not that bad.
I'll answer part of my own question- this does look like it's compatible with the Keepass protocol 2. So that shouldn't be the reason to stop.
Of course there could be other reasons.
Of course there could be other reasons.
KeePassXC does support the KeePass2 format (i.e., KDBX3). It does not (yet) support the very latest format (KDBX4), but by default KeePass also still uses KDBX3, so both are compatible.
No KDBX 4 support unfortunately.
Has anyone thought of a good redundancy scheme for yubikey?
Physical object authentication is great except physical objects are less durable than brain memory (or at least, if my brain memory is gone then I probably would have no use for the password anyway).
Physical object authentication is great except physical objects are less durable than brain memory (or at least, if my brain memory is gone then I probably would have no use for the password anyway).
Keep 1 key on your keychain, one in a fire vault in the house, and one in the safety-deposit box at the local branch bank office. Most U2F-enabled sites let you register multiple keys. Add new sites with keychain during the day, in the evening add the fire-vault key at home. Once a quarter add the third key from the safety-deposit box.
I am playing with YubiKey storing certificates, then using the certificates like any other GPG setup, so I can have redundancy and revocation. But I have yet to make it dead simple enough to use for real-world application.
Or maybe I am just procrastinating.
Or maybe I am just procrastinating.
Features I like:
1) Download website favicon (no clue how though, tried entering website but didn't see an option to download favicon)
2) Command line interface, no clue again how to use.
1) Download website favicon (no clue how though, tried entering website but didn't see an option to download favicon)
2) Command line interface, no clue again how to use.
For 1) Download favicon option is there inside "icon" menu of a keepass entry. https://keepassxc.org/images/screenshots/macos/screen_003.pn...
I wish there was a way to download and associate favicon of all entries in one-click.
I wish there was a way to download and associate favicon of all entries in one-click.
Okay, issue 254 has documentation on the CLI. Looks like you can't query password if that's what you're after
Indeed, wish there was more documentation on how to use the CLI
Same here. I was hoping to run this completely headlessly but any attempt to run even `keepassxc --help` or `keepassxc --version` results in:
QXcbConnection: Could not connect to display
AbortedCan you open an issue on Github? Thanks
EDIT: I originally created an issue for the wrong repository, and it looks like someone has already made an issue for me: https://github.com/keepassxreboot/keepassxc/issues/668
Thanks for your attention
Thanks for your attention
This is really cool. Here are more feature requests (and for all I know they're already there):
* Optionally display a secret as a QR code
* Generate and validate BIP39-compatible seeds (like Diceware but with a checksum. Many Bitcoin wallets these days accept them)
* Get this into Tails
* Optionally display a secret as a QR code
* Generate and validate BIP39-compatible seeds (like Diceware but with a checksum. Many Bitcoin wallets these days accept them)
* Get this into Tails
Would you be so kind to file a feature request on GitHub? Here it gets lost. Thanks!
Notable features:
1. Unlock using Yubikey
2. TOTP 2FA
3. Diceware password generator
4. ASLR for in-memory security (didn't expect this!)
5. Portable and Single instance mode (I'll have to check this one in detail)
Thanks for your work team!
1. Unlock using Yubikey
2. TOTP 2FA
3. Diceware password generator
4. ASLR for in-memory security (didn't expect this!)
5. Portable and Single instance mode (I'll have to check this one in detail)
Thanks for your work team!
For anyone wondering - the TOTP 2FA is not on the password wallet itself, but that the wallet is able to store the TOTP key, authenticating TOTP involves knowing the key, by which point there's really no value in using it to authenticate the wallet, it'd be a UI-only protection.
However I think storing TOTP keys in your wallet is a bad idea for security - now if someone hacks your machine they get both your password and your TOTP key at the same time. The main advantage of TOTP is that it puts your second form of auth on a separate device, preventing a single point of compromise.
not much malware will exploit this as not many people will use it, but a targeted attack might greatly benefit from something like this.
However I think storing TOTP keys in your wallet is a bad idea for security - now if someone hacks your machine they get both your password and your TOTP key at the same time. The main advantage of TOTP is that it puts your second form of auth on a separate device, preventing a single point of compromise.
not much malware will exploit this as not many people will use it, but a targeted attack might greatly benefit from something like this.
Just to make sure no one gets the wrong impression: You still have a single point of compromise, as having sufficient access to your machine would allow an attacker to do anything from intercepting your TOTP code to stealing your session or just sending requests from your device. U2F doesn't help with this aspect either, it just adds phishing resistance.
The difference lies in the amount of effort an attacker would have to go through. A compromised password manager database including TOTP secrets effectively gives them access to everything at once, whereas any other kind of compromise would require a lot more effort to get everything, and would probably increase the odds of detection.
It's also a good way to hedge against types of compromise where only your password manager is affected, from vulnerable browser extensions (see LastPass, among others) to the possibility of weak crypto (which would be especially devastating for password managers that use centralized online storage) or even backdoors.
The difference lies in the amount of effort an attacker would have to go through. A compromised password manager database including TOTP secrets effectively gives them access to everything at once, whereas any other kind of compromise would require a lot more effort to get everything, and would probably increase the odds of detection.
It's also a good way to hedge against types of compromise where only your password manager is affected, from vulnerable browser extensions (see LastPass, among others) to the possibility of weak crypto (which would be especially devastating for password managers that use centralized online storage) or even backdoors.
Just to make sure no one gets the wrong impression: You should store your TOTP keys in a different KDBX file, locked with a different master password, and maybe even used on a different device/PC.
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
I store them in the same password safe for quite a simple reason; more convenient and less complexity.
I personally see TOTP only as a security against phishing and password stealing attacks. I don't see how a separate database for TOTP secrets improves on that in any way.
The thing is; a Keepass Password is (usually, looking at your password requirements Paypal) fairly secure in of itself, long, random and contains all the good characters.
TOTP is mainly useful when you have weak passwords and enter them into the wrong place, something that Keepass (especially with the Browser Extension) fully prevents. It's just for show and some extra padding.
Though I do use U2F anywhere I can.
I personally see TOTP only as a security against phishing and password stealing attacks. I don't see how a separate database for TOTP secrets improves on that in any way.
The thing is; a Keepass Password is (usually, looking at your password requirements Paypal) fairly secure in of itself, long, random and contains all the good characters.
TOTP is mainly useful when you have weak passwords and enter them into the wrong place, something that Keepass (especially with the Browser Extension) fully prevents. It's just for show and some extra padding.
Though I do use U2F anywhere I can.
>We all know that you shouldn't store your password along with TOTP secrets
https://xkcd.com/1053/
https://xkcd.com/1053/
Still no KDBX 4 support though?
Please consider making it a priority - it looks like someone tried to pull request it but that failed? The older format uses a custom AES-based KDF - and while I don't personally see any major issues with it, I'm much more comfortable with the modern, heavily reviewed Argon2 design used in the KDBX4.
https://github.com/keepassxreboot/keepassxc/issues/148
Please consider making it a priority - it looks like someone tried to pull request it but that failed? The older format uses a custom AES-based KDF - and while I don't personally see any major issues with it, I'm much more comfortable with the modern, heavily reviewed Argon2 design used in the KDBX4.
https://github.com/keepassxreboot/keepassxc/issues/148
That would be me.
I wrote the patch against the original KeePassX which seems to be no longer maintained (?). One of the KeePassXC guys asked me to rebase it over so I did. Then we (they) spent a week or two debating on how to support libargon2 and the newer libgcrypt required for ChaCha20, coming to no resolution, and I just lost any motivation to push for them to merge my patch.
They also disagreed with the way I implemented KDBX 4 (by adding conditionals to the KDBX reader/writer instead of just creating a whole new class — I did this because KeePass did it this way). I agree that it should be separated, but at that point I already gave up on getting them to accept my patch.
The PR is [here](https://github.com/keepassxreboot/keepassxc/pull/399), you can read it, I know I sound rather impatient here. The other PR on updating their Docker to get newer libraries (libargon2 and libgcrypt) is [here](https://github.com/keepassxreboot/keepassxc/pull/419).
I honestly thought someone else would take it up after I gave up to get it in by 2.2 (it's not even a very big patch), but.. I guess not.
Someone with more experience/patience/persistence, please, you can take the patch and rebase it and clean it up to what they want. You'll also need to wait for them to figure out how they want to use the libraries required with their packaging system.
I wrote the patch against the original KeePassX which seems to be no longer maintained (?). One of the KeePassXC guys asked me to rebase it over so I did. Then we (they) spent a week or two debating on how to support libargon2 and the newer libgcrypt required for ChaCha20, coming to no resolution, and I just lost any motivation to push for them to merge my patch.
They also disagreed with the way I implemented KDBX 4 (by adding conditionals to the KDBX reader/writer instead of just creating a whole new class — I did this because KeePass did it this way). I agree that it should be separated, but at that point I already gave up on getting them to accept my patch.
The PR is [here](https://github.com/keepassxreboot/keepassxc/pull/399), you can read it, I know I sound rather impatient here. The other PR on updating their Docker to get newer libraries (libargon2 and libgcrypt) is [here](https://github.com/keepassxreboot/keepassxc/pull/419).
I honestly thought someone else would take it up after I gave up to get it in by 2.2 (it's not even a very big patch), but.. I guess not.
Someone with more experience/patience/persistence, please, you can take the patch and rebase it and clean it up to what they want. You'll also need to wait for them to figure out how they want to use the libraries required with their packaging system.
KDBX4 is a priority indeed, but we only have limited resources. We hoped to get it into 2.2.0, but it just wasn't possible. We really appreciate your patch and will make sure it lands in 2.3.0. It's not forgotten.
> we only have limited resources
I understand, but I'm still disappointed. You all only needed to come to a decision on how you wanted to proceed with supporting the newer libraries required and I would have taken it from there. I'm not sure if you guys have even now come to a decision on that.
And it took a month before someone mentioned they would prefer if the KDBX 4 functionality was separated (and I do agree that it should be).
You could probably merge a similarly-sized patch into the kernel in less time...
I understand, but I'm still disappointed. You all only needed to come to a decision on how you wanted to proceed with supporting the newer libraries required and I would have taken it from there. I'm not sure if you guys have even now come to a decision on that.
And it took a month before someone mentioned they would prefer if the KDBX 4 functionality was separated (and I do agree that it should be).
You could probably merge a similarly-sized patch into the kernel in less time...
I thought we settled on the PPA approach.
Congrats for your work there. It's sad that they asked you to refactor before raising the separated class issue.
Hope somebody cleans it up and adds the PR to Keepassxc. I would but I am not a C++ guy.(only Python guy sadly)
Really good timing for me to self promote. :-) I'm working on improved keepassxc browser extension. Communication between browser and KeePassXC is via NativeClient. You need varjolintu fork of KeePassXC, but eventually it will also support KeePassHTTP protocol too.
My goals currently are: internalization, nicer UI, clean and extensible code base. I already did options page with material-ui and react. Currently working on replacing jquery popup implentation for hyperapp, which appeared here on HN yesterday.
If interested I can send instruction how you can build extentions. I would like to see this as official part of KeePassXC and willing to donate for free. What you guys think?
You can try options UI on https://mauron85.github.io/keepassxc-browser/preview/
My goals currently are: internalization, nicer UI, clean and extensible code base. I already did options page with material-ui and react. Currently working on replacing jquery popup implentation for hyperapp, which appeared here on HN yesterday.
If interested I can send instruction how you can build extentions. I would like to see this as official part of KeePassXC and willing to donate for free. What you guys think?
You can try options UI on https://mauron85.github.io/keepassxc-browser/preview/
A few things to be wary of:
* KeePassHTTP doesn't use authenticated encryption for its protocol and thus is insecure (decrypt password level insecure). Please make sure you don't have this issue.
* Browser integration means there is only some JS code between my unlocked password vault and random websites. Please study findings from Tavis Ormandy and others who found such vulnerabilities in LastPass et al
* KeePassHTTP doesn't use authenticated encryption for its protocol and thus is insecure (decrypt password level insecure). Please make sure you don't have this issue.
* Browser integration means there is only some JS code between my unlocked password vault and random websites. Please study findings from Tavis Ormandy and others who found such vulnerabilities in LastPass et al
Your second point is a great point, and I believe that there should be a user prompt every time something tries to read from the password database over any API.
With that said, what's the threat model for the first point? Is localhost interception a serious risk?
With that said, what's the threat model for the first point? Is localhost interception a serious risk?
As far as I know, localhost can't be intercepted. Except for unintentional mistakes such as binding to 0.0.0.0 instead of 127.0.0.1.
And inevitably there are going to be some tinkerers who'll run it over the network because it suits them.
keepassxc-browser uses libsodium's box method for encrypting the messages. Only public keys are transferred between the extension and KeePassXC. You still need a valid private keys and a nonce for decrypting and encrypting the replies. You can read a more detailed description from the github page.
I have been keeping eye on the vulnerabilities and going to be very careful when it is time for a final release. Currently if there's any vulnerabilities, these are almost identical to chromeIPass' possible vulnerabilities.
I have been keeping eye on the vulnerabilities and going to be very careful when it is time for a final release. Currently if there's any vulnerabilities, these are almost identical to chromeIPass' possible vulnerabilities.
Well, yes, that's the goal. But it's surprisingly easy to mess up. I think the people here are cautioning you not to get overconfident, and to make sure you research the details of the flaws in other systems.
It is easy to mess up, yes. I'm not overconfident, but almost the opposite. Without being totally paranoid, I'm usually pretty certain something important is forgotten. All help is welcome :)
chromeIPass' possible vulnerabilities being?
KeePassXC restricts chromeIPass to localhost, so data should be safe. Still, chromeIPass exchanges encryption keys in base64. Basically that's plain text. These are the only keys used, so technically it's possible to steal those keys (if not localhost). But if someone has permission to read your loopback or local packet traffic, your info is gone..
Other than that, chromeIPass uses quite old libraries and depricated API functions. Those haven't been updated in ages. keepassxc-browser should fix all issues mentioned above :)
Other than that, chromeIPass uses quite old libraries and depricated API functions. Those haven't been updated in ages. keepassxc-browser should fix all issues mentioned above :)
Also, any autofilling is disabled by default.
The official and latest version is always available here:
https://github.com/varjolintu/keepassxc-browser
Firefox Nightly (version 56) is also supported. The extension will work officially when Mozilla releases build 57.
Firefox Nightly (version 56) is also supported. The extension will work officially when Mozilla releases build 57.
Have you considered dual browser extensions as in this paper:
https://arxiv.org/abs/1706.05085
>The prototype Horcrux client, implemented as a Firefox add-on, is split into two components, with code that has access to the user's master's password and any key material isolated into a small auditable component, separate from the complexity of managing the user interface.
https://arxiv.org/abs/1706.05085
>The prototype Horcrux client, implemented as a Firefox add-on, is split into two components, with code that has access to the user's master's password and any key material isolated into a small auditable component, separate from the complexity of managing the user interface.
Interesting idea. Gotta read the paper. Thank you.
Can I talk to you about an idea I have regarding automating authentication extensions? There's no email in your profile, I'm afraid.
awesome will definitely signup to be a beta test when you get it where you want that.
actively using lastpass now and would like to move to an open source solution I feel like I can trust
actively using lastpass now and would like to move to an open source solution I feel like I can trust
You can go fully OSS already. Try https://github.com/pfn/passifox. It is using KeePassXC http protocol. I'am working on it's replacement.
Is there a KeePass fork with support for the new MacBook touch bar?
Storing password and TOTP seed in a single storage goes against the concept of 2FA.
You should store your TOTP keys in a different KDBX file, locked with a different master password, and maybe even used on a different device/PC.
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
Well instead general password without password manager assumes the fact someone remembers that password. (and perhaps reusing that password.) Using password manager (with different password for each service) plus TOTP would serve its purpose. You still have to enter the code, so it still require you to "have" that code somehow which makes it no different than provisioning multiple devices which many 2FA systems won't prevent, perhaps other than hardware TOTP devices.
An official ppa repository for Ubuntu would be great!
There is a link to an unofficial one in your page, but since this is a security app, installing it from some random repo just feels wrong... Thank you for the great work!
Have you tried the snap install ?
Sorry to hijack the thread a bit, but since you're discussing the snap install I thought I'd ask. This is the first snap app I've ever used. I find the file browser for opening the DB won't show anything outside of my $HOME. I assume this is some sort of sandbox feature of snap apps. But I'd like to store my DB on a network mount, so that gets in the way unless I set up symlinks. Is there any way to get this to behave a bit more like a normal desktop program?
The snap is great! Yes, the theming current is not perfect, and I've noticed the longer startup time. But yesterday my RSS reader showed this post (actually, the Github release page a little earlier) and one impatient `sudo snap refresh` later, this new version is installed, direct from the upstream, without any extra repo or PPA that could replace my kernel.
Yes I did that, but the gui looked horrible, as it was not using my themes, colors etc. I then found out that this was a known issue of snap at that time.
keepassxc from snap is starting much longer. at least 5sec diff
[deleted]
Great release!
Is kdbx format supported by any iPhone app? I'm stuck with KeepassX for that reason.
Is kdbx format supported by any iPhone app? I'm stuck with KeepassX for that reason.
Try MiniKeePass.
It works well but has some actions flow to sync your kdbx backups with updated data from the phone and vise versa.
https://itunes.apple.com/us/app/minikeepass-secure-password-...
It works well but has some actions flow to sync your kdbx backups with updated data from the phone and vise versa.
https://itunes.apple.com/us/app/minikeepass-secure-password-...
Anyone knows how should I change the font? I know this seems a minor thing but I'd like this thing to be readable :-).
The font-size is too small. And I'd prefer a font of my own choice.
The font-size is too small. And I'd prefer a font of my own choice.
One thing I like about the KeePassX interface is the ability to search with a hotkey (CTRL+F). Also, this could be done without having the menu bar visible, hitting the hotkey just pulls up the input field.
I use MacPass, which is a good native Mac alternative for KeePass. It supports KeePassHTTP and judging by their github wiki they have recently implemented support for the KDBX4 format.
Well done! It's great to see some progress with open source in this particular area.
At the moment I'm still stuck with [insert_name_of_commercial_proprietary_solution] but would love to switch to a true open source solution with good user experience and reliable mobile support.
I will make a small donation as soon as I get through the flattr waitlist as a small token of appreciation.
At the moment I'm still stuck with [insert_name_of_commercial_proprietary_solution] but would love to switch to a true open source solution with good user experience and reliable mobile support.
I will make a small donation as soon as I get through the flattr waitlist as a small token of appreciation.
The 'lock database' and 'copy password to clipboard' icons are nearly identical (both essentially a padlock) and still adjacent but one in the UI.
I accidentally lock the database far more often than I would like. I know I'm a bit clumsy and a slow to catch on but this one simple change would really make application a lot more useable for us divs.
https://image.ibb.co/k1amA5/kxpc.png