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