KeePassXC 2.2.0 released with YubiKey and TOTP support(keepassxc.org) |
KeePassXC 2.2.0 released with YubiKey and TOTP support(keepassxc.org) |
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
I was not able to find information on that process on eithers project homepage
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/
* 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
With that said, what's the threat model for the first point? Is localhost interception a serious risk?
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.
Firefox Nightly (version 56) is also supported. The extension will work officially when Mozilla releases build 57.
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.
actively using lastpass now and would like to move to an open source solution I feel like I can trust
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.
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.
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.
The C in the fork title apparently stands for 'community'. It has a lot of support behind it.
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.
[Edit: missing word]
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.
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.
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...
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!
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.
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.
We all know that you shouldn't store your password along with TOTP secrets, or should I make a blog post explaining this?
EDIT: Wait, now it's downloading a second 80 MB container :(
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).
Or maybe I am just procrastinating.
[1] https://itunes.apple.com/us/app/ikeepass/id299697688?mt=8 [2] http://www.keepassdroid.com/
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?
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.
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.
Of course there could be other reasons.
Can anyone tell me how to enable Yubikey?
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.
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.
I wish there was a way to download and associate favicon of all entries in one-click.
QXcbConnection: Could not connect to display
AbortedAt 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.
* 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
Is kdbx format supported by any iPhone app? I'm stuck with KeepassX for that reason.
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-...
The font-size is too small. And I'd prefer a font of my own choice.
So KeepassXC was created as a fork of KeepassX for the linux users who don't want an ugly MOno version of Keepass.
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 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 would try the symlink approach for now. Possibly drop a file next to the DB on your share in case you have to do it again and don't remember.
Refactoring out a core and building multiple UIs would be an interesting and large project.
1) Eto.Forms (https://github.com/picoe/Eto) 2) Avalonia (https://github.com/AvaloniaUI/Avalonia)
Thanks for your attention
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 :)