Credential stuffing op klantaccounts: zo stop je accountovername

Jouw webshop wordt niet gehackt, je klanten worden dat. Aanvallers loggen in met e-mailadressen en wachtwoorden die ergens anders lekten, en jouw loginpagina doet gewoon wat hij moet doen.

Dit heet credential stuffing. Het valt onder A07 Authentication Failures in de OWASP Top 10:2025. Het is geen kwetsbaarheid in Magento, Shopify of Laravel. Het is misbruik van hergebruikte wachtwoorden, op schaal en geautomatiseerd.

Hieronder lees je hoe je het herkent, wat het kost en welke maatregelen werken zonder dat echte klanten het gevoel krijgen dat ze door een beveiligingsparcours moeten.

Wat is credential stuffing precies?

Een aanvaller heeft een lijst gelekte combinaties van e-mailadres en wachtwoord uit een datalek bij een andere dienst. Een bot probeert die combinaties bij jouw shop. Veel mensen gebruiken hetzelfde wachtwoord op meerdere plekken, dus een deel werkt.

Het verschilt van brute force:

Dat laatste is de reden dat "5 pogingen, dan blokkeren per account" niet volstaat. De aanvaller probeert elk account maar één of twee keer.

Waarom is dit een probleem voor een webshop?

Een overgenomen klantaccount geeft de aanvaller meer dan je denkt:

• Opgeslagen adressen en gegevens. Naam, adres, telefoonnummer, orderhistorie. Dat is persoonsgegevens, met AVG-gevolgen.
• Opgeslagen betaalmethoden of tegoeden. Afhankelijk van je betaalprovider en setup.
• Gift cards, store credit en loyalty-punten. Dit is voor aanvallers vaak het echte doel, want het is direct te verzilveren.
• Bestellingen op andermans rekening of met andermans korting. Denk aan B2B-accounts met speciale prijzen.
• Reputatieschade en supportdruk. Klanten bellen boos en vragen waarom jij hun gegevens niet hebt beschermd.

Is er risico voor betrokkenen, dan kan een datalek meldplichtig zijn bij de Autoriteit Persoonsgegevens, binnen 72 uur (AVG art. 33). Of een overname van klantaccounts onder die meldplicht valt, hangt af van de omstandigheden. Laat dat beoordelen, en lees onze aanpak in Magento 2 gehackt: wat nu?.

Hoe herken je het in je logs?

Je hoeft niet te wachten op een klacht. Dit zijn de patronen die we zoeken:

• Piek in mislukte logins op customer/account/loginPost (Magento), /login (Laravel) of de login-endpoint van je headless frontend.
• Veel verschillende e-mailadressen vanaf dezelfde IP-reeks, ASN of user-agent.
• Bijna-identieke requests: dezelfde user-agent, dezelfde headers, vaste volgorde.
• Een hoge ratio mislukt/geslaagd. Normale gebruikers slagen meestal in één of twee pogingen. Bij een aanval is de ratio veel slechter, met af en toe een geslaagde login.
• Logins uit onverwachte landen voor accounts die altijd vanuit Nederland bestellen.
• Geslaagde logins gevolgd door direct een wijziging: e-mailadres, wachtwoord, adres of een gift card-saldo-check.
• Verzoeken buiten kantoortijden in regelmatige golven.
• Een toename van wachtwoord-reset-mails. Bots proberen soms ook de reset-flow.

Een snelle controle op de webserver-log, als je een standaard nginx-logformat gebruikt:

grep "POST /customer/account/loginPost" /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Dit toont de IP-adressen met de meeste login-POSTs. Bij credential stuffing zie je vaak juist géén dominante IP's, maar honderden adressen met elk een paar verzoeken. Kijk dan naar het totaal per minuut.

Heb je geen logging op applicatieniveau, dan zie je niet welke logins mislukten. Dat is een kans om je logging te verbeteren; zie security logging voor webshops.

Maatregel 1: rate limiting op meerdere niveaus

Limiteer op meer dan één dimensie:

• per IP-adres
• per IP-reeks of ASN, voor verspreide bots
• per account (e-mailadres)
• per sessie of device-fingerprint

Op nginx-niveau kun je de login-endpoint apart begrenzen:

limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;

location = /customer/account/loginPost/ {
    limit_req zone=login burst=5 nodelay;
    # ... normale fastcgi/proxy config
}

Let op: achter een CDN of reverse proxy moet $binary_remote_addr het echte client-IP zijn, anders blokkeer je je eigen proxy. Zet de real IP-module goed.

Rate limiting per IP alleen helpt beperkt tegen verspreide botnets. Daarom is een WAF met bot-detectie belangrijk. Hoe je dat inricht staat in WAF en bot-bescherming voor je webshop en in onze Cloudflare Pro-instellingen.

Bij Laravel gebruik je de ingebouwde RateLimiter en throttle-middleware, en limiteer je op combinaties van e-mailadres en IP, niet alleen op IP.

Maatregel 2: captcha of Turnstile, zonder klanten te irriteren

Een captcha op de loginpagina houdt simpele bots tegen. Een dure captcha-oplossing is niet nodig; Cloudflare Turnstile is een bekend, gebruiksvriendelijk alternatief dat meestal geen puzzel toont.

Praktische keuzes:

• Toon de uitdaging alleen bij verdacht gedrag, bijvoorbeeld na een paar mislukte pogingen of bij een slechte IP-reputatie. Voor normale klanten blijft login dan snel.
• Zet de controle ook op wachtwoord vergeten, registratie en gift card-saldocheck. Aanvallers wijken uit naar het zwakste endpoint.
• Valideer het token server-side. Een captcha die alleen in de browser wordt gecontroleerd is decoratie.

Wees eerlijk over de grens: gespecialiseerde diensten die captchas laten oplossen door mensen of AI bestaan. Een captcha is een drempel, geen slot.

Maatregel 3: wachtwoordbeleid dat klopt

Oude regels als "minimaal 8 tekens met een hoofdletter, cijfer en leesteken" leveren Welkom01! op. Beter:

• Lengte boven complexiteit. Een minimale lengte van 10 tot 12 tekens, en lange wachtwoordzinnen toestaan.
• Controleer op gelekte wachtwoorden. Vergelijk nieuwe wachtwoorden met een lijst van bekende gelekte wachtwoorden. Een bekende dienst hiervoor is Have I Been Pwned met een k-anonimiteit-API, waarbij je alleen een deel van de hash verstuurt. Bij Laravel bestaat hiervoor de Password::uncompromised()-regel.
• Blokkeer de allerbekendste wachtwoorden (wachtwoord123, de naam van je shop, het e-mailadres zelf).
• Geen verplichte periodieke wijziging. Die leidt tot Wachtwoord1, Wachtwoord2.
• Plakken toestaan. Blokkeer plakken in het wachtwoordveld niet; password managers hebben dat nodig.

Bij Magento stel je de wachtwoordsterkte en lockout in via de configuratie, maar de standaardopties zijn beperkt. Een extra controle op gelekte wachtwoorden vraagt vaak maatwerk of een goede extensie. Controleer een extensie wel zoals beschreven in extensies veilig installeren.

Maatregel 4: 2FA of passkeys, als optie

Voor klantaccounts is verplichte 2FA bij een webshop meestal te veel gevraagd. Klanten haken af. Een optionele tweede factor of passkey voor klanten die dat willen, werkt wel, vooral voor B2B-portalen en accounts met tegoeden.

Voor je admin ligt het anders: dat hoort 2FA te hebben (Magento heeft dat standaard sinds 2.4.0). Daarover lees je meer in Magento admin beveiligen.

Maatregel 5: notificaties bij login en gevoelige wijzigingen

Een kleine investering met veel effect. Stuur een e-mail bij:

• een login vanaf een nieuw apparaat of nieuwe locatie
• wijziging van e-mailadres of wachtwoord
• wijziging van het bezorgadres vlak voor een bestelling
• gebruik van een gift card of groot tegoed

Stuur de wijziging van het e-mailadres ook naar het oude adres, met een link om het terug te draaien. Aanvallers wijzigen eerst het e-mailadres, zodat de echte klant niets meer ziet.

Maatregel 6: bescherm gift cards, tegoeden en loyalty

Hier zit het geld. Wij raden aan:

• Bestel- en inwisselacties met tegoed vragen opnieuw om het wachtwoord of een extra bevestiging.
• Limiteer het aantal saldocontroles per sessie en per IP, want bots testen of een code geldig is.
• Maak gift card-codes lang en onvoorspelbaar.
• Let op ongebruikelijke patronen: veel kleine inwisselingen, of direct na een login het volledige saldo opmaken.
• Houd tegoed-mutaties bij in een logboek dat je kunt terugzoeken.

Maatregel 7: onderscheid bots van klanten

Een goede WAF of bot-management-laag kijkt naar IP-reputatie, TLS-fingerprint, gedrag en headers. Dat vangt een groot deel van het botverkeer op voordat het je applicatie raakt. Je verliest er weinig mee, want echte klanten merken het niet.

Een aanvulling die zonder kosten kan: gebruik overal dezelfde foutmelding. "E-mailadres of wachtwoord onjuist" voorkomt dat een aanvaller kan achterhalen of een account bestaat. Hetzelfde geldt voor de reset-flow: "Als dit adres bij ons bekend is, sturen we een e-mail."

Wat te doen bij een lopende aanval?

1. Bevestig met logs: piek in login-POSTs, mislukte-ratio, geslaagde logins uit vreemde bronnen.
2. Verscherp rate limiting en zet de captcha/Turnstile aan voor iedereen op de loginpagina.
3. Reset wachtwoorden van accounts waar verdachte geslaagde logins op zaten, en beëindig hun sessies.
4. Controleer gift card- en tegoedmutaties, en recente adres- en e-mailwijzigingen.
5. Informeer getroffen klanten duidelijk en vraag ze een uniek wachtwoord te kiezen.
6. Beoordeel of er een meldplicht geldt en leg vast wat je hebt gedaan.

Wil je dit vooraf geregeld hebben? Zie het incident response plan voor webshops.

Veelgestelde vragen

Is credential stuffing een hack van mijn webshop?

Technisch niet. De aanvaller gebruikt geldige logins van klanten die elders zijn gelekt. Jouw verantwoordelijkheid is wel dat je het opmerkt, beperkt en dat je klantgegevens redelijk beschermt, ook tegen dit scenario.

Helpt het blokkeren van IP-adressen?

Een beetje. Aanvallers verspreiden hun verzoeken over veel adressen, dus losse IP-blokkades zijn een dweil met de kraan open. Combineer rate limiting met bot-detectie in een WAF en een captcha bij verdacht gedrag.

Moeten klanten verplicht 2FA gebruiken?

Voor de meeste webshops niet. Het kost conversie en het probleem is ook op andere manieren te beperken. Bied het wel aan als optie, en verplicht het voor admins en medewerkers.

Hoe controleer ik of een wachtwoord gelekt is?

Met een dienst die bekende gelekte wachtwoorden vergelijkt, bijvoorbeeld Have I Been Pwned via de k-anonimiteit-API. In Laravel is er de Password::uncompromised()-validatieregel. Bij Magento is meestal maatwerk of een extensie nodig.

Is een captcha genoeg?

Nee. Het houdt simpele bots tegen, maar vastberaden aanvallers omzeilen het. Je hebt meerdere lagen nodig: rate limiting, bot-detectie, monitoring en notificaties.

Merk je een piek in mislukte logins of wil je dat iemand je loginflow doorlicht? Bekijk onze security-aanpak of neem contact op via /contact. Je praat direct met degene die het doorrekent en bouwt.