Could not read your security key

[grisu48]

Gitea Version

1.16.0

Git Version

2.30.2

Operating System

openSUSE Leap 15.3

How are you running Gitea?

podman container using gitea/gitea:latest

Database

PostgreSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

When logging in with my Yubikey, I get a "Could not read your security key" error (See screenshot). The Yubikey works with other services, and was working with gitea before.

I haven't logged in in a while, so I'm not sure, which version was the last where it was working.

Logging in via TOTP works fine. Removing the Yubikeys from my account and re-adding them solved the issue.

Screenshots

[veita]

Probably same problem as here:

+ wget https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64
--2022-01-31 08:10:20--  https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 104.21.60.7, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 105989848 (101M) [application/octet-stream]
Saving to: ‘gitea-1.16.0-linux-amd64’

gitea-1.16.0-linux-amd64           100%[================================================================>] 101.08M  1.31MB/s    in 87s     

2022-01-31 08:11:47 (1.16 MB/s) - ‘gitea-1.16.0-linux-amd64’ saved [105989848/105989848]

++ wget https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64.asc
--2022-01-31 08:11:47--  https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64.asc
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 104.21.60.7, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 833 [text/plain]
Saving to: ‘gitea-1.16.0-linux-amd64.asc’

gitea-1.16.0-linux-amd64.asc       100%[================================================================>]     833  --.-KB/s    in 0s      

2022-01-31 08:11:47 (8.41 MB/s) - ‘gitea-1.16.0-linux-amd64.asc’ saved [833/833]

++ gpg --verify gitea-1.16.0-linux-amd64.asc gitea-1.16.0-linux-amd64
gpg: Signature made Sun 30 Jan 2022 06:58:00 PM UTC
gpg:                using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: BAD signature from "Teabot <teabot@gitea.io>" [unknown]
+ echo 'ERROR Bad signature'
ERROR Bad signature
+ exit 1

[techknowlogick]

@veita this is an issue re:webauthn validation, and not gpg validation of the binaries

[veita]

That's weird. The same script works with 1.15.10:

++ wget https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64
--2022-01-31 09:07:21--  https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 172.67.186.211, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 106478136 (102M) [application/octet-stream]
Saving to: ‘gitea-1.15.10-linux-amd64’

gitea-1.15.10-linux-amd64          100%[================================================================>] 101.54M  1.25MB/s    in 90s     

2022-01-31 09:08:51 (1.13 MB/s) - ‘gitea-1.15.10-linux-amd64’ saved [106478136/106478136]

++ wget https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64.asc
--2022-01-31 09:08:51--  https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64.asc
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3034::ac43:bad3, 2606:4700:3036::6815:3c07, 172.67.186.211, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3034::ac43:bad3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 833 [text/plain]
Saving to: ‘gitea-1.15.10-linux-amd64.asc’

gitea-1.15.10-linux-amd64.asc      100%[================================================================>]     833  --.-KB/s    in 0s      

2022-01-31 09:08:51 (8.76 MB/s) - ‘gitea-1.15.10-linux-amd64.asc’ saved [833/833]

++ gpg --verify gitea-1.15.10-linux-amd64.asc gitea-1.15.10-linux-amd64
gpg: Signature made Fri 14 Jan 2022 08:27:46 PM UTC
gpg:                using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: Good signature from "Teabot <teabot@gitea.io>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7C9E 6815 2594 6888 62D6  2AF6 2D9A E806 EC15 92E2
     Subkey fingerprint: CC64 B1DB 67AB BEEC AB24  B645 5FC3 4632 9753 F4B0
+ echo 'OK Signature verified'
OK Signature verified

[zeripath]

@grisu48 "An attempt was made to use an object that is not, or is no longer, usable" likely relates to the different format of the "relying party" ID that webauthn expects as compared to U2F.

You would need to set the [u2f] APP_ID to match the old APP_ID format that the security keys would work for. Gitea guesses this is the ROOT_URL but depending on your set-up this may not be correct. TRUSTED_FACETS are not supported in webauthn so if you were depending on these you will need to choose the most important one of these and set it as the APP_ID.

[grisu48]

Thank you, that makes sense. Indeed, I don't see a [u2f] section in my app.ini and it is likely that this was introduced after my initial setup. Will update my configuration accordingly.

Feel free to close this issue, with this explanation is seems to be more likely the result of an old config, rather than an actual bug. Thanks for looking into this!

---

Anyone who ends up here after me, checkout the u2f section of the app.ini.

[mscherer]

I also faced the same issue. I had a [u2f] and I tried to change it to the ROOT_URL value without luck. So in the end, I also just remove the keys and added them back.

[zeripath]

Gitea should be setting the app_id to the root_url already so if it's not working by default the app_id would need to be slightly different from the root_url.

If you do manage to work out what it should be in those cases please do report back - it may well be that we can create a better default.

[grisu48]

I just added the following configuration to my app.ini and it worked without complains:

[U2F]
APP_ID = https://<<REDACTED>>        # Replace with public endpoint hostname

After a service restart, I could login with the already registered Yubikeys. By setting this value explicitly I assume we're safe from here onwards, especially to mitigate the possibility that gitea at some point confuses the internal hostname/ip with the external one (I'm thinking about containers).

[zeripath]

Setting the app_id correctly should work for previously registered u2f keys but if your root_url is not your real root URL you may have difficulties registering new keys.

Webauthn requires that the relying party knows its own endpoint. Now this could be taken from the requests requestURI and perhaps in future once context passing is done we could do that but at present Gitea expects the root URL to be right.

[mscherer]

In my case, the forge is behind a apache httpd proxy, and that was the U2F config (out of ansible, just expanded {{ vhost }} to forge.example.org)

[U2F]

APP_ID = https://forge.example.org/
TRUSTED_FACETS = https://forge.example.org

And ROOT_URL:

ROOT_URL = https:/forge.example.org

I tried moving ROOT_URL to APP_ID, didn't work.

I guess I mixed the / in the wrong order or something in the past. Now, I removed the U2F section. I have backups of my DB, so I can take a look if there is more information needed. The host is using the upstream binaries, tested with firefox and 2 yubikey nano.

[beedaddy]

I also faced this issue after updating to 1.16.0. APP_ID, ROOT_URL etc. was already set correctly. I could login via smartphone (2FA-app) and then I could remove and re-add my Nitrokey FIDO2 usb stick. Afterwards, 2FA with the stick worked again.

[svenseeberg]

Some of our users face the same issue. I triggered the 2FA reset in the user management for them, however the users are still seeing the error above.

I had to manually remove the old entries from the webauthn_credential SQL table.

[zeripath]

Honestly - I'd need to know more about your situations in order to advise.

1. Are these users all using a particular browser? My suspicion is that Firefox has completely switched off U2F support including fallback support.
2. Are your ROOT_URLs correct? WebAuthn requires that the ROOT_URL exactly matches the real application url?
3. Were you using TRUSTED_FACETS previously?

WebAuthn is not a one-to-one replacement for U2F. We've tried to migrate and provide backwards support but it relies on the browsers allowing that backwards support.

[grisu48]

Honestly - I'd need to know more about your situations in order to advise.

1. Are these users all using a particular browser? My suspicion is that Firefox has completely switched off U2F support including fallback support.

I had this issue in Firefox and in Chromium.

2. Are your ROOT_URLs correct? WebAuthn requires that the ROOT_URL exactly matches the real application url?

Yes, the ROOT_URL is pointing to the publicly available https link of the instance. I didn't had the [U2F] block when the issue arised.

3. Were you using TRUSTED_FACETS previously?

Nope and I could not find this setting in my app.ini (not can i find it on https://docs.gitea.io/en-us/config-cheat-sheet/)

WebAuthn is not a one-to-one replacement for U2F. We've tried to migrate and provide backwards support but it relies on the browsers allowing that backwards support.