Just to be clear, "Yubikey" is a brand of FIDO key. See:
https://fidoalliance.org. You can find other brands which in my experience, are just as functional but often less expensive. I have a yubikey, one from hyperfido and most interesting is the open source 'U2F zero'. All of them work equally well. Unless MS has a non-standard implementation or does not use FIDO, then any FIDO would work.
If we really want to be clear, a Yubikey is a token capable of running applets including, but not limited to FIDO U2F. Other applets commonly used include PIV (pkcs11), OpenPGP, OATH, and Yubi's own OTP applet.
This is the part I don't understand... the Yubikey U2F-only option (1/2 the price) is not listed as supported by this application.
As best I can tell, U2F as it is used today isn't supported by Windows Hello; this is a custom app to support the more advanced Yubikey products.
Apparently there is some v2 of U2F coming down the pike that vendors are waiting for before implementing support; however, I couldn't find much information on how this currently affects Windows Hello:
No it is not. There are yubikeys that implement U2F but Yubikeys also provide more. In this case, their specific U2F key is not listed as requirement. So this is most likely not implemented using U2F.
I have a Yubikey 4, a Plug Up key (pu1.fr/sk though seems to be awol) and a Fidesmo nfc card for my phone. Annoyingly the nfc card works fine with github, but Google says it is not supported on my device.
I hope that someone adds support for using U2F with windows accounts.
I got as far as plugging in the key, and then it said "Windows companion devices are disabled on your system. Contact your system administrator." My computer is a standalone desktop, not connected to a domain.
Edit:
If you run into this problem, here's how to fix it
To modify local security policy
Open the Local Group Policy Editor. To do this, press the Windows key, type R, and then type gpedit.msc.
In the Local Group Policy Editor, from the top level Local Computer Policy, navigate to Computer Configuration > Administrative Templates > Windows Components > Microsoft Secondary Authentication Factor.
In the right pane, click the link to Edit policy setting. (You can also double-click the setting to Allow companion device for secondary authentication.) The default state is Not configured.
In the setting screen, select the option for Enabled, and click OK. If this option is already selected, your policy is set and you can click Cancel.
Exit the Local Group Policy Editor and the Management Console.
And apparently with macOS Sierra it's possible to once again use a Yubikey to configure login on a Mac. I'd missed that news, will have to go dig mine out of the drawer!
How useful is that, really, considering you couldn't possibly use a Yubikey to configure disk encryption? Unless you actually put the unlock key on the Yubikey somehow (I've never heard of someone attempting or succeeding at that), anyone with physical access - which is what this is intended to protect against - could still wreak all kinds of havoc with disk access.
It's certainly easier and may even be safer (in the case of a malfunction, which has happened on OSX) to just use a longer password.
I actually keep my FDE password separate just because I use such a long password it's not practical to type every time my screen locks. The GUI doesn't expose it, but you can encrypt your root volume independent of your user account directly with a "diskutil cs encryptVolume" command. There's a great writeup of it here: https://www.westhoffswelt.de/blog/2014/9/9/osx-full-disk-enc...
I think a physical token for the user account is still good for times when one I'm just away from the desk for a bit, a physical key is better than a short password that someone could probably shoulder surf me typing 50 times a day anyway.
There seems to be some info on using the Yubikey with FDE on their site, it's worth a look but indeed, I'm not sure there's anything that they could do there beyond effectively storing said really long password anyway.
It seems an attacker with physical access still requires your password to unlock the disk. At that point, they'd need the Yubikey to login (assuming they haven't already decrypted the disk and taken your data).
> It seems an attacker with physical access still requires your password to unlock the disk. At that point, they'd need the Yubikey to login (assuming they haven't already decrypted the disk and taken your data).
Its just PAM (pam_yubikey to be precise). If they have physical access they can edit the requirement for Yubikey in PAM.
If there's FDE (FileVault) then I don't know. But I do know the PAM configuration must be read, and is therefore in r/w. It isn't in some kind of security enclave.
If it's long and random enough to be very hard to remember, then it's MFA, in my opinion. A private key (e.g. the one used for TOTP) is nothing more than a quantity of random bits (with specific properties, grant you). I'll give you that the output is certainly reusable for a statically stored key, but you're still adding a second factor that, barring some alternate attack like keylogging, still adds security beyond a password.
I wonder if one of the coreboot/openboot/whatever could implement that. I don't know enough about that part of the stack to know whose responsibility it is to implement it.
I don't like something that I have to plugin. What I greatly prefer is what PacBell gave me as a consultant in the 1990s to access their secure inner networks remotely: a device that would display a new random number every 10 seconds and I would add that number to my password when logging in. I was given the same sort of device at Google in 2013 when I was a consultant there.
For laptop and mobile devices, I like the idea of password and biometrics (finger print reader and/or facial recognition).
A serious problem with biometrics is credential revocation. The best answer I've seen to this is using the biometric to locally unlock some other credential like a certificate that can be revoked. There are other problems that are flashier, like spoofing and liveness, but revocation is a real show-stopper that is frequently ignored.
The new FIDO UAF standard solves exactly this problem, all biometrics are only unlocking a local identifier preferable on Secure Element or in a Trust Zone.
Those are considered deprecated by now. The most important issue with those devices is that they're not secure against phishing.
If you accidentally input your credentials and PIN code in a phishing site, it's game over.
With FIDO tokens, this is impossible - authentication is challenge-response based and tied to the encrypted channel. Your device contains a private key which is used to authenticate. This requires two-way communication, so you have to plug in the device.
Thata the clever bit about FIDO. Part of what unlocks the private key for signing the challenge is somehing called AppId. AppId is automatically captured by your webbrowser (weborigin standard) and passed along. So the authenticator only unlooks if you are on the correct website.
A further feature is that you can make the ssl tunnel id part of this as well, that makes it even better.
If you program your own keys into the Yubi, then you know them and can archive them for reprogramming on another device. You can do this with the Yubi Personalisation tool [1] for a few modes the device supports.
Eh. Hence why I said it like I did. In most cases, the device generates the secrets. And that's how it should be done, it guarantees that they can't be compromised easily (vs if someone compromised wherever you backed up those keys to).
Sure. There are also other instances where the Yubis keys maybe exposed, such as when using their OTP protocol which requires the keys stored in a validation server (either theirs by default, or your own [1])
Pretty much every online service that supports it has a backup 2FA method that you are required to set up. I use Google Authenticator on my phone because my phone doesn't have NFC.
Some of us need to use windows for various reasons. There's a bunch of other stuff you can do to prevent spying, they do not fall within the scope of this post.
