3 ms·

Thanks you for your response. I'm going to read up more. I wasn't aware this was a feature.

tialaramex 4y ago
Specifically what's going on here in the cheapest FIDO devices is roughly this: On every site where you enroll, random private keys are generated - this ensures you can't be tracked by the keys, your Facebook login and your GitHub login with WebAuthn are not related, so although if both accounts are named "ChikkaChiChi" there are no prizes for guessing it's the same person, WebAuthn does not help prove this. A private key used to prove who you are to say example.com is not stored on the device, instead, it's actually encrypted using a symmetric key that is really your device's sole "identity" the thing that makes it different from the millions of others, and with a unique "Relying Party" ID or RPID which for WebAuthn is basically (SHA256 of) the DNS name using AEAD encryption mode, and then, sent to example.com during your enrolment, along with the associated public key and other data. They can't decrypt it, in fact, they aren't formally told it's encrypted at all, they're just given this huge ID number for your enrolment, and from expensive devices (say, an iPhone) it might not be encrypted at all, it might just really be a huge randomly chosen ID number. Who knows? Not them. But even if they were 100% sure it was encrypted too bad, the only decryption key is baked inside your authenticator which they don't have. What they do have is the public key, which means when you can prove you know that private key (by your device signing a message with it) you must be you. This "I'm (still) me" feature is deliberately all that cheap Security Keys do, out of the box, it's precisely enough to solve the authentication problem, with the minimum cost to privacy. Now, when it's time to log in to example.com, they send back that huge ID. Your browser says OK, any Security Keys that are plugged in, I just got this enrolment ID, from example.com, who can use that to authenticate ? Each authenticator looks at the ID, and tries to decrypt it, knowing their symmetric key and the fact it's for example.com. AEAD mode means the result is either "OK" and the Private Key, which they can then use to sign the "I'm (still) me" proof for WebAuthn and sign you in, or "Bzzt wrong" with no further details and that authenticator tells the browser it didn't match so it must be some other authenticator. This means, if you're actually at example.org instead of example.com the AEAD decryption would fail and your authenticator doesn't even know why this didn't work, as far as it knows, maybe you forgot to plug in the right authenticator? You not only don't send valid credentials for example.com to the wrong site, your devices don't even know what the valid credentials are because they couldn't decrypt the message unless it's the correct site.

Specifically what's going on here in the cheapest FIDO devices is roughly this: On every site where you enroll, random private keys are generated - this ensures you can't be tracked by the keys, your Facebook login and your GitHub login with WebAuthn are not related, so although if both accounts are named "ChikkaChiChi" there are no prizes for guessing it's the same person, WebAuthn does not help prove this. A private key used to prove who you are to say example.com is not stored on the device, instead, it's actually encrypted using a symmetric key that is really your device's sole "identity" the thing that makes it different from the millions of others, and with a unique "Relying Party" ID or RPID which for WebAuthn is basically (SHA256 of) the DNS name using AEAD encryption mode, and then, sent to example.com during your enrolment, along with the associated public key and other data. They can't decrypt it, in fact, they aren't formally told it's encrypted at all, they're just given this huge ID number for your enrolment, and from expensive devices (say, an iPhone) it might not be encrypted at all, it might just really be a huge randomly chosen ID number. Who knows? Not them. But even if they were 100% sure it was encrypted too bad, the only decryption key is baked inside your authenticator which they don't have. What they do have is the public key, which means when you can prove you know that private key (by your device signing a message with it) you must be you. This "I'm (still) me" feature is deliberately all that cheap Security Keys do, out of the box, it's precisely enough to solve the authentication problem, with the minimum cost to privacy. Now, when it's time to log in to example.com, they send back that huge ID. Your browser says OK, any Security Keys that are plugged in, I just got this enrolment ID, from example.com, who can use that to authenticate ? Each authenticator looks at the ID, and tries to decrypt it, knowing their symmetric key and the fact it's for example.com. AEAD mode means the result is either "OK" and the Private Key, which they can then use to sign the "I'm (still) me" proof for WebAuthn and sign you in, or "Bzzt wrong" with no further details and that authenticator tells the browser it didn't match so it must be some other authenticator. This means, if you're actually at example.org instead of example.com the AEAD decryption would fail and your authenticator doesn't even know why this didn't work, as far as it knows, maybe you forgot to plug in the right authenticator? You not only don't send valid credentials for example.com to the wrong site, your devices don't even know what the valid credentials are because they couldn't decrypt the message unless it's the correct site.