Implement WebAuthn support

[markg85]

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:

• a new setting to allow the user to login with only a username (no password!)
• implement webauthn to run in that flow

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

[e3b0c442]

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:

1. 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 :)

2. 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.

[jonasfranz]

@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.

[e3b0c442]

@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.

[markg85]

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)

[e3b0c442]

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.

[markg85]

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 :)

[e3b0c442]

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.

[Mstrodl]

@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.