[STRML]

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.

[hannibalhorn]

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.

[vrdabomb5717]

With FileVault, the disk won't decrypt until the user enters their login password.

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...?

[Fnoord]

> 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.

[andrewstuart2]

Furthermore, just encrypt your disk with a password concatenated with said static yubikey password and you've got effective MFA.

[jrockway]

I feel like a static password doesn't really count as MFA. Someone can keylog that static password without you knowing.

[andrewstuart2]

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.

[eximius]

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.

[yuhong]

I don't think the BIOS is responsible for this kind of stuff.