Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement WebAuthn support #6892

Closed
markg85 opened this issue May 9, 2019 · 16 comments · Fixed by #17957
Closed

Implement WebAuthn support #6892

markg85 opened this issue May 9, 2019 · 16 comments · Fixed by #17957
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Milestone

Comments

@markg85
Copy link

markg85 commented May 9, 2019

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

@zeripath zeripath added type/feature Completely new functionality. Can only be merged if feature freeze is not active. issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented labels May 9, 2019
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label May 10, 2019
@lafriks lafriks removed the type/proposal The new feature has not been accepted yet but needs to be discussed first. label May 14, 2019
@e3b0c442
Copy link
Contributor

e3b0c442 commented Jun 13, 2019

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
Copy link
Member

@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
Copy link
Contributor

@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
Copy link
Author

markg85 commented Jun 15, 2019

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
Copy link
Contributor

e3b0c442 commented Jun 15, 2019

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
Copy link
Author

markg85 commented Jun 15, 2019

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
Copy link
Contributor

Sure thing, I had that same confusion myself for awhile. Glad I could enlighten.

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jun 16, 2019
@ghost
Copy link

ghost commented Jul 11, 2019

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
Copy link

Mstrodl commented Jul 30, 2019

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

@markg85
Copy link
Author

markg85 commented Sep 10, 2019

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.

@Mstrodl
Copy link

Mstrodl commented Sep 10, 2019

@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

@e3b0c442
Copy link
Contributor

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

@Semisol
Copy link

Semisol commented Nov 20, 2021

Bumping this because the U2F API seems to be getting deprecated, I got a warning while logging into my gitea server from my browser.

@wxiaoguang wxiaoguang added the issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP label Nov 22, 2021
@wxiaoguang
Copy link
Contributor

As reported that "the U2F API will not be available after February 2022.", so I marked this issue as priority/critical.

@lunny
Copy link
Member

lunny commented Nov 22, 2021

Maybe we have to add this to v1.16

@lunny lunny added this to the 1.16.0 milestone Nov 22, 2021
@james-d-elliott
Copy link

james-d-elliott commented Dec 11, 2021

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.

@lunny lunny mentioned this issue Dec 11, 2021
3 tasks
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants