Credential stuffing tegenhouden aan de edge

Credential stuffing

-aanvallen gebruiken geautomatiseerde tools om gestolen combinaties van gebruikersnaam en wachtwoord te testen tegen loginpagina's. De aanvallen zijn enorm — één operator test mogelijk miljoenen credentials per dag over honderden doelsites. Traditionele verdedigingen zoals rate limiting en CAPTCHA's schieten tekort, omdat aanvallers hun requests verdelen over duizenden IP-adressen en CAPTCHA-oplosdiensten gebruiken. Zo houden wij credential stuffing tegen aan de edge, voordat de requests je authenticatiesysteem bereiken.

Het aanvalsoppervlak

Een typische credential-stuffing-operatie gebruikt een lijst met gestolen credentials (op darkweb-marktplaatsen verkrijgbaar voor slechts $10 per miljoen records), een automatiseringstool (meestal een custom script of een tool als OpenBullet) en een pool van proxy-IP's (residentiële proxy's die bij elke request rouleren om IP-gebaseerde rate limiting te omzeilen).

De aanvaller configureert zijn tool om loginrequests met een gecontroleerd tempo te versturen — traag genoeg om simpele rate limits niet te triggeren, maar snel genoeg om duizenden credentials per uur te testen. Elke request komt van een ander IP-adres, met een andere user-agent-string, waardoor het lijkt op een stroom legitieme loginpogingen van verschillende gebruikers.

Waarom rate limiting faalt

IP-gebaseerde rate limiting is de eerste verdedigingslinie die de meeste teams inzetten, en het is de eerste die faalt. Residentiële proxydiensten geven toegang tot miljoenen echte IP-adressen — thuisrouters, mobiele apparaten en IoT-apparaten — die bij elke request rouleren. Vanuit het perspectief van de server komt elke loginpoging van een uniek residentieel IP zonder enige geschiedenis van misbruik.

Account-gebaseerde rate limiting (loginpogingen per gebruikersnaam beperken) is effectiever, maar creëert een denial-of-service-vector: een aanvaller kan legitieme gebruikers buitensluiten door opzettelijk meerdere loginpogingen tegen hun gebruikersnamen te laten mislukken.

Device fingerprinting als fundament

Device fingerprinting verandert de vergelijking, omdat het het device identificeert dat de aanval uitvoert, niet het IP dat het gebruikt. Een credential-stuffing-tool die op één machine of VM-farm draait, produceert een consistente device fingerprint over al zijn requests, ongeacht welk proxy-IP het roulereert.

Onze Bot Detection-engine identificeert de automatiseringstools zelf. Selenium laat navigator.webdriver-artefacten achter. Puppeteer en Playwright hebben kenmerkende JavaScript-runtime-eigenschappen. Headless Chrome mist specifieke browser-API's die de headed Chrome wel bevat. Zelfs custom HTTP-clients die geen JavaScript uitvoeren, worden gedetecteerd via TLS-fingerprinting — hun Client Hello-berichten verraden de onderliggende HTTP-library.

Velocity tracking per device

Zodra we een stabiele device-identifier hebben (via Device Identification), kunnen we velocity checks op device-niveau toepassen in plaats van op IP-niveau. Als één device 50 logins in 5 minuten probeert — ongeacht van hoeveel verschillende IP's die requests kwamen — is het patroon onmiskenbaar credential stuffing.

Onze IP Intelligence-module volgt velocity over drie tijdvensters: 5 minuten, 1 uur en 24 uur. Deze aanpak met meerdere vensters vangt zowel agressieve aanvallen (honderden pogingen per minuut) als slow-and-low-aanvallen (een paar pogingen per uur, dagenlang volgehouden).

Analyse van gedragssignalen

Naast bot detection en velocity tracking onderzoekt onze Smart Signals-analyse gedragssignalen die geautomatiseerde aanvallen onderscheiden van legitieme logins. Echte gebruikers vertonen natuurlijke variatie in requesttiming, typsnelheid en navigatiepatronen. Geautomatiseerde tools produceren doorgaans mechanisch consistente timing, identieke request-headers en geen muisbewegingen of scroll-events.

We controleren ook op inconsistenties in signalen die op spoofing van de omgeving wijzen. Een browser die beweert Chrome op macOS te zijn maar WebGL-parameters presenteert die bij een Linux-VM horen, wordt onmiddellijk gemarkeerd. Een user-agent-string die niet overeenkomt met de TLS-fingerprint activeert een tampering-melding.

Deployment aan de edge

De sleutel tot het stoppen van credential stuffing is het stoppen ervan voordat het je authenticatiesysteem bereikt. Onze agent laadt op de loginpagina en verzamelt signalen tijdens het laden van de pagina — voordat de gebruiker (of bot) credentials indient. De resultaten van de fingerprint en bot detection zijn beschikbaar tegen de tijd dat het loginformulier wordt ingediend, waardoor je server geautomatiseerde pogingen direct kan afwijzen.

Voor doelwitten met veel verkeer raden we aan onze Cloudflare Worker- of CloudFront Lambda@Edge-integratie in te zetten, die fingerprint-validatie aan de CDN-edge draait. Dit betekent dat credential-stuffing-requests worden geblokkeerd bij de edge-node die het dichtst bij de aanvaller ligt, en je origin-servers nooit bereiken.

Resultaten

Onze klanten rapporteren een reductie van 99% in credential-stuffing-volume na het inzetten van tracio.ai op hun loginpagina's. De resterende 1% bestaat uit uiterst geavanceerde aanvallen die volledige browserautomatisering met zorgvuldig gespoofte signalen gebruiken — en die worden door onze detectie met meerdere methoden gevangen binnen de eerste paar dozijn requests zodra velocity-patronen zichtbaar worden.