3 ms·

The article here ignores the view of the Web that Cloudflare has, which coupled with "something you have" (the U2F keys) makes for a compelling alternative to C

The article here ignores the view of the Web that Cloudflare has, which coupled with "something you have" (the U2F keys) makes for a compelling alternative to CAPTCHAs. Sure, bots can automate keys, but those keys could also be banned just as well. Cloudflare only needs to know which ones are the good keys and track those forever. This means, for every non-bot out there, the CAPTCHAs are as good as gone. The genius of Cloudflare here is that they (ab)use WebAuthn, which can also be implemented on Android and iOS natively. Before you know it, Cloudflare has built an identity platform (where it may not be helpful for KYC) is plenty useful for websites Cloudflare fronts. Imagine never having to bother with user registration and authentication and bots... that's the next extension I see to all of this.

weird-eye-issue 6y ago
They already have that but it's just for internal teams. I used it recently to lockdown Wordpress installations
wfleming 6y ago
Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. It's an interesting trade-off. It seems like batch keys for device attestation was designed to help protect individual privacy (good), but if you can't ban a key without potentially a lot of splash damage when you detect a bad actor, that seems like a very limiting choice.
- tialaramex 6y ago
  The intent of attestation is that a business could decide, OK, we think FooCorp are doing a proper job and we trust their FIDO tokens, but we don't like all these dozens of cheap alternatives. So for our corporate site we'll require FooCorp tokens, and we'll just issue every employee a FooCorp token on our dime. Maybe it could make sense for a bank to do this, sending account holders a special custom Security Key with the bank's branding on it. I personally think that's stupid, but I can imagine it appealing to bank executives and it's not so stupid as to be worse than SMS or TOTP 2FA that banks do today. But it clearly isn't relevant for no-cost services like Facebook or Gmail, and so sure enough you can just tell them you don't want to give them attestation and they work anyway (I don't know if either of them ask, I just reflexively deny attestation if it's requested). It isn't intended to be useful for trying to do stuff like Cloudflare are attempting here. Which doesn't mean Cloudflare can't succeed in their goals, but in the FIDO threat models a "bad actor" would be a whole vendor, maybe some outfit is using fixed long term secret keys inside their Security Key products and they just sell the NSA a list of those keys - you might decide to just refuse all the products from this vendor. Whereas for Cloudflare the "bad actor" they're worried about just buys a half dozen of whatever was cheapest from eBay and then plugs them into a Raspberry Pi. Or, do they? That's the gamble I think Cloudflare is taking. Maybe the value of defeating this intervention is so low that bad guys will not, in fact, build a Raspberry Pi Security Key clicker proxy to make their thing work.
- ignoramous 6y ago
  > Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. You're right. I meant Cloudflare could ban the generated public-key and not the device's public-key itself. Besides, they could also mark the batch as being taken over by bots and increase the level on challenges issued to the batch. Note though, a single secure module can only generate / store so many public-keys. For instance, Yubi Key 5 supports up to 25 keys, though those could be reset to generate a newer set of 25, but repeat registration of a number of keys from a single batch is bound to trigger some statistical anomalies. From Cloudflare's blog about Cryptographic attestation of personhood https://archive.is/4EbER https://archive.is/4EbER > For our challenge, we leverage the WebAuthn registration process. It has been designed to perform multiple authentications, which we do not have a use for. Therefore, we do assign the same constant value to the required username field. It protects users from deanonymization. Currently, the user-name field is constant for all users. I wanted to point out that that they could amend the registration ceremony to register any user in particular.
  - TimWolla 6y ago
    > For instance, Yubi Key 5 supports up to 25 keys This is for resident keys. A YubiKey 5 supports an infinite number of non-resident WebAuthn keys, because the returned key handle will simply be the private key encrypted with a master key stored on the YubiKey. For authentication the service will send the stored key handle back to the YubiKey which then can decrypt it and use the decrypted private key to sign the challenge.
    - deleted 6y ago
      [deleted]
    - ignoramous 6y ago
      TIL. Envelope encryption. Neat. Can WebAuthn keys be (made) a resident key? If so, is that preferred instead? Conversely, what use case is there for resident keys in context of WebAuthn? For example, if there are multiple master keys, can I switch between them per browser / website (assuming the master key itself is a resident key and not burnt into the element)? Thanks.
robalfonso 6y ago
I agree, I saw the author mention for $25k you could have 1000 keys. I immediately though that is not nearly enough. Given the sheer volume they have, they would start putting a picture together very quickly of ip/key/sites. There is no where near enough uniqueness. I also thought the idea of the key exchange being fast was a red herring. That's a bad thing. If I'm them I'm paying attention to how long from prompt to exchange it takes a human to touch the button. On my own setup my key is on my laptop, which is in a dock. I must stand up and tap it over my monitor. It's just a few seconds but it's a) consistent in timing b) not < 1s. Imagine the aggregate timing data they have. Overall they make some good points if you are teeny tiny player and ignore completely the scale cloudflare is operating at.

weird-eye-issue 6y ago

They already have that but it's just for internal teams. I used it recently to lockdown Wordpress installations

wfleming 6y ago

Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. It's an interesting trade-off. It seems like batch keys for device attestation was designed to help protect individual privacy (good), but if you can't ban a key without potentially a lot of splash damage when you detect a bad actor, that seems like a very limiting choice.

tialaramex 6y ago
The intent of attestation is that a business could decide, OK, we think FooCorp are doing a proper job and we trust their FIDO tokens, but we don't like all these dozens of cheap alternatives. So for our corporate site we'll require FooCorp tokens, and we'll just issue every employee a FooCorp token on our dime. Maybe it could make sense for a bank to do this, sending account holders a special custom Security Key with the bank's branding on it. I personally think that's stupid, but I can imagine it appealing to bank executives and it's not so stupid as to be worse than SMS or TOTP 2FA that banks do today. But it clearly isn't relevant for no-cost services like Facebook or Gmail, and so sure enough you can just tell them you don't want to give them attestation and they work anyway (I don't know if either of them ask, I just reflexively deny attestation if it's requested). It isn't intended to be useful for trying to do stuff like Cloudflare are attempting here. Which doesn't mean Cloudflare can't succeed in their goals, but in the FIDO threat models a "bad actor" would be a whole vendor, maybe some outfit is using fixed long term secret keys inside their Security Key products and they just sell the NSA a list of those keys - you might decide to just refuse all the products from this vendor. Whereas for Cloudflare the "bad actor" they're worried about just buys a half dozen of whatever was cheapest from eBay and then plugs them into a Raspberry Pi. Or, do they? That's the gamble I think Cloudflare is taking. Maybe the value of defeating this intervention is so low that bad guys will not, in fact, build a Raspberry Pi Security Key clicker proxy to make their thing work.
ignoramous 6y ago
> Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. You're right. I meant Cloudflare could ban the generated public-key and not the device's public-key itself. Besides, they could also mark the batch as being taken over by bots and increase the level on challenges issued to the batch. Note though, a single secure module can only generate / store so many public-keys. For instance, Yubi Key 5 supports up to 25 keys, though those could be reset to generate a newer set of 25, but repeat registration of a number of keys from a single batch is bound to trigger some statistical anomalies. From Cloudflare's blog about Cryptographic attestation of personhood https://archive.is/4EbER https://archive.is/4EbER > For our challenge, we leverage the WebAuthn registration process. It has been designed to perform multiple authentications, which we do not have a use for. Therefore, we do assign the same constant value to the required username field. It protects users from deanonymization. Currently, the user-name field is constant for all users. I wanted to point out that that they could amend the registration ceremony to register any user in particular.
- TimWolla 6y ago
  > For instance, Yubi Key 5 supports up to 25 keys This is for resident keys. A YubiKey 5 supports an infinite number of non-resident WebAuthn keys, because the returned key handle will simply be the private key encrypted with a master key stored on the YubiKey. For authentication the service will send the stored key handle back to the YubiKey which then can decrypt it and use the decrypted private key to sign the challenge.
  - deleted 6y ago
    [deleted]
  - ignoramous 6y ago
    TIL. Envelope encryption. Neat. Can WebAuthn keys be (made) a resident key? If so, is that preferred instead? Conversely, what use case is there for resident keys in context of WebAuthn? For example, if there are multiple master keys, can I switch between them per browser / website (assuming the master key itself is a resident key and not burnt into the element)? Thanks.

robalfonso 6y ago

I agree, I saw the author mention for $25k you could have 1000 keys. I immediately though that is not nearly enough. Given the sheer volume they have, they would start putting a picture together very quickly of ip/key/sites. There is no where near enough uniqueness. I also thought the idea of the key exchange being fast was a red herring. That's a bad thing. If I'm them I'm paying attention to how long from prompt to exchange it takes a human to touch the button. On my own setup my key is on my laptop, which is in a dock. I must stand up and tap it over my monitor. It's just a few seconds but it's a) consistent in timing b) not < 1s. Imagine the aggregate timing data they have. Overall they make some good points if you are teeny tiny player and ignore completely the scale cloudflare is operating at.