Keepassxc: Feature Request: Integration with the Web Authentication API

Created on 20 Apr 2018  Â·  16Comments  Â·  Source: keepassxreboot/keepassxc

Recently, the W3C finalized their Candidate Recommendation for the Web Authentication Standard, a new browser feature that allows sites to request user authentication through a standardized API.

Implementation is currently underway in Chrome, Firefox, and Edge.

Once this standard starts being implemented by sites, I'd like to be able to use KeePassXC as an Authenticator for it, so that I can store my Web Authentication private keys in the same place my existing legacy passwords are stored, and keep them synchronized across all my devices.

While it might still be too early to begin working on a concrete implementation (available documentation for the Web Authentication API is still a little sparse, outside of the standards document itself), I figured it can't hurt to start looking into this now so we're prepared when the time comes.

Would integration with the Web Authentication API be a feature worth supporting?

new feature Browser integration

Most helpful comment

I already have a test branch that can intercept WebAuthn create/get on the test page. For now it doesn't do anything yet, but I'll try to improve things when I have some time. But it's certainly possible to do.

All 16 comments

Looks very promising!

I will definitely keep an eye on this!

Web Authentication is supported in the latest Google Chrome release (67)

So far I haven't found a way to use a software as an Authenticator, and I assume it will not be possible unless you have a idiot-proof way to emulate a USB device.

It's possible official support for third-party software authenticators could be coming in the future (though I've heard no news about anything like that yet); but even in the absence of that couldn't you use a browser extension to directly intercept calls to the Web Authentication API and implement it that way?

Until we have some real-world examples of sites using the Web Authentication API as a password replacement, it's hard to say what the best way to approach the problem is.

FYI, the Web Authentication standard is now officially a W3C recommendation: https://www.w3.org/TR/2019/REC-webauthn-1-20190304/

It's possible to implement an Authenticator via a browser extension by intercepting calls to the Web Authentication API and returning an appropriate response to the web page. Krypton is a good example of how this can be done: https://github.com/kryptco/kr-u2f/blob/192af059419501bb702148ae5301f042c9859447/src/inject_webauthn_chromium.ts (Note the linked code is not FOSS so we can't copy it directly, but it does provide a general idea of how this can be done.)

WebAuthn can be tested at https://webauthn.org/ or https://webauthn.io/

Cool, thank you for keeping on top of this

But is not WebAuthn intended to be used as a 2FA method? Not a replacement for passwords…

And if you use WebAuthn as a password replacement, you cannot really use any 2FA anymore? Or what should one do, if one then wants to use a hardware key as 2FA WebAuthn e.g.?

WebAuthn is replacing human generated passwords with challenge response keys. These _CAN_ be stored on hardware tokens, but certainly not necessary or desired in most cases. I for one hate carrying a token around with me.

. I for one hate carrying a token around with me.

But you notice this is a security advantage?

So let's think again about 2FA: You want:

  • something you know
  • something you have
  • something you are

(all and/or connected, 2 factors for two-factor-authenticatiion obviously)

So "traditionally" passwords are the first (you know them) and things like a TOTP app (on a different mobile phone) or hardware tokens are "what you have".
With KeePassXC, it would only be "what you know"…

Respectively it would all be on one device (being one factor in the end). If that is compromised, all your logins are compromised. Without it, you have currently have to compromise two devices (KeePass DB and on one phone or even a hardware key), which is obviously more secure…

Security is all about _choice_. I did not say this is replacing 2FA or that it is stronger than 2FA. The vast majority of the world has no idea what 2FA is, nor do they care. I have lowered my personal risk on those accounts that I have deemed are "high value" by using true 2FA. For accounts that are not high value, I would very much like to have the convenience of using WebAuth without a hardware token.

You can make your own choices. That's the beautiful thing about KeePassXC!

. I for one hate carrying a token around with me.

But you notice this is a security advantage?

So let's think again about 2FA: You want:

* something you know

* something you have

* something you are

(all and/or connected, 2 factors for two-factor-authenticatiion obviously)

So "traditionally" passwords are the first (you know them) and things like a TOTP app (on a different mobile phone) or hardware tokens are "what you have".
With KeePassXC, it would only be "what you know"…

Respectively it would all be on one device (being one factor in the end). If that is compromised, all your logins are compromised. Without it, you have currently have to compromise two devices (KeePass DB and on one phone or even a hardware key), which is obviously more secure…

It is understandable and I agree with you. But as @droidmonkey said, it's a trade-off between security vs. convenience. And it is perfectly assumed in the FAQ:

We believe that storing both together [passwords and TOTP secrets] can still be more secure than not using 2FA at all, but to maximize the security gain from using 2FA, you should always store TOTP secrets in a separate database, secured with a different password, possibly even on a different computer.

You have the choice to store your 2FA (TOTP or FIDO2/CTAP) secrets in the same database.

Nothing says you could not generate a WebAuthn response from more than one factor (I haven't read the spec, but it's quite flexible and generic from what I've heard).
As used today, 2FA is largely a mitigation of weak passwords and not of break ins into your machine. If your PC is taken over, then taking over your phone as well is usually rather easy (or vice versa). You only get the full advantage of 2FA if at least one of your tokens never comes in contact with the other (like e.g. a YubiKey or a dedicated hardware token generator that is hard to impossible to penetrate with malware).

If your PC is taken over, then taking over your phone as well is usually rather easy (or vice versa).

I would totally challenge that assumption…


But yes, it can be totally useful as an optional feature. I totally think users can trade-off things there. (We have the same thing with TOTP tokens in KeePassXC.)

What I am just not sure about is, whether the WebAuthn spec actually intends this implementation? Does it take the thing into account (for security implications or so) or is the spec rather intended for 2FA?

It's up to the website to support 2FA, I don't see any reason why WebAuthn can't be used as one factor. Similarly to how Google implements 2FA login it would just be WebAuthn on one page then TOTP or something else on the next.

I already have a test branch that can intercept WebAuthn create/get on the test page. For now it doesn't do anything yet, but I'll try to improve things when I have some time. But it's certainly possible to do.

Was this page helpful?
0 / 5 - 0 ratings