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:
https://groups.google.com/a/fidoalliance.org/forum/#!topic/f...
I hope that someone adds support for using U2F with windows accounts.
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.
For laptop and mobile devices, I like the idea of password and biometrics (finger print reader and/or facial recognition).
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.
EDIT: I mean you can't copy credentials off in most cases, like this one. Credentials can be replaced.
[1] https://www.yubico.com/products/services-software/personaliz...
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 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.
Here's Yubico's documentation on Filevault integration: https://www.yubico.com/support/knowledge-base/categories/art...
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).
Someone on Reddit suggested saving a static password to the Yubikey and then entering that at boot time to get around this: https://www.reddit.com/r/AskNetsec/comments/3dpa2q/how_do_yo...?
More explanations on why: https://security.stackexchange.com/questions/71316/how-secur...
And how: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendmen...
A further feature is that you can make the ssl tunnel id part of this as well, that makes it even better.
This is how both UAF and U2F work.
I believe pressing on a button not confirming any transaction details/message is quite a useless action
[1] https://www.yubico.com/products/services-software/open-sourc...
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.