Google, GitHub, Facebook and Dropbox (and others) all support security keys this way. (Although the Firefox extension appears to stop working with Firefox 57, based on reports.) If you do that, then there's a Firefox extension that implements the same API by running a local binary to handle it. In Chrome you can load an implementation of that API which forwards requests to an internal extension that handles the USB communication. The W3C standard for security keys is still a work in progress, but sites can use them via the FIDO API today. 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 kommentar(er)
