TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ending CAPTCHAs: Introducing Cryptographic Attestation of Personhood

114 pointsby jacobwgabout 4 years ago

20 comments

syrrimabout 4 years ago
This isn&#x27;t an attestation of personhood. This is attestation of access to a hardware module with certain properties. These are very different things. Obnoxiously different. Do any of the listed manufacturers implement any sort of rate limiting? If not, then it would be quite easy to set up a farm of yubikeys, and solve captchas for an arbitrarily low rate.<p>Also, what is the cost of a single one of these keys? If it&#x27;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.<p>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 &quot;one computer, one vote&quot;, 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&#x27;t see how this system will proceed any differently.<p>&gt;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.<p>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.<p>&gt;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.<p>We aren&#x27;t, and someone has. The majority of people don&#x27;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&#x27;t add up to anything near 500 years per day of captchas.
评论 #27286936 未加载
评论 #27149117 未加载
评论 #27147093 未加载
EFruitabout 4 years ago
I&#x27;m all for eliminating (re)CAPTCHAs, and I&#x27;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.<p>First, I don&#x27;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&#x2F;ignore features, block certain platforms, give kickbacks, etc.)<p>Second, it&#x27;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...)
评论 #27146534 未加载
评论 #27143873 未加载
motohagiographyabout 4 years ago
Is it accurate that their solution does something like:<p>CloudFlare -&gt; Browser: challenge{...}<p>Browser -&gt; CloudFlare: {sha256((device_public_key)^root_signature), (challenge)__device_priv_signature}<p>CloudFlare -&gt; CA: &quot;get signed public key by hash&quot;<p>CA -&gt; CloudFlare: {(device_public_key)^root_signature}<p>CloudFlare -&gt; self: &quot;verifies hash, decrypts returned challenge&quot;<p>CloudFlare -&gt; Browser: &quot;ok&quot;<p>Where &quot;CA&quot; is some source of device public keys, &quot;^&quot; means signed, and &quot;__&quot; means encrypted.<p>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&#x27;ve described to provide privacy and anonymous attestation.<p>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&#x2F;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.<p>The other piece is that I don&#x27;t know how we verify that FIDO token vendors aggregate their batch keys into cohorts large enough that they provide trustworthy anonymity. Maybe I&#x27;m into the weeds without details, but what this post talks about is a non-trivial problem.
captn3m0about 4 years ago
For Firefox users, trying to anonymize the U2F device results in a failed challenge.<p>So you must keep the checkbox unchecked[0]<p>[0]: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;2ORwgEs.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;2ORwgEs.png</a>
评论 #27144091 未加载
ahecklerabout 4 years ago
I tried their test site just now [0]. After clicking &quot;I am human&quot;, my MacBook prompted me to confirm with my Apple Watch. I double-pressed the side button, but then got this error [1].<p>[0] <a href="https:&#x2F;&#x2F;cloudflarechallenge.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudflarechallenge.com&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;HEGY85&#x2F;Uz3jgdqXXZ" rel="nofollow">https:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;HEGY85&#x2F;Uz3jgdqXXZ</a>
评论 #27141998 未加载
therealunrealabout 4 years ago
While interesting, this sounds like giving the keys to &quot;the internet&quot; to a handful of key manufacturers. There&#x27;s also the cost of the devices, which is significant, making this useful for only a tiny percentage of the world. I&#x27;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?
tomjen3about 4 years ago
Hmm, I remain skeptical. The idea isn&#x27;t terrible on the face of it, but I would want assurances that they can&#x27;t get more knowledge about who I am, including getting any additional information of the key.<p>I don&#x27;t care about assurances that they don&#x27;t do that.<p>The other issue is more practical: few people have such a key (especially when they won&#x27;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.<p>The idea isn&#x27;t bad, but we need to get to a place where bots aren&#x27;t bad and that websites can deal with them.
评论 #27143417 未加载
vlmutoloabout 4 years ago
&gt; 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.<p>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?
评论 #27148382 未加载
评论 #27147690 未加载
评论 #27142657 未加载
kristianpabout 4 years ago
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&#x27;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&#x27;t use the original algorithm, because a bad actor could use an old bitcoin miner to quickly finish the work.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hashcash" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hashcash</a>
jjk166about 4 years ago
This is incredibly dumb. While we&#x27;ve traditionally talked about bots vs humans, this was always just a standin for what we actually cared about: legitimate vs illegitimate operations.<p>If you&#x27;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&#x27;t matter.<p>Conversely, if someone is trying to brute force a PIN, does it matter if it&#x27;s a human typing in combinations or a script entering them at the same rate? Nope.<p>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&#x27;s harder for a human to do these things doesn&#x27;t mean they won&#x27;t.<p>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&#x27;t employ an effective CAPTCHA solver then its effectively an attempt limiter, whereas with such a solver it&#x27;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.<p>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.<p>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&#x27;re talking about an edge case of an edge case of an edge case.
评论 #27171390 未加载
nonameiguessabout 4 years ago
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&#x27;t feel like going and finding it.<p>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.
评论 #27144359 未加载
EVa5I7bHFq9mnYKalmost 4 years ago
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.<p>So ultimately servers should deal with bots on their end. You can rate limit, provide API for bots to pull data etc.
mectagabout 4 years ago
Looks pretty interesting!
Reelixabout 4 years ago
<a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;moving-from-recaptcha-to-hcaptcha&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;moving-from-recaptcha-to-hcaptch...</a><p>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.<p>So don&#x27;t you act all innocent Cloudflare - You were the ones who instigated this!
qshamanabout 4 years ago
I wonder who is going to train Google&#x27;s &quot;AI&quot; now, if this becomes mainstream?
评论 #27143746 未加载
gruezabout 4 years ago
What&#x27;s preventing someone from buying a bunch of u2f keys and using that to spam?
评论 #27149485 未加载
dcooabout 4 years ago
This just sounds like webauthn with extra steps
评论 #27149815 未加载
stfnsnabout 4 years ago
Great news! But it doesn&#x27;t work with MS Edge PIN. It returns this error: unsupported_att_fmt (same as &quot;aheckler&quot;)
yash_gargabout 4 years ago
Interesting!
sebyx07about 4 years ago
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.