On Security Tokens
Mark Risher of Google extols the virtues of security keys:
I’ll say it again for the people in the back: with Security Keys, instead of the *user* needing to verify the site, the *site* has to prove itself to the key. Good security these days is about human factors; we have to take the onus off of the user as much as we can.
Furthermore, this “proof” from the site to the key is only permitted over close physical proximity (like USB, NFC, or Bluetooth). Unless the phisher is in the same room as the victim, they can’t gain access to the second factor.
This is why I keep using words like “transformative,” “revolutionary,” and “lit” (not so much anymore): SKs basically shrink your threat model from “anyone anywhere in the world who knows your password” to “people in the room with you right now.” Huge!
Cory Doctorow makes a critical point, that the system is only as good as its backup system:
I agree, but there’s an important caveat. Security keys usually have fallback mechanisms—some way to attach a new key to your account for when you lose or destroy your old key. These mechanisms may also rely on security keys, but chances are that they don’t (and somewhere down the line, there’s probably a fallback mechanism that uses SMS, or Google Authenticator, or an email confirmation loop, or a password, or an administrator who can be sweet talked by a social engineer).
So while the insight that traditional 2FA is really “something you know and something else you know, albeit only very recently,” security keys are “Something you know and something you have, which someone else can have, if they know something you know.”
And just because there are vulnerabilities in cell phone-based two-factor authentication systems doesn’t mean that they are useless. They’re still much better than traditional password-only authentication systems.