hCaptcha: Profits over People and Fscking Useless
Where
Talks
A New HOPE
Duration
51 min
Examines how hCaptcha's accessible workflow raises privacy concerns and can be automated, and what should replace puzzle CAPTCHAs.
Summary
The talk opens with assistive technology and how CAPTCHAs are meant to separate people from automation, then focuses on hCaptcha, a commercial provider used by a large share of websites. The speaker walks through the standard visual challenge and the accessible alternative, which takes several steps: requesting access by email, clicking a link to set a cookie, and sometimes contacting support for manual approval. The accessible path is noticeably longer than the visual one.
The speaker raises two problems. The first is privacy: because the accessible cookie is tied to the email address used to sign up, it could in principle be linked to a person across sites. The second is security: the accessible flow contains no step that verifies a human, and a scripted browser with a custom mail handler was able to complete the entire process. Rate limits were the only visible countermeasure. The vendor disputed earlier research and said the attempt was likely caught, and both the vendor and Cloudflare declined to treat the report as a security issue through their bug bounty programs.
The talk then looks ahead. hCaptcha is testing a text-based challenge that the speaker expects to be more accessible and privacy-friendly, though it is still in beta. The speaker argues that puzzle CAPTCHAs are losing value and points to hardware-backed and zero-interaction attestation as better options. The takeaway is to design for all users from the start, since separate accessible workflows tend to be slower and less private.
Related talks
Talks·45 min
Covers modern attacks on OAuth, OIDC and JWT authentication flows and how they can be abused.
Talks·23 min
Dylan Ayrey
Shows how re-registering lapsed startup domains lets attackers reach old Google sign-in accounts at other services.
Talks·21 min
Falcon Darkstar Momot
Shows how Postgres roles, stored procedures and in-database JWT checks can limit what SQL injection is able to reach.


