This is a step up from app- or SMS-based two-factor authentication, which only solves password reuse. Indeed, a user cannot be socially engineered into compromising themselves with a security key, short of them physically giving it to the attacker. The point is that security keys are unphishable: a phisher can only get a signature for their appId which, because it's based on the origin, has to be invalid for the real site. Hopefully it'll go away in a future revision for that and other reasons.) (* well, they can almost be stateless, but there's a signature counter in the spec. By having the security keys encrypt state and hand it to the website to store, they can be stateless(*) and robust. By having a physical button, which must be pressed to enroll or sign, operations can't happen without user involvement. Later, when a user wants to log in, the website can send a challenge to the security key, which signs it to prove possession of the corresponding private key. Websites can “enroll” a security key by asking it to generate a public key bound to an “appId” (which is limited by the browser based on the site's origin). Security Keys are (generally) USB-connected hardware fobs that are capable of key generation and oracle signing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |