Correct - just like an evildoer who had your yubikey could generate and save a bunch of yubikey key strings, they could also generate and save a bunch of time-based codes for times in the future by changing the host clock.
You can use a bidirectional challenge-response between the yubikey and a trusted server - that's what U2F does.
But honestly, if an attacker has both your password and physical possession of your 2fa token, it's already game over.
Sure you can! (For yubikey OTP key strings at least) Just have yubikey sign the current time, you're already trusting them to correctly verify the key string.
U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
> Just have yubikey sign the current time, you're already trusting them to correctly verify the key string.
By "them" you presumably mean Yubico not the Yubikey. But these OTP strings are generated by the Yubikey, not by Yubico so there's no way for them to be "signed" in this way. The verification process takes place at authentication so that would just tell you the current time, something you already know, it's useless.
> U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
For WebAuthn (and its predecessor U2F) none of this is correct.
The Relying Party (a web site you want to authenticate to) sends a random challenge. A correct authentication in part signs that challenge, so timestamping is irrelevant here, your answers are either fresh or they're invalid anyway.
Because a physical FIDO authenticator is independent from the computer you are not necessarily "done for" if the computer is compromised, unless you've outfitted your computer with a finger to press keys it cannot, for example, press the button on the key, so there is no way for the compromised computer to obtain signatures from the authenticator with the UP (User Present) bit set, and checking UP in the signed response is part of WebAuthn.
Ok got it and we can't trust the host PC clock or any web based clock via host pc...