Ending CAPTCHAs: Introducing Cryptographic Attestation of Personhood(blog.cloudflare.com)
blog.cloudflare.com
Ending CAPTCHAs: Introducing Cryptographic Attestation of Personhood
https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/
44 comments
I use a vpn, so I solve like 5 captchas a day, to the cost of ~300 seconds. "500 years a day" means 500 x 365 x 24 x 3600 : 300 = 52mln vpn users. Totally feasible.
> until someone noticed that custom hardware could compute hashes order of magnitude faster than a pc could. I can't see how this system will proceed any differently.
Bitcoin is an open protocol that anyone can implement, so anyone can build and use faster mining hardware.
This is an open protocol, but with the added restriction that the hardware manufacturer needs to be approved by a trusted authority, and there is a cryptographic chain of trust from the device to the manufacturer to the trusted authority.
Someone could design a "bulk attestation device" which has 10,000 distinct device keys in a single device. But the trusted authority probably won't approve it. And if the hardware manufacturer tries to sneak it past them, they can always revoke the certificate. That's why the "specialised mining hardware" strategy that was so successful with Bitcoin may not work here.
Bitcoin is an open protocol that anyone can implement, so anyone can build and use faster mining hardware.
This is an open protocol, but with the added restriction that the hardware manufacturer needs to be approved by a trusted authority, and there is a cryptographic chain of trust from the device to the manufacturer to the trusted authority.
Someone could design a "bulk attestation device" which has 10,000 distinct device keys in a single device. But the trusted authority probably won't approve it. And if the hardware manufacturer tries to sneak it past them, they can always revoke the certificate. That's why the "specialised mining hardware" strategy that was so successful with Bitcoin may not work here.
The price of certified keys is relatively high, which acts a de-facto internet license.
Keep in mind the median yearly household income in the world is $9,733 - meaning your average person will have to dedicate two days pay to just bypass Cloudflare.
Keep in mind the median yearly household income in the world is $9,733 - meaning your average person will have to dedicate two days pay to just bypass Cloudflare.
> Keep in mind the median yearly household income in the world is $9,733 - meaning your average person will have to dedicate two days pay to just bypass Cloudflare.
You just confused households with people (as well as using a figure that is a decade out of date [2013 Gallup based on national data mixed from 2006-2012.])
You just confused households with people (as well as using a figure that is a decade out of date [2013 Gallup based on national data mixed from 2006-2012.])
You are right. I just quickly googled a number. But it is still a substantial price for some people in the US.
I'm all for eliminating (re)CAPTCHAs, and I'm glad someone is working on the problem, but this proposal seems a little iffy on a few fronts, with two main areas of concern.
First, I don't like the idea of having Cloudflare as the sole judge of the trusted key set; a more open model like the CA-Browser forum would be much easier to trust, as it helps reduce perverse incentives (for example, forcing token manufacturers to implement/ignore features, block certain platforms, give kickbacks, etc.)
Second, it's hard to support a proposal where a full deployment would require every person on the internet to buy AT LEAST a new security token (from an Approved™ vendor), which may not even be compatible with their platform, or may be impossible to acquire (because of export restrictions, poverty, someone inventing a cryptocurrency that requires a hardware token to mine...)
First, I don't like the idea of having Cloudflare as the sole judge of the trusted key set; a more open model like the CA-Browser forum would be much easier to trust, as it helps reduce perverse incentives (for example, forcing token manufacturers to implement/ignore features, block certain platforms, give kickbacks, etc.)
Second, it's hard to support a proposal where a full deployment would require every person on the internet to buy AT LEAST a new security token (from an Approved™ vendor), which may not even be compatible with their platform, or may be impossible to acquire (because of export restrictions, poverty, someone inventing a cryptocurrency that requires a hardware token to mine...)
> having Cloudflare as the sole judge of the trusted key set
The article doesn't say so, but the approved vendor list is actually not determined by Cloudflare. They defer to the FIDO Alliance's Metadata Service [0], which maintains a list of certified suppliers.
[0] https://fidoalliance.org/metadata/
The article doesn't say so, but the approved vendor list is actually not determined by Cloudflare. They defer to the FIDO Alliance's Metadata Service [0], which maintains a list of certified suppliers.
[0] https://fidoalliance.org/metadata/
Regarding your second point, this is meant to be a CAPTCHA alternative, not full replacement. Users without access to approved devices should be able to fall back to existing proof of personhood mechanisms. It's good to have options!
Is it accurate that their solution does something like:
CloudFlare -> Browser: challenge{...}
Browser -> CloudFlare: {sha256((device_public_key)^root_signature), (challenge)__device_priv_signature}
CloudFlare -> CA: "get signed public key by hash"
CA -> CloudFlare: {(device_public_key)^root_signature}
CloudFlare -> self: "verifies hash, decrypts returned challenge"
CloudFlare -> Browser: "ok"
Where "CA" is some source of device public keys, "^" means signed, and "__" means encrypted.
I find Alice and Bob stories impenetrable. This is just an HN comment and not a thought through design, but to do the verification, it needs that challenge to bind to the private key on the device, which uniquely identifies it. They need something with more diversification than what I've described to provide privacy and anonymous attestation.
The way they would need to do this with any degree of anonymity would be to use a symmetric key on the device that was both a) derived from a vendor/manufacturer key, and b) the response was diversified by both a KDF on the device, and the challenge. I missed this part in their description.
The other piece is that I don't know how we verify that FIDO token vendors aggregate their batch keys into cohorts large enough that they provide trustworthy anonymity. Maybe I'm into the weeds without details, but what this post talks about is a non-trivial problem.
CloudFlare -> Browser: challenge{...}
Browser -> CloudFlare: {sha256((device_public_key)^root_signature), (challenge)__device_priv_signature}
CloudFlare -> CA: "get signed public key by hash"
CA -> CloudFlare: {(device_public_key)^root_signature}
CloudFlare -> self: "verifies hash, decrypts returned challenge"
CloudFlare -> Browser: "ok"
Where "CA" is some source of device public keys, "^" means signed, and "__" means encrypted.
I find Alice and Bob stories impenetrable. This is just an HN comment and not a thought through design, but to do the verification, it needs that challenge to bind to the private key on the device, which uniquely identifies it. They need something with more diversification than what I've described to provide privacy and anonymous attestation.
The way they would need to do this with any degree of anonymity would be to use a symmetric key on the device that was both a) derived from a vendor/manufacturer key, and b) the response was diversified by both a KDF on the device, and the challenge. I missed this part in their description.
The other piece is that I don't know how we verify that FIDO token vendors aggregate their batch keys into cohorts large enough that they provide trustworthy anonymity. Maybe I'm into the weeds without details, but what this post talks about is a non-trivial problem.
For Firefox users, trying to anonymize the U2F device results in a failed challenge.
So you must keep the checkbox unchecked[0]
[0]: https://i.imgur.com/2ORwgEs.png
So you must keep the checkbox unchecked[0]
[0]: https://i.imgur.com/2ORwgEs.png
Correct. Anonymizing the U2F device hides the device manufacturer information, which is currently required for Cloudflare to verify that the device comes from a trusted vendor.
From the blog post: > Cloudflare asks you for proof and checks that your manufacturer is legitimate.
From the blog post: > Cloudflare asks you for proof and checks that your manufacturer is legitimate.
I tried their test site just now [0]. After clicking "I am human", my MacBook prompted me to confirm with my Apple Watch. I double-pressed the side button, but then got this error [1].
[0] https://cloudflarechallenge.com/
[1] https://d.pr/i/HEGY85/Uz3jgdqXXZ
[0] https://cloudflarechallenge.com/
[1] https://d.pr/i/HEGY85/Uz3jgdqXXZ
It only works with hardware from certain manufacturers, which at the moment does not include Apple:
"While there is a variety of hardware security keys, our initial rollout is limited to a few devices: YubiKeys, which we had the chance to use and test; HyperFIDO keys; and Thetis FIDO U2F keys."
"While there is a variety of hardware security keys, our initial rollout is limited to a few devices: YubiKeys, which we had the chance to use and test; HyperFIDO keys; and Thetis FIDO U2F keys."
Ah, must have missed that, thanks! I guess I just expected it to not even prompt me if it wasn't going to work.
While interesting, this sounds like giving the keys to "the internet" to a handful of key manufacturers. There's also the cost of the devices, which is significant, making this useful for only a tiny percentage of the world. I'm also skeptical about the privacy guarantees; how large would the manufacturer batches have to be to be accepted? and how many people within my geo-ip range have a device from that batch?
Hmm, I remain skeptical. The idea isn't terrible on the face of it, but I would want assurances that they can't get more knowledge about who I am, including getting any additional information of the key.
I don't care about assurances that they don't do that.
The other issue is more practical: few people have such a key (especially when they won't support what is built into computers), and I for one am more likely to solve a captcha, or close the page, than I am to take of my headphones, go to another room and find my jacket to get my fido token.
The idea isn't bad, but we need to get to a place where bots aren't bad and that websites can deal with them.
I don't care about assurances that they don't do that.
The other issue is more practical: few people have such a key (especially when they won't support what is built into computers), and I for one am more likely to solve a captcha, or close the page, than I am to take of my headphones, go to another room and find my jacket to get my fido token.
The idea isn't bad, but we need to get to a place where bots aren't bad and that websites can deal with them.
I'm not sure about Android devices, but iPhones and Apple Watches can act as FIDO devices thanks to their chip's secure enclave.
> We also have to consider the possibility of facing automated button-pressing systems. A drinking bird able to press the capacitive touch sensor could pass the Cryptographic Attestation of Personhood. At best, the bird solving rate matches the time it takes for the hardware to generate an attestation. With our current set of trusted manufacturers, this would be slower than the solving rate of professional CAPTCHA-solving services, while allowing legitimate users to pass through with certainty.
Is it true that most of these FIDO keys try to prevent automation by, for example, requiring someone to activate a button on the device?
Is it true that most of these FIDO keys try to prevent automation by, for example, requiring someone to activate a button on the device?
Most devices require some sort of out-of-band signal to generate an attestation, but this is fairly trivial to bypass if you wanted to automate the process. They used the example of a mechanical Rube Goldberg contraption to press the button, but you could also do it more reliably by connecting a circuit to the touch sensor. I also see no reason why the process couldn't be sped up, at least in aggregate, by using multiple keys and activating them in sequence.
> Is it true that most of these FIDO keys try to prevent automation by, for example, requiring someone to activate a button on the device?
All the security keys I have require a human to be in the loop by pressing a button, but I don't think that's to prevent automation. I think it's to prevent a hacker who has control of your device from being able to use your 2FA token remotely.
> With our current set of trusted manufacturers, this would be slower than the solving rate of professional CAPTCHA-solving services, while allowing legitimate users to pass through with certainty.
Are those solving services automated, or do they just exploit low-paid humans doing mechanical-turk tasks? If it's the latter, I could totally see that changing quickly with a bunch of machines with 50+ port USB hubs filled with security keys.
All the security keys I have require a human to be in the loop by pressing a button, but I don't think that's to prevent automation. I think it's to prevent a hacker who has control of your device from being able to use your 2FA token remotely.
> With our current set of trusted manufacturers, this would be slower than the solving rate of professional CAPTCHA-solving services, while allowing legitimate users to pass through with certainty.
Are those solving services automated, or do they just exploit low-paid humans doing mechanical-turk tasks? If it's the latter, I could totally see that changing quickly with a bunch of machines with 50+ port USB hubs filled with security keys.
Short answer: yes. I don't think they intend to support U2F hardware that lends itself to automation. I doubt any reputable manufacturer even makes these, since it defeats the purpose to begin with.
Why not get the browser to do 10 seconds of cryptographic work, as per the original aim of Hashcash [0] (which was repurposed for bitcoin mining). The user could be presented with a message letting them know what's happening and the ability to bypass it. It would not continue to use cpu once the sufficient work has been done to access the site. You wouldn't use the original algorithm, because a bad actor could use an old bitcoin miner to quickly finish the work.
[0] https://en.wikipedia.org/wiki/Hashcash
[0] https://en.wikipedia.org/wiki/Hashcash
This is incredibly dumb. While we've traditionally talked about bots vs humans, this was always just a standin for what we actually cared about: legitimate vs illegitimate operations.
If you're a business owner selling office supplies, do you really care if an order was placed by a biological human or by an automatic reorder script? No. So long as somebody is going to pay for the order, it doesn't matter.
Conversely, if someone is trying to brute force a PIN, does it matter if it's a human typing in combinations or a script entering them at the same rate? Nope.
The concern about bots is that they can do things repeatedly and quickly. Placing one order is great, placing 10,000 orders is problematic. Brute forcing a 4 digit PIN is tedious for a human, trivial for a machine. But just because a script can potentially be used to abuse a service does not mean there are no legitimate use cases, and just because it's harder for a human to do these things doesn't mean they won't.
When people want to stop bots, what they really want is to limit the rates and attempts of certain actions. CAPTCHAs somewhat achieve this goal - if the adversary doesn't employ an effective CAPTCHA solver then its effectively an attempt limiter, whereas with such a solver it's a rate limiter. However, since the goal of a CAPTCHA is not to effectively limit rates or attempts, it is not a very good limiter - the captcha might kick in on the first attempt, blocking perfectly legitimate scripts, and with a solver the rate limitation may be trivially small, and remain constant. A properly designed system would only kick in after some suspicious activity had been detected, and would progressively become more burdensome as the user strayed further from expected behavior.
This new system may exceed CAPTCHAs at identifying humans, but that is not what we want. An automatic button presser is much easier to implement than a CAPTCHA solver, and whereas the CAPTCHA solver might be broken by a mild change to the CAPTCHA on the backend, the button presser will work so long as the button its pressing does. Thus it is much worse as an attempt limiter. As a rate limiter, they claim it has a longer interval than current solvers, but again more advanced CAPTCHAs are easily possible, and it still suffers from the same limitation as CAPTCHA in that it must remain unobtrusive for legitimate users, so it can not make its rate limitation too large. In short, this is just a more easily defeated and more difficult to improve version of CAPTCHA.
There may be some niche applications where guaranteeing a human user is actually the desired outcome rather than a proxy, and in those cases this key might be a good alternative to CAPTCHAs for the further small minority who have disabilities that make CAPTCHAs difficult to use, yet for whatever reason have no problem accessing and using a physical device. Still you're talking about an edge case of an edge case of an edge case.
If you're a business owner selling office supplies, do you really care if an order was placed by a biological human or by an automatic reorder script? No. So long as somebody is going to pay for the order, it doesn't matter.
Conversely, if someone is trying to brute force a PIN, does it matter if it's a human typing in combinations or a script entering them at the same rate? Nope.
The concern about bots is that they can do things repeatedly and quickly. Placing one order is great, placing 10,000 orders is problematic. Brute forcing a 4 digit PIN is tedious for a human, trivial for a machine. But just because a script can potentially be used to abuse a service does not mean there are no legitimate use cases, and just because it's harder for a human to do these things doesn't mean they won't.
When people want to stop bots, what they really want is to limit the rates and attempts of certain actions. CAPTCHAs somewhat achieve this goal - if the adversary doesn't employ an effective CAPTCHA solver then its effectively an attempt limiter, whereas with such a solver it's a rate limiter. However, since the goal of a CAPTCHA is not to effectively limit rates or attempts, it is not a very good limiter - the captcha might kick in on the first attempt, blocking perfectly legitimate scripts, and with a solver the rate limitation may be trivially small, and remain constant. A properly designed system would only kick in after some suspicious activity had been detected, and would progressively become more burdensome as the user strayed further from expected behavior.
This new system may exceed CAPTCHAs at identifying humans, but that is not what we want. An automatic button presser is much easier to implement than a CAPTCHA solver, and whereas the CAPTCHA solver might be broken by a mild change to the CAPTCHA on the backend, the button presser will work so long as the button its pressing does. Thus it is much worse as an attempt limiter. As a rate limiter, they claim it has a longer interval than current solvers, but again more advanced CAPTCHAs are easily possible, and it still suffers from the same limitation as CAPTCHA in that it must remain unobtrusive for legitimate users, so it can not make its rate limitation too large. In short, this is just a more easily defeated and more difficult to improve version of CAPTCHA.
There may be some niche applications where guaranteeing a human user is actually the desired outcome rather than a proxy, and in those cases this key might be a good alternative to CAPTCHAs for the further small minority who have disabilities that make CAPTCHAs difficult to use, yet for whatever reason have no problem accessing and using a physical device. Still you're talking about an edge case of an edge case of an edge case.
> If you're a business owner selling office supplies, do you really care if an order was placed by a biological human or by an automatic reorder script? No.
Have you heard about scalpers and efforts trying to stop them from buying all GPUs and consoles? You do care in certain cases. Also, you don't want bots attempting to use stolen CCs.
Have you heard about scalpers and efforts trying to stop them from buying all GPUs and consoles? You do care in certain cases. Also, you don't want bots attempting to use stolen CCs.
Any plans to support existing Windows Security authentication methods? I just tried using my fingerprint and got the format not supported error. I have a Yubikey but don't feel like going and finding it.
Also, the potential to just use automated button-pushing devices was mentioned. It would be quite a lot harder to automate scanning of my fingerprint.
Also, the potential to just use automated button-pushing devices was mentioned. It would be quite a lot harder to automate scanning of my fingerprint.
Yes. And other methods supported on both desktop and mobile devices.
Days of CAPTCHA are numbered, as AI capabilities to solve this kind of tasks are quickly approaching human levels. Hardware solutions alone will not work without captcha fallback.
So ultimately servers should deal with bots on their end. You can rate limit, provide API for bots to pull data etc.
So ultimately servers should deal with bots on their end. You can rate limit, provide API for bots to pull data etc.
Looks pretty interesting!
[deleted]
[deleted]
https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptch...
Yea - And they do this since Cloudflare decided to move from a no-click CAPTCHA to one that requires people to click half a dozen images.
So don't you act all innocent Cloudflare - You were the ones who instigated this!
Yea - And they do this since Cloudflare decided to move from a no-click CAPTCHA to one that requires people to click half a dozen images.
So don't you act all innocent Cloudflare - You were the ones who instigated this!
I wonder who is going to train Google's "AI" now, if this becomes mainstream?
Google already started charging for recpatcha for big sites.
https://cloud.google.com/recaptcha-enterprise/pricing
This is one of the reasons Cloudflare jumped to hcaptcha
https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptch...
https://cloud.google.com/recaptcha-enterprise/pricing
This is one of the reasons Cloudflare jumped to hcaptcha
https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptch...
If you read the very article you linked, hCaptcha did the exact same - So they cut a deal.
So they
a.) Moved from a no-click CAPTCHA solution to one that requires you to click images.
b.) Offered a paid solution so you can have your no-click solution back.
Introduce a problem and then introduce a paid-for solution to fix the problem - That's just scummy business practice.
So they
a.) Moved from a no-click CAPTCHA solution to one that requires you to click images.
b.) Offered a paid solution so you can have your no-click solution back.
Introduce a problem and then introduce a paid-for solution to fix the problem - That's just scummy business practice.
What's preventing someone from buying a bunch of u2f keys and using that to spam?
Money. If they were able to open 100,000 fake accounts today, they would only be able to open far fewer if they had to press a button every time.
This just sounds like webauthn with extra steps
> The Cryptographic Attestation of Personhood relies on Web Authentication (WebAuthn) Attestation. This is an API that has been standardized at the W3C and is already implemented in most modern web browsers and operating systems.
That's because it is WebAuthn.
That's because it is WebAuthn.
Great news! But it doesn't work with MS Edge PIN. It returns this error: unsupported_att_fmt (same as "aheckler")
Interesting!
Yubikey monopoly is coming, then again lawsuits or open sourced yubikey like emulation comes, which renders it useless. POW currently is the only way to stop bots.
Also, what is the cost of a single one of these keys? If it's relatively high (say, $50 each), then this would keep out a large portion of the 4 billion people that cloudflare claims to be seeking to help. If relatively low, then it would enable a farm to be run quite cheaply, even with aggressive rate limiting on each key.
So this does not at all prove personhood, it proves access to money. In that sense, it is nearly identical to a proof of work system. The parallels are actually quite amusing. Recall the slogan "one computer, one vote", which was originally applied to bitcoin, until someone noticed that custom hardware could compute hashes order of magnitude faster than a pc could. I can't see how this system will proceed any differently.
>With our current set of trusted manufacturers, this would be slower than the solving rate of professional CAPTCHA-solving services, while allowing legitimate users to pass through with certainty.
They are only considering speed, not price. Here is a captcha system for you: the site sends you a token. You wait K seconds. The token becomes valid. K is an adjustable parameter, so it can be made longer than whatever the time it takes for captcha solving services to work.
>The very idea that we’re all wasting 500 years per day on the Internet — that nobody had revisited the fundamental assumptions of CAPTCHAs since the turn of the century — seemed absurd to us.
We aren't, and someone has. The majority of people don't fill out any captchas, ever. Google, in its great benevolence and wisdom, monitors their browsing habits. If it determines them to be reflective of a human, then when they click the recaptcha button, it will let them through without a hitch. A very small minority of users behave in ways that are suspect, such as by rejecting cookies, resetting their browsing history, or using tor. These are the users that face frequent captchas. Since they are a heavy minority of users, even if they solve ten captchas a day, it doesn't add up to anything near 500 years per day of captchas.