Windows asks for key PIN, native Linux does not about windows-fido-bridge HOT 7 CLOSED

Just tried it on a native Linux machine with the same YubiKey I tested on Windows and it did request a PIN before requiring me to touch the sensor:

mgbowen@seattle:~$ sudo ssh-keygen -t ecdsa-sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
Enter file in which to save the key (/root/.ssh/id_ecdsa_sk):
# ...

Interestingly, it didn't allow me to do that without being root, but I assume that's because I need to set up some udev rule or something to grant a specific user group access to the key's HID device.

I'll close this then, let me know if you run into any other issues.

from windows-fido-bridge.

Some background: the WebAuthn standard allows the "relying party" (in this case, OpenSSH/windows-fido-bridge) to optionally request that the security key performs "user verification", which can include a variety of possibilities; in the case of your security key (and the YubiKeys I own), that means providing a PIN to the security key before a credential is generated. If the RP doesn't request user verification, the WebAuthn standard requires that the security key instead perform a "test of user presence", which for our security keys means physically touching a sensor on the key itself.

Likely what's happening is I'm not explicitly setting dwUserVerificationRequirement when making a credential or when getting an assertion (i.e. during a login) and Windows is defaulting to requiring user verification, which is why you get a PIN prompt. Also, OpenSSH passes in flags where it tells its SK middleware if it wants user verification or a test of user presence as well, but right now, windows-fido-bridge just ignores them. Best as I can tell from reading its source, OpenSSH only ever explicitly asks its SK middleware for a test of user presence, which is why it doesn't ask you for a PIN when you use it in Linux (though that doesn't necessarily mean you may never be asked for a PIN, something I assume depends on the security key you use).

The fix is to pay attention to the flags from OpenSSH and set the appropriate options in Windows' API accordingly. I'll find some time within the next few days to test it out and make a fix. Thanks for reporting the issue!

from windows-fido-bridge.

Thanks for the background information, that helps a lot in understanding why this happens!

from windows-fido-bridge.

Could you rebuild with the latest commit and try again? On my system, logging into a remote machine now only requires touching the security key, though creating an SSH key still requires entering a PIN if the key is set up with one, which seems to be enforced by either Windows or the security key itself.

from windows-fido-bridge.

Latest commit works great!

And same here, it asks for PIN only when creating a new SSH key, which I suppose is understandable and done rarely enough anyways that it's fine. I can't remember if baremetal Linux required a PIN to create keys when I last used it, I would check but can't right now.

from windows-fido-bridge.

@mgbowen Sorry to hijack this issue to ask this question but this got me thinking.

Does all this mean that even if a resident key is created with the user verification flag, there is nothing requiring user verification on subsequent uses of that resident key?

I'm asking because I was considering using a resident key so that I could avoid having to copy it from computer to computer but wanted to have it be protected by a PIN so that it would not be compromised in case of theft.

What's stopping an attacker from writing their own fido-bridge that unsets the uv flag and using the resident key to log into a server?

I'm having a hard time finding information on the subject.

from windows-fido-bridge.

Disregard, I should have read further, I was looking everywhere except your own README.

from windows-fido-bridge.