Use of a security key also requires a PIN?
Comments
-
If you saved a PIN during setup on 1Password, then yes
Didnt fill in the PIN at that first prompting. I backed out until I knew more what was happening; hence this thread. I will go back now and set it up shortly. (I might go out for lunch and ponder the choice of this clearly important # ;))
(So it is possible for the devs of 1P to backtrack (from fido2) (thereby not requiring a PIN)?)
0 -
Didnt fill in the PIN at that first prompting. I backed out until I knew more what was happening; hence this thread. I will go back now and set it up?
(So it is possible for the devs of 1P to backtrack (from fido2) (thereby not requiring a PIN)?)
Assuming the flags are set right, a Relying Party can use FIDO2 without requesting a PIN.
0 -
a Relying Party can use FIDO2 without requesting a PIN
Until this happens (if ever), as I said in an earlier post, it would be helpful if 1P Support provided documentation for this "happening". For example there is no reference to it in their video:
On Yubico's site: https://www.yubico.com/works-with-yubikey/catalog/1password/
nor
On 1P's site: https://support.1password.com/security-key/
0 -
I'm ever so grateful you jumped in, @plttn. I was reading more of YubiKey's documentation last night, but it still wasn't clear to me when the PIN prompt would/wouldn't appear and why. You've cleared things up so well, and I sincerely appreciate it. ❤️
So looping back around to your question on why @kaitlyn didn't see the PIN prompt, there's now a couple potential reasons:
- Her Yubikey is not a FIDO2/WebAuthn supporting key, so she would have never seen it.
- Enrolling a FIDO2 key on macOS (unclear which OS she's using) does not prompt for a PIN for some reason.
In response to the above, I've got a YubiKey 5C, and I'm on macOS. The latter would explain why I wasn't seeing the prompt since it sounds like the 5 series does support FIDO2/WebAuthn as long as I'm understanding things correctly. My plan for today was going to be to try it out on Windows using Parallels, but I think you've answered the questions I would have had, @plttn. Thank you so much!
As for noting this in our own documentation, like @jmjm mentioned, I'll reach out to our developers as well as our documentation team and see what their thoughts are. I don't want to unnecessarily confuse users by leaving anything out, but I also don't want to unnecessarily confuse users who don't see the prompt. Luckily, our documentation team is full of rockstars, so I'm sure they'll think of a way to relay the message appropriately.
0 -
No problem @kaitlyn!
Let me just add my +1 for setting the
userVerification
flag on the WebAuthn call to DISCOURAGED (per the documentation I linked earlier) when used in 1Password. With how infrequently the 2FA actually gets used, I could see a disaster scenario where someone using a WebAuthn/FIDO2 supporting key loses their TOTP generator along with access to all devices other than their emergency kit and their Yubikey, and forgets their key PIN since right now other than Microsoft, 1Password is the only service I've seen useuserVerification
at all. That state would mean they've got everything to recover but since they've maybe not entered their Yubikey PIN in months, they're completely locked out of their 1Password account, because of a PIN on their Yubikey they've potentially only entered 10 times in the lifespan of that key.0 -
(Just musing on how many 1P users have opted for using a physical security key as their 2FA)
0 -
Each Security key has its OWN pin. If you have two security keys, the each have a different PIN. (you could configure each security key the SAME PIN if you wanted) The PIN "unlocks" access to the private key on the Security Key and never leaves the machine where the Security Key is inserted. As someone said above, the FIDO2 portion of the YubiKey will have, at most, ONE PIN. ALL FIDO credentials on that key will be secured by the same PIN.
0 -
I have a few different form factor keys (USB C Nano, USB A NFC, Lightning, etc.) That's how I differentiate them. Yubico also has stickers that you can apply to USB A and USB C keychain versions. I have 80's Hairband Red and Black...
0 -
@jmjm and @kaitlyn :
Another Yubikey user here..I have both a 5NFC and a 5ci. I got the PIN prompt and had no idea what to do with it. Unfortunately, it also appears that 1P's use of 2FA is somewhat broken (or I'm not set up properly).I have no idea WHY I'd want a PIN (even after reading all of the above) -- I have several keys, all of which I want to work. These both work flawlessly with Lastpass (no PIN!). As well, because I had to register an APP I also did so (Google Authenticator in my case).
However..despite enforcing 2FA I notice that the Windows App opens without the second factor, the 1P extension on Chrome opens without it as well, after locking...and the only one that required it was the 1P app on my iPhone.
To my way of thinking...1P, no matter where located, no matter whether being unlocked or started....should ENFORCE the 2FA per the setting.
Not sure if the instructions are incorrect or the app is.....(or if I'm just not smart enough to figure it out...)
0 -
@Rural_Tax_Wonk – I'm happy to help make sure 2FA in 1Password isn't broken, but I don't have much of an answer for the YubiKey question. Here's the article I found on YubiKey's site that explains a bit about it. I hope that helps.
My guess is that 1Password for Windows and 1Password X (if that's the extension you're using) aren't actually syncing since you need to re-authenticate your account with MFA now that it's enabled. To test it out, try visiting this link to the 1Password web app and signing into your account that has MFA enabled. Let me know if you're prompted to enter your 2FA code or plug in and touch your YubiKey.
0 -
If you saved a PIN during setup on 1Password, then yes, that PIN will be the PIN for any other Relying Party that wants User Verification
I am the OP and after being asked in that first sign in for a PIN I have never been asked again at 1Password.com.
0 -
I've had the same issue on Windows 10 build 2004 and adding the key to Facebook through Firefox, but it wasn't the browser asking for it, it is Windows Security. I've managed to work around this by disabling the FIDO2 interface on the key using the YubiKey Manager. It now working fine for me.
0 -
@kaitlyn
Did you ask the team about the feedback from @plttn ? Specifically this part:Let me just add my +1 for setting the userVerification flag on the WebAuthn call to DISCOURAGED (per the documentation I linked earlier) when used in 1Password. With how infrequently the 2FA actually gets used, I could see a disaster scenario where someone using a WebAuthn/FIDO2 supporting key loses their TOTP generator along with access to all devices other than their emergency kit and their Yubikey, and forgets their key PIN since right now other than Microsoft, 1Password is the only service I've seen use userVerification at all.
Why is it that 1Password apparently requires a security key PIN by default, if it supports it? At first I thought it was a Windows thing (since it happened on Windows but not Mac), but from what @plttn describes it's also dependent on a flag that is set in the 1Password system?
0 -
Hi, @gandalf_saxe.
Thanks for bringing this up again! I'm sorry we didn't take care of it sooner; it looks like it fell through the cracks somewhere. I took a look at our code and found what I assume is the problem. The code that asks for your security key when you sign in has had
userVerification
set todiscouraged
since the security keys (WebAuthn) feature was first introduced in the web app in June 2019. However, we missed the spot where the security key gets set up for the first time. That seems to match the reports here that the PIN is being requested (in some cases) during setup but not when signing in.Anyway, I've got a fix for this ready to go, so I hope to have that live this week.
Thanks again to everyone involved here!
0 -
Well, hmm, as I was investigating this further, it looks like another dev on my team spoke to Yubico about this already and their recommendation was to request the PIN when registering a new security key, but not when signing in. I don't see that recommendation in their public documentation, though. Given that we're using WebAuthn here as a second factor, this page seems to indicate that PIN should be discouraged in both cases:
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Readiness_Checklist.html
For second factor flows, we recommend setting UV to discourage a PIN prompt.
And below that they call out both the creation options (registration) and request options (signing in). My colleague who implemented this is out today, but I'll check in with him tomorrow and report back.
In any case, at this moment in time, the current behavior is expected. We may change it, though, if it's not clear why it should be different for registration.
ref: dev/b5/b5#8385
0 -
U2F nerd again here:
It looks like there's potentially some undocumented behavior with the way Windows handles Webauthn now that makes
discouraged
fall upwards intopreferred
during a registration action if the security key is FIDO2 capable which is why Yubico recommends requesting the PIN.Using https://webauthn.me/debugger (also be careful with this site, getting keys stuck in a awkward process will end up locking up the entire browser window you're working in, I assume due to some awkward wait/lock bugs), I set
userVerification
todiscouraged
and registered a key with an existing FIDO2 PIN. Windows still asked me for the PIN to register the key with this debugger. When trying to authenticate, I again setuserVerification
todiscouraged
and it happily just wanted a touch of the key, not a PIN. I wiped the FIDO2 applet so that there was no PIN at all, and using the debugger to register withdiscouraged
didn't ask me for the PIN.Where it gets really interesting though is after wiping this and recreating it, services which I know didn't ask me for the PIN previously to add this key now were asking for the PIN when registering (GitHub, Twitter, Facebook) but don't require it when authenticating. Even more strangely though is Google, while using the MS FIDO2 prompt, did not ask for the PIN.
Unless there's some other registration config value that I'm missing, this seems to be Microsoft messing with Webauthn requests on the OS side of things, not anything that can be fixed in JS.
0 -
Just tested on my Android phone (all my accessible and functional devices not running a version of Windows with native FIDO support only have USB-C ports and I've lost all my adapters), setting
userVerification
todiscouraged
works as intended on Android (although that may be a bug as setting it topreferred
doesn't prompt for a PIN, so it's possible Android's U2F implementation isn't aware of how to set PINs given the NFC functionality)0 -
Wow this thread has some life as it started on January 8.
After requiring a PIN to establish my yubikeys for 1password.com I have never been asked for the PIN again when I have had to occasionally (re)authenticate my account. And this includes just a few days ago when having to use NFC to swipe the same Yubikey for my Android phone.
0 -
Looks like Windows is definitely doing something funny and upgrading most (haven't figured out how Google wasn't getting a PIN yet) FIDO2 calls from
discouraged
topreferred
on registration. I disabled the FIDO2 interface on my key, and webauthn.me happily registered it without a PIN even when Windows was the one handling the registration instead of Chrome.I can confirm however the website isn't prompting for the PIN on login at least so I'll take that as a definite win.
0 -
That's really interesting, @plttn. Sounds like the behavior is still pretty undefined, or at least not clearly defined.
In any case, we opted to change the behavior of 1Password when adding (registering) a new security key. As of last week, we set both registration and authentication to
discouraged
.In some cases, a browser would ask you to create a PIN for your security key when adding it to your 1Password account. The app now discourages the browser from making that request. {8385}
Thanks to all who contributed here!
0