News for hackers. Stuff that matters.
Re:Ask HN: Why is WebAuthn so slow to take off? by m-p-3 on Sunday April 23, 2023 @11:01AM (#35676817)
I'm currently looking into deploying hardware keys for some of our users at work (mostly through Microsoft SSO which is FIDO2 passwordless), and one of the roadblock on our end is the inability to define our own minimum requirements for the PIN. Educating our users about the importance of using a secure PIN is indeed a priority, but it would be nice from a security standpoint of we could enforce some policies on our end to at least eliminate the possibility of settings some obviously weak PIN (0000, 1234, etc)
Re:Ask HN: Why is WebAuthn so slow to take off? by shawabawa3 on Sunday April 23, 2023 @11:05AM (#35676848)
Why do you require a pin at all?

The point of hardware keys is to protect against online takeover. Physical access is usually game over either way

Re:Ask HN: Why is WebAuthn so slow to take off? by jameswestgate on Sunday April 23, 2023 @11:37AM (#35677155)
2 factors - something you know and something you have. The device is what you have, the pin is something you know, otherwise anyone can pick up your security key and use it
Re:Ask HN: Why is WebAuthn so slow to take off? by turnsout on Sunday April 23, 2023 @11:37AM (#35677151)
It adds another factor (something you know), which increases the difficulty of an exploit.
Re:Ask HN: Why is WebAuthn so slow to take off? by m-p-3 on Sunday April 23, 2023 @12:24PM (#35677602)
Since Microsoft's implementation of FIDO2 is passwordless, you NEED to use a PIN, which is the "something you know" part, the key being "something you have".

And if the PIN is complex enough, bruteforcing or guessing won't work as I believe the default behavior is to wipe the secure element storage after 8 incorrect attempts (with 3 attempts per key being initialized at a time).

Re:Ask HN: Why is WebAuthn so slow to take off? by crote on Monday April 24, 2023 @06:05AM (#35685594)
Those bruteforce protections aren't really worth a lot in practice. If you have physical access to the device, you will eventually be able to find a way to glitch it - as things like Cellebrite have already proven for the iPhone.
Re:Ask HN: Why is WebAuthn so slow to take off? by m-p-3 on Monday April 24, 2023 @02:21PM (#35691215)
Is there any demonstrated case where someone was able to exfiltrate secrets from a Yubikey secure element?
Re:Ask HN: Why is WebAuthn so slow to take off? by michaelt on Sunday April 23, 2023 @12:39PM (#35677799)
Because Microsoft's implementation is incredibly boneheaded, and doesn't allow the Google-style mechanism of username+password+Yubikey. They only support U2F/Webauthn as an alternative to a password.

I assume Microsoft is hoping to make Windows the main Webauthn provider out there, to tie online identities into the Windows login process for easier tracking/advertising.

Re:Ask HN: Why is WebAuthn so slow to take off? by pQd on Monday April 24, 2023 @01:03AM (#35683845)
Also - thanks to that FIDO2 does not seem to be usable with Microsoft's MS365 services [ Teams, Outlook, Excel etc ] on Android or iOS. there's no way to provide pin for the security key, regardless if it's plugged in via the USB port or used via NFC.

https://learn.microsoft.com/en-us/azure/active-directory/aut...

bummer

Re:Ask HN: Why is WebAuthn so slow to take off? by DANmode on Sunday April 23, 2023 @12:39PM (#35677798)
> it would be nice from a security standpoint of we could enforce some policies on our end to at least eliminate the possibility of settings some obviously weak PIN (0000, 1234, etc)

If your security model requires you retaining that level of control over your user's device security, MDM seems like the only option.

Re:Ask HN: Why is WebAuthn so slow to take off? by techsupporter on Sunday April 23, 2023 @01:28PM (#35678364)
> control over your user's device security, MDM seems like the only option.

I hope that both the person to whom you are replying and their users and bosses remember that once someone has that level of control, it's not really that user's device any more.

Where I work, we debated this sort of setup, but rejected it in favor of NFC Yubikeys largely on privacy grounds. We had several employees (doctors and nurses among them, since we are a medical practice) object to a device management profile, especially because of the remote wipe permission.

Instead, we adopted Yubikeys and an automated provisioning process with a break-glass procedure if someone gets locked out.