Skip to content

DEF CON 34 talks are here: 354 talks, summarized and searchable.

Browse DEF CON 34

hCaptcha: Profits over People and Fscking Useless

Steven Presser

AppSecTalks51 minIntermediateOpen on YouTube ↗

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·21 min

  • ShmooCon
  • AppSec
  • Date: Jan 2025
  • Location: DC

Falcon Darkstar Momot

Shows how Postgres roles, stored procedures and in-database JWT checks can limit what SQL injection is able to reach.

appsecvulnerabilitiesidentity+3