Fix: passkey login not working anymore

[hiifong]

Quick fix #32595, use authenticator auth flags to login

[james-d-elliott]

Yes, you will need to store the flags. This will break for everyone who doesn't have backup eligible authenticators.

See here for more info: https://www.w3.org/TR/webauthn-3/#sctn-credential-backup

[james-d-elliott]

Looking at the way you're using this we can probably simplify this with tooling from the go-webauthn side, the binary value of the flags is already available so you don't need to convert it, but we can add a convenience method to derive the flags when reconstructing the credential. Let me know if this is preferable?

[wxiaoguang]

we can probably simplify this with tooling from the go-webauthn side, the binary value of the flags is already available so you don't need to convert it, but we can add a convenience method to derive the flags when reconstructing the credential. Let me know if this is preferable?

If there could be a simple and compatible (backward&forward) solution, it definitely helps a lot. Indeed as a library downstream, I think the fewer details the downstream knows, the more robust the system is. Thank you very much!

[james-d-elliott]

Inspect the change in go-webauthn/webauthn#337 and see what you think. I still need to update the docs and will do that time permitting. It's worthwhile to note that I plan on releasing soon but have one other fix I'd like to merge first. It adds an additional field which you should just backup Flags.Raw which can restore the whole of the Flags field with webauthn.NewCredentialFlags()

Also it's worth noting I personally recommend storing the credential attestation (field named Attestation), using json encoding to a TEXT/BYTEA column. I personally also encrypt it in all of my implementations as well as the pub key to avoid database tampering, but depends on your tooling if this is practical.

You don't need to restore it each time, but it will allow you to validate the attestation at a later date if you decide to leverage metadata. I can also provide some fairly decent recommendations on how to handle this, though you can also expect that the recommendations will make their way into the library as well.

[james-d-elliott]

Hmm, get it from protocol.ParseCredentialRequestResponse => parsedResponse.Response.AuthenticatorData.Flags, is it right?

That's correct.

[wxiaoguang]

Thank you for your help, finally I think I somewhat could understand the details now.

Now we have 2 commits:

• c5a32f4 revert unnecessary changes and make some necessary preparations, not that important
• 5eeac46 !!the key change!! use the default authenticator flags when login, also added some comments there

I think we could resolve the problem now (the same behavior as webauthn 0.10), and leave the database migration to another PR (or if it doesn't really cause security problem, maybe we could just keep using the authenticator auth flags without really storing them?)

[hiifong]

@wxiaoguang Still can't use passkey to login to Gitea.

Screen-2024-11-26-214951.mp4

[wxiaoguang]

Confirmed that 555577e "fixes" the problem.

[DorianCoding]

On version 1.23.1, Bitwarden does not detect the passkey on first login page but does after logging succesfully as 2FA. Maybe some connection is broken between the two. The website runs on https://

No passkey found when "logging with passkey":

However it works after login as 2FA

Thanks.

[wxiaoguang]

On version 1.23.1, Bitwarden does not detect the passkey on first login page but does after logging succesfully as 2FA. Maybe some connection is broken between the two. The website runs on https://

No passkey found when "logging with passkey":
However it works after login as 2FA
Thanks.

The initial passkey support was add by " Add Passkey login support #31504 " (I haven't carefully looked into the details), @anbraten do you have some ideas?

[DorianCoding]

On version 1.23.1, Bitwarden does not detect the passkey on first login page but does after logging succesfully as 2FA. Maybe some connection is broken between the two. The website runs on https://
No passkey found when "logging with passkey":
However it works after login as 2FA
Thanks.

The initial passkey support was add by " Add Passkey login support #31504 " (I haven't carefully looked into the details), @anbraten do you have some ideas?

Thanks for your quick answer.

The difference is on logging:

{"publicKey":{"challenge":"4KXVvpzyv7f98AIIWAyYDD6g9M0sBfxpz9Yo5bUDY9c","timeout":120000,"rpId":"xxxxxxx","userVerification":"discouraged"}}

And on 2FA

{"publicKey":{"challenge":"IxjvbxQipwKAIimB-ZRNrUz-iGDNWrK1zDSUSSm__RA","timeout":120000,"rpId":"xxxxxx","allowCredentials":[{"type":"public-key","id":"K2cxLFxKS8ONfdJP5ePZnQ"}],"userVerification":"discouraged"}}

Probably one solution would be to put userVerification to "preferred", at least for one sign-in (which is safer btw). It seems also it might cause some password managers to hide some keys.

NB: changing the code did not work. However removing old passkey and putting new one with "preferred" works so maybe there was a glitch or preferred is needed...