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

Password requirement for WebAuthn external key (like YubiKey) should be optional #89

Closed
krambrock opened this issue Feb 22, 2024 · 8 comments
Assignees
Labels
enhancement New feature or request needs testing (on unstable) If the feature exists, but isnt yet released

Comments

@krambrock
Copy link

When using a YubiKey for WebAuthn MFA, a password is mandatory for the key. Other platforms and applications (such as Google and Proxmox) permit the use of the key without a password, which, in my opinion, is more practical as a second factor of authentication.

I've briefly looked through the code in your repository at https://github.com/NHAS/webauthn but couldn't pinpoint the exact location where this configuration might be modified. Could you provide some guidance on how to adjust this setting?

@NHAS
Copy link
Owner

NHAS commented Feb 22, 2024

I don't know what you mean by this. My webauthn implementation doesn't support or require a password.

@krambrock
Copy link
Author

Thanks for the fast answer.

This happens to me when I register a YubiKey with google or proxmox:
registerForGoogle

And this happens to me when I register it to wag:
registerForWag

As I said I browsed a bit through the code and I did not find anything. It is not super-important, I would just not use external keys then with wag.

@NHAS
Copy link
Owner

NHAS commented Feb 22, 2024

This looks like it's using the windows hello based webauthn instead of the physical security key.

I use webauthn with a u2f key and I do not get a prompt like this.

@krambrock
Copy link
Author

Good to know that it works for you, I'll check my setup then. It is definitely the key, though. I entered a password once, and the key had a password at that time.

@krambrock
Copy link
Author

I found a detailed destription why this is happening in mastodon (mastodon/mastodon#16545) together with a two-line change in Ruby (mastodon/mastodon@11a7861).

The summary: If the userVerification is to preferred (probably the default) and you use a fido2 key that support a pin in windows then the pin it is requested and you cannot avoid setting it. This is also descibed in https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html.

The solution would be to set it to discouraged, like in the mastodon commit. Changes could maybe be done in this two places:

Maybe I'll look into it myself when I got a Go setup running.

@NHAS NHAS added the enhancement New feature or request label Feb 24, 2024
@NHAS
Copy link
Owner

NHAS commented Feb 24, 2024

Sweet! Thanks for finding that, I'll have a look at setting it in wag.

Just as there is on-going work this change might not be released for quite some time

@NHAS NHAS self-assigned this Feb 24, 2024
@krambrock
Copy link
Author

krambrock commented Feb 27, 2024

I found a workaround with a YubiKey (other keys will probably provide something simelar). Just disable the Fido2 functionallity of your key before registering it and leave the u2f function activated:
disableFido2

After you registered you can re-enable the Fido2 functionallity. I think it still makes sense to change the setting but with this workaround it might be low-priority.

@NHAS
Copy link
Owner

NHAS commented Apr 26, 2024

This is now on unstable, thanks for the excellent recommendation and resources!

@NHAS NHAS added the needs testing (on unstable) If the feature exists, but isnt yet released label Apr 26, 2024
@NHAS NHAS closed this as completed in f466a9a May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs testing (on unstable) If the feature exists, but isnt yet released
Projects
None yet
Development

No branches or pull requests

2 participants