the yubikey thing
Sure, sure, most people are unlikely to be affected by the Yubikey vulnerability in practice. But this attack raises two serious questions:
1. How, exactly, was a failure to implement constant time overlooked for 14 years despite many rounds of certification? This should have been caught.
2. I've frequently hear people claim that Yubikeys are safer than FOSS security keys, because the FOSS keys are not resistant against physical tampering. And sure, to some degree they're not, that's the point - but *is* a Yubikey actually any better, if we're treating this vulnerability as "not a big deal" anyway?
the yubikey thing
@joepie91 it's not a big deal because the potting acts as security in depth--one later failed, but another layer succeeded.
the yubikey thing
@astraluma But... it didn't? The whole point here is that those Yubikeys were successfully exploited, and did not resist that attack
the yubikey thing
@joepie91 while this kind of vulnerability would be a concern for some people/companies using Yubikeys, my money is that the vast majority of Yubikeys produced do not provide access that would make that kind of targeted, high-effort attack worth it.
the yubikey thing
@joepie91 so basically, no, it doesn't matter for 90% of their customers, because it's hard to get into a position to utilize the vulnerability, because of the nature of the attack and there are other protections in place.
the yubikey thing
@astraluma What are you even arguing about? I already explicitly acknowledged this in the very first post, and none of my post is about this
the yubikey thing
@joepie91 exploited in a lab is pretty different from exploited in the wild. No security is perfect--you can only make it more expensive for your adversary, until you hit the point of diminishing returns for your situation.
Even if this was packaged sufficiently to completely remove the technical expertise, it would still be expensive, impossible to do secretly, and necessarily build on a physical attack to get necessary access