Credential stuffing is het opnieuw afspelen van combinaties van e-mail en wachtwoord, gelekt bij andere sites, op jouw login. Mensen hergebruiken wachtwoorden, dus een klein deel van elke gelekte lijst werkt bijna overal. De aanvaller hoeft je systeem niet te kraken; hij heeft volume nodig, en een loginformulier dat snel antwoordt.
Hoe het eruitziet in je logs
- Een percentage mislukkingen dat omhoogschiet. Normale logins slagen meestal. Een stuffing-run mislukt negentien van de twintig keer.
- Veel accounts, weinig pogingen per account. Anders dan bij brute force wordt elk account één of twee keer geprobeerd, dus een lockout per account gaat nooit af.
- Veel adressen. Pogingen komen via residential proxy-pools, dus de bovenste IP's blokkeren maakt nauwelijks verschil.
- Logins zonder pagina. Het login-endpoint wordt direct aangeroepen, door clients die de loginpagina nooit hebben geladen.
- Machinale timing. Requests in een vast ritme, op uren dat je klanten slapen.
Waarom de gebruikelijke verdediging tekortschiet
Rate limits per IP-adres worden verslagen door proxy-pools met duizenden exits. Account-lockouts treffen je klanten harder dan de aanvaller, en kunnen worden misbruikt om mensen expres buiten te sluiten. CAPTCHA's worden door betaalde diensten opgelost voor een fractie van een cent. Elk ervan voegt frictie toe voor echte mensen en een kleine kostenpost voor bots.
Beoordeel de client, niet alleen de request
Een stuffing-tool kan bij elke request van IP en User-Agent wisselen. Wat het moeilijk kan nabootsen, is een complete, consistente browser die je pagina heeft geladen, je script heeft uitgevoerd en zich de hele sessie als een mens gedraagt:
- een ondertekend token van de pagina, dat ontbreekt of door veel sessies wordt gedeeld;
- automatiseringsvlaggen en browser-fingerprints die niet kloppen;
- één apparaat of token dat veel verschillende accounts probeert;
- doorgaan met proberen dwars door fouten heen, wat mensen niet doen.
Waar de check hoort
Vraag het voordat je het wachtwoord controleert, zodat een bot nooit leert of een combinatie werkt:
- bot high: antwoord alsof het wachtwoord verkeerd was. De tool leert niets, en je klant merkt er niets van.
- bot: vraag om een tweede factor of een code per e-mail voordat je de sessie binnenlaat.
- alle anderen: de normale login.
Een bot hetzelfde "verkeerd wachtwoord" geven dat een mens zou zien, is belangrijk: een aparte blokkeerpagina vertelt de aanvaller dat hij van tactiek moet wisselen.
Na de login
Vertel je botcheck wat er daarna gebeurde. Een login die later een echte bestelling plaatst, of een chargeback die het tegendeel bewijst, is bewijs dat geen request-header kan vervalsen, en het maakt de volgende beslissing over dezelfde bezoeker scherper.