Closed markg85 closed 2 years ago
As I mentioned in the referring issue, I'd be interested in taking a crack at this, at least as far as implementing the existing second-factor flow on WebAuthn, which would obviously lay the groundwork for the additional passwordless flow.
There are a couple of ways that we could go about this. The question is, do we want to replace U2F with WebAuthn, or have them coexist for a bit?
At issue is backward compatibility. The appid extension for WebAuthn allows existing credentials to be made compatible with WebAuthn, so that we do not need to have users reregister their tokens; however, new credentials created with WebAuthn will be incompatible with the legacy JavaScript APIs.
So we can either:
Replace U2F with WebAuthn outright. The existing credentials can be pulled forward, but users of Chrome 41-66 and Firefox 47-59 (who had manually switched on the u2f flag) would no longer be able to authenticate with their tokens. Per caniuse.com, this would amount to about 2.5% of overall web users today, and I'm guessing far less in our demographic. Those versions of the browsers are no longer supported by their respective vendors--FireFox 52 ESR ended support in September 2018. That said, that's not a decision I can make myself :)
Run U2F alongside WebAuthn until that slice of the web gets small enough that consensus says we no longer need to support them. This would involve running two sets of registration/validation endpoints (though I hope we could use a common model) and basically checking for navigator.credentials
API in the browser and falling back to the existing implementation if that does not exist. This would eliminate the loss of functionality for any user except for the hopefully-rare case where somebody would register their token in a WebAuthn-supporting browser and then try to authenticate on a browser only supporting the legacy U2F implementation. This would come at the cost of increased code and complexity.
Once this is done and we have CTAP1 tokens authenticating successfully, then the flow for CTAP2 tokens could be designed.
@e3b0c442 I think option 1 is more feasible as you argued. Do you want to send a pull request to add WebAuthN? If you need help with the existing u2f implementation, please feel free to contact me since I've implemented it the first time.
@jonasfranz Yeah, I'd like to start working on it as long as it isn't urgent for some reason; I'm still familiarizing myself with the gitea codebase, plus day job and all that. If that's not an issue, I'll open a draft PR and work against that.
Correct me if i'm wrong, but do you actually mean replacing U2F with WebAuthn? Aka, after you've implemented that there would be no more way to login with U2F + any of those authenticators out there? *
If the above is correct, then i think the wise thing to do is - sadly - go for your option 2. The reason being that logging in with webauthn on your desktop browser really isn't neatly working just yet. Yes, you can use the Krypton authenticator + extension on browsers which makes your phone the authenticator for desktop sites. That works neatly, but figuring out that you need to use that is really not common knowledge yet. As far as i know, there is no other authenticator besides Krypton that allows you to authenticate. For that reason alone, WebAuthn really is still in a bit of an enthusiast area at the moment.
For me personally, i'd kick U2F out right away and go with WebAuthn :) but in general.. i think it might be the best thing to have them both for the time being.
[*] = the 6 digit verification token the authenticator provides, not the webauthn support the some provide (like Google Authenticator)
Yes, replacing U2F with WebAuthn, because WebAuthn is backward compatible with U2F.
It seems that you might confusing WebAuthn with the difference between FIDO2 and U2F. WebAuthn supports two token communication protocols: CTAP1 and CTAP2. CTAP1 is literally U2F renamed; CTAP2 is for the newer FIDO2 devices that support passwordless 1FA, like the Yubikey 5 and the Krypton software authenticator you're referring to.
So, what we are talking about here is replacing the hacky U2F implementations (and they are hacky, since there's no W3C standard here; note the referenced bug where the vendored implementation uses user-agent strings to determine support and I note Chrome's lack of window.u2f
) with WebAuthn+CTAP1 2nd-factor flow. You are right that CTAP2 is likely not ready for prime time, but WebAuthn+CTAP1 should be working in everything that U2F works in, minus the versions of the browsers listed above that had U2F support before WebAuthn was standardized.
If, as we are building and testing we do find issues, then yes, we may need to implement a fallback, but that is not an idea option due to the possibility of needing to support separate data models due to the fact that credentials created with WebAuthn cannot be used with U2F APIs.
Yes, replacing U2F with WebAuthn, because WebAuthn is backward compatible with U2F.
It seems that you might confusing WebAuthn with the difference between FIDO2 and U2F. WebAuthn supports two token communication protocols: CTAP1 and CTAP2. CTAP1 is literally U2F renamed; CTAP2 is for the newer FIDO2 devices that support passwordless 1FA, like the Yubikey 5 and the Krypton software authenticator you're referring to.
So, what we are talking about here is replacing the hacky U2F implementations (and they are hacky, since there's no W3C standard here; note the referenced bug where the vendored implementation uses user-agent strings to determine support and I note Chrome's lack of
window.u2f
) with WebAuthn+CTAP1 2nd-factor flow. You are right that CTAP2 is likely not ready for prime time, but WebAuthn+CTAP1 should be working in everything that U2F works in, minus the versions of the browsers listed above that had U2F support before WebAuthn was standardized.If, as we are building and testing we do find issues, then yes, we may need to implement a fallback, but that is not an idea option due to the possibility of needing to support separate data models due to the fact that credentials created with WebAuthn cannot be used with U2F APIs.
Thank you very much for explaining that! I wasn't aware WebAuthn had that. In that case, by all means, go for your option 1!
Note: I'm merely a user for Gitea. You should probably value the opinion of your fellow Gitea devs more then my opinion here :)
Sure thing, I had that same confusion myself for awhile. Glad I could enlighten.
Would the support of WebAuthn allow for the use of Duo prompt for 2FA? (https://guide.duo.com/prompt)
I assume so since the WebAuthn lib is maintained by duo labs, but I don't know enough about these standards to know for sure.
@christianpage I don't think so, afaik Duo is a (proprietary) 2fa solution that allows for several different authentication methods (e.g. push notification, text, webauthn, google authenticator, etc) to be implemented easily.
Hi,
Just curious if there is an update on this.
Another thing i'm curious about is how to go about adding multiple devices to one account? By that i mean i authenticate with one device and a few years later (say due to hardware upgrades, new phone, whatever) i want to authenticate with another device. How do you make a secure logic that my then new device is actually from me? This all with WebAuthn/CTAP2.
I'm curious as you cannot verify it by giving my device a challenge since it would be whole new hardware thus it will end up with a different public key. The challenge you "could" give with my old key would not work on the new one, obviously.
This scenario isn't that far fetched... If i only have one CTAP2 device, say my phone, and i accidentally let it fall and doesn't turn on anymore (been there, done that, hated it) then how do you verify that a new device is actually me.
Or would this work in a way that i need one device to authenticate another device as actually mine? So for instance, if i have one device authenticated i can add a second device but have to confirm on that first device that the second one is mine. I can see how this would work but it does put some quite substantial burden on WebAuthn if this were the way to go as you'd always need to have at least 2 devices to authenticate anywhere in case one breaks.
@markg85 most likely the only requirement for adding a device would be logging in (like every other platform I know of which has support for multiple devices) and don't forget that TOTP is always available to use as a fallback
Just curious if there is an update on this.
I'd quote John Lennon here, if it were not stating the obvious.
I'm still planning on working on this, but life has gotten in the way this summer. I don't want to be a blocker, so if somebody else wants to work this implementation, please feel free. Regardless, I'll keep picking away at it as I have time, and if somebody else is done faster than me, it was still a good learning experience :)
Bumping this because the U2F API seems to be getting deprecated, I got a warning while logging into my gitea server from my browser.
As reported that "the U2F API will not be available after February 2022.", so I marked this issue as priority/critical
.
Maybe we have to add this to v1.16
As a note if you're interested, Authelia is maintaining a branch of github.com/duo-labs/webauthn at github.com/authelia/webauthn. We've merged a majority of the open PR's and various other changes after reviewing them. You can replace the duo-labs version with a simple replace. The key part is that we have implemented the appid extension which allows backwards compat with U2F key handles and public keys (provided you add a column/field denoting their attestation type as fido-u2f
).
See this line: https://github.com/authelia/authelia/pull/2707/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R118
Which points to: https://github.com/authelia/webauthn/pull/7/commits/f8df6d828fd40055cd3777486cc7d534a48f01c8
You can also see the PR in that line linked above which is where we've implemented everything. Additionally we are implementing this in our typescript react app in a fairly easy to understand way I believe.
Edit: If you have questions feel free to reach out, I'm just learning about the protocol for myself, but I may know the answer none the less.
WebAuthn gained some traction in recent months. Specifically now that most android devices are certified security keys, webauthn becomes very appealing!
What needs to happen for this is:
As Gitea is written in Go, you're golden when it comes to WebAuthn support. There is a quite well documented library: https://github.com/duo-labs/webauthn
Now you need a biometric device to login (for example to https://webauthn.io/). It's easy on android, you just place your finger on the fingerprint sensor and you're in. On the desktop this is a bit more tricky. As this is all still quite new, i guess more applications will pop up that allow you to use your phone's biometric sensors to login on desktop sites.. But one way to go about this now is by using the Krypton authenticator app. It allows you to do exactly that.
So, can we have this please? :)
Best regards, Mark