![]() That random-looking ID is in some sense your private key for the site, but suitably encrypted, e.g. If the Security Key cost less than a low-end Yubikey, it has no storage. It says the resulting credentials have random-looking ID 98765431. I picked my own random nonsense XXXZZZ, and a Security Key picked public key ABCDEF, then to prove it knows the private key it signed this message for some.example mentioning XYZXYZXYZ and XXXZZZ and with bitflags it understands enough to know what it's signing. Go for it" and your browser talks to your Security Keys until it finds one that isn't already enrolled, gets that one to sign the appropriate message and sends back, "I am a web browser, I checked that you are some.example. ![]() I also picked this random nonsense XYZXYZXYZ. The relying party says "I am some.example and I want to enroll a Security Key, but, not ones which recognise these huge random-looking IDs that are already enrolled: 12345678, 34561234. To complete enrollment you need to know the corresponding private key, live. Elegant, albeit not suitable for those who fear lock-in. In the short term, their priority is the trick he wrote about most recently - if your Android phone is enrolled as a Security Key with Google, and it's signed in to Google because it's an Android phone, and you use Chrome on a desktop, which is also signed into Google, the Chrome can use Bluetooth to determine if the phone is physically nearby and if so propose to authenticate your desktop Chrome to a remote web site using the Android phone. Adam Langley has written vaguely on this subject before. Google have apparently some plans to address this problem in the medium term. This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub. starting at "Type-2 is a bit less obvious "įor FIDO (and thus WebAuthn, and thus to make this actually practical beyond a toy that only works for some particular Yubico product) the keys are random per enrollment. Bitcoin hierarchical deterministic uses this property to generate wallets that don't need regular backup (all your addresses are derived from one key) and apple's find my network uses something similar. The corresponding private keys can only be derived using the corresponding master ECDSA private key, and the generated public keys can't be linked back to the master ECDCSA public key. You can derive more ECDSA public keys from a single master ECDSA public key. >Each token from the yubikey is not (readily) linkable to the key itself since the underlying secret is opaque and can't be exported Just adding a public key export (on the security token side) and a way to enroll a token by its public key (on the browser/website side) would allow you to enable 2fa without having to make a trip to the safe deposit box (either to store your backup codes, or to fetch your backup token for enrollment). You don't necessarily have to do it crypto wallet style and have the private key be exportable. >Because each hardware key is unique, this is not a feature currently available nor likely to become available.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |