Brute force aanvallen op uw website voorkomen

captcha.eu

Brute force attacks zijn een van de meest hardnekkige bedreigingen voor de beveiliging van websites. In 2026 combineren ze gestolen lijsten met referenties, gedistribueerde botnets en AI-geoptimaliseerd raden, waardoor verdediging op basis van één laag onvoldoende is. In deze gids wordt uitgelegd hoe elke beschermingslaag werkt, waar deze op zichzelf tekortschiet en hoe u ze effectief kunt combineren.

Geschatte leestijd: 12 minuten


De dreiging in 2026

Geautomatiseerde tools testen miljoenen combinaties per seconde over gedistribueerde IP-bereiken; eenvoudige IP-blokkering volstaat niet langer.

Sterkste afzonderlijke maatregel

MFA. Uit gegevens van Microsoft blijkt dat het 99,9% van de gecompromitteerde accounts tegenhoudt, zelfs als wachtwoorden al bekend zijn.

Waarom CAPTCHA hier past

Proof-of-work CAPTCHA werkt als een ingebouwde limiter die de kosten van elke aanmeldingspoging voor bots verhoogt voordat er ooit een wachtwoord wordt geprobeerd.

De juiste aanpak

Grondige verdediging: geen enkele laag houdt alles tegen. MFA, snelheidsbeperking en CAPTCHA dichten samen de gaten die elk afzonderlijk openlaat.



Brute kracht is geen nieuwe aanval. Wat veranderd is, is de snelheid, de schaal en de geavanceerdheid. Moderne tools draaien niet meer vanaf één machine met een duidelijk IP-adres. In plaats daarvan verspreiden aanvallers hun pogingen over duizenden IP-adressen tegelijk, roteren ze door proxy-netwerken en gebruiken ze AI om de meest waarschijnlijke wachtwoordkandidaten als eerste te rangschikken, op basis van miljarden referenties die zijn gelekt bij eerdere datalekken.

Volgens het Verizon Data Breach Investigations Report zijn gestolen referenties betrokken bij de meeste inbreuken op webapplicaties. Brute kracht en “credential stuffing” zijn de belangrijkste methoden om ze te verkrijgen. Voor websitebeheerders betekent dit dat het oude mentale model ("mijn gebruikers hebben sterke wachtwoorden, dus we zitten goed") niet langer opgaat. Aanvallen zijn inderdaad gericht op zwakke wachtwoorden. Maar ze richten zich ook op hergebruik van wachtwoorden in verschillende services en ze kunnen miljoenen pogingen per uur aan zonder dat dit leidt tot eenvoudige snelheidslimieten als het verkeer wordt gedistribueerd.

De omvang hiervan is niet theoretisch. In mei 2024 registreerde een bedreigingsacteur die bekend stond onder de naam Menelik partneraccounts op een Dell-klantenportaal en spendeerde drie weken aan het brute-forcen van servicetag-identificatoren met ongeveer 5.000 verzoeken per minuut. Dell ontdekte de activiteit pas toen de aanvaller een e-mail stuurde waarin hij de kwetsbaarheid bekendmaakte. Tegen die tijd waren de gegevens van ongeveer 49 miljoen klanten geschraapt. Voor de aanval was geen geavanceerde exploit nodig, maar alleen een aanhoudend, geautomatiseerd volume tegen een endpoint zonder adequate snelheidsbeperking of botdetectie.

De praktische implicatie: om een aanmeldpagina, een registratieformulier, een wachtwoord reset flow of een API endpoint te beschermen tegen brute kracht zijn meerdere lagen nodig die samenwerken. De secties hieronder leggen elke laag uit, inclusief waar het werkt, waar het faalt en wat het gat opvult.


Niet alle brute kracht aanvallen werken op dezelfde manier. Inzicht in de variant bepaalt welke verdediging je prioriteit geeft.

AANVALTYPE
HOE HET WERKT
PRIMAIRE VERDEDIGING
Eenvoudig brute kracht
Probeert elke mogelijke tekencombinatie in volgorde
Lange, complexe wachtwoorden; accountvergrendeling
Woordenboek aanval
Gebruikt lijsten met veelgebruikte woorden en bekende wachtwoorden
Sterk wachtwoordbeleid; blokkeer veelgebruikte wachtwoorden
Het vullen van referenties
Herhaalt gebruikersnaam/wachtwoordparen van datalekken op andere sites
MFA; CAPTCHA; breach-password screening
Wachtwoord sproeien
Probeert een paar gemeenschappelijke wachtwoorden voor veel accounts om uitsluiting te voorkomen
Snelheidsbeperking per gebruikersnaam; anomaliedetectie
Hybride aanval
Combineert woordenboekwoorden met getallen en symbolen
Wachtzinnen; wachtwoordmanagers; MFA
Regenboogtafel aanval
Gebruikt vooraf berekende hashtabellen om hashes van wachtwoorden om te keren
Gezouten hashing; moderne hash-algoritmen (bcrypt, Argon2)

Credential stuffing en password spraying verdienen speciale aandacht omdat dit de varianten zijn die het makkelijkst maatregelen omzeilen die alleen ontworpen zijn voor brute kracht. Credential stuffing hoeft geen wachtwoorden te raden; het heeft ze al. Password spraying vermijdt detectie door onder de drempelwaarden voor het blokkeren van accounts te blijven. Beide vereisen een verdediging die verder gaat dan alleen het wachtwoordbeleid.

Als je meer wilt weten over credential stuffing, bekijk dan onze gids over wat credential stuffing is en hoe het werkt.


  • Multi-factor verificatie

    MFA is de sterkste verdediging tegen brute force aanvallen en het bewijs is ondubbelzinnig. Microsofts analyse van incidenten waarbij accounts werden gecompromitteerd, wees uit dat MFA 99,9% ervan zou hebben voorkomen. De reden is structureel: zelfs als een aanvaller een wachtwoord correct raadt of bemachtigt, vereist MFA een tweede factor (een TOTP-code, een hardwaresleutel of een pushmelding) waartoe de aanvaller geen toegang heeft. Voor websitebeheerders is de prioriteit MFA op elke beheerdersaccount en account met hoge rechten, gevolgd door MFA op elke account met toegang tot gevoelige gegevens of financiële stromen. Het afdwingen van MFA voor alle eindgebruikers hangt af van het publiek en het risicoprofiel, maar moderne browserondersteuning voor passkeys en authenticatie-apps maakt het haalbaar voor de meeste use cases.

  • Snelheidsbeperking en progressieve vertragingen

    Rate limiting beperkt het aantal aanmeldpogingen dat een client kan doen binnen een bepaalde tijd. Het is een eenvoudige en effectieve eerste verdedigingslinie tegen ongenuanceerde aanvallen. Na een bepaald aantal mislukte pogingen vanaf hetzelfde IP-adres introduceert de server een vertraging, stuurt een tijdelijke blokkade terug of vereist een extra verificatiestap. De beperking van eenvoudige IP-gebaseerde snelheidsbeperking is dat moderne gedistribueerde aanvallen verzoeken via duizenden verschillende IP-adressen routeren. Elk individueel IP blijft onder de drempel terwijl het totale aanvalsvolume enorm blijft. Een robuustere aanpak combineert snelheidsbeperking op IP-niveau met drempels per account, waarbij mislukte pogingen per gebruikersnaam worden bijgehouden, ongeacht het IP van herkomst, en koppelt dat aan anomaliedetectie die ongebruikelijke verkeerspatronen globaal markeert, niet alleen per bron.

  • Beleid voor blokkering van accounts

    Accountvergrendeling blokkeert een account tijdelijk of permanent na een ingesteld aantal mislukte aanmeldpogingen. De OWASP Authentication Cheat Sheet raadt een drempel van vijf tot tien mislukte pogingen aan voordat een tijdsgebaseerde lockout van toepassing is. Harde lockouts (waarbij een account wordt geblokkeerd totdat een beheerder het handmatig deblokkeert) bieden de sterkste bescherming, maar creëren een risico op denial-of-service misbruik. Een aanvaller kan opzettelijk veel accounts laten blokkeren, waardoor legitieme gebruikers niet kunnen inloggen. Progressieve vertragingen hebben over het algemeen de voorkeur: elke mislukte poging verlengt de wachttijd voordat de volgende poging wordt toegestaan, waardoor geautomatiseerde tools gefrustreerd raken zonder echte gebruikers permanent te blokkeren.

  • Sterk wachtwoordbeleid

    De lengte van een wachtwoord is belangrijker dan de complexiteit. Een wachtwoordzin van 16 tekens die bestaat uit willekeurige woorden is moeilijker te kraken dan een reeks van 8 tekens die bestaat uit letters, cijfers en symbolen. Wachtwoordmanagers maken lange, unieke wachtwoorden praktisch voor elke account. Voor websitebeheerders is het meest effectieve beleid om wachtwoorden van ten minste 12 tekens te eisen en nieuwe wachtwoorden te screenen in databases met bekende inbreuken, waarbij wachtwoorden die in eerdere lekken zijn voorgekomen worden geweigerd. Het wachtwoordbeleid biedt een goede oplossing voor eenvoudige brute kracht- en woordenboekaanvallen. Het biedt bijna geen bescherming tegen credential stuffing, waarbij de aanvaller al het juiste wachtwoord heeft. Daarom is wachtwoordbeleid alleen onvoldoende als verdediging tegen brute kracht.

  • CAPTCHA als structurele botbarrière

    CAPTCHA werkt anders dan de andere lagen op deze lijst. In plaats van het beperken van wat een aanvaller kan doen na een mislukte poging, verhoogt het de kosten van elke poging voordat het je authenticatielogica bereikt. Dat onderscheid is belangrijk. Het belangrijkste onderscheid is tussen traditionele visuele CAPTCHA en moderne proof-of-work CAPTCHA. Traditionele CAPTCHA (afbeeldingsrasters, vervormde tekst) is in toenemende mate breekbaar. AI-tools lossen automatisch uitdagingen met afbeeldingen op en CAPTCHA-oplosboerderijen kunnen miljoenen uitdagingen per dag verwerken voor een paar dollar. Tegen een vastberaden aanvaller met voldoende middelen biedt een visuele CAPTCHA minder bescherming dan het lijkt. Proof-of-work CAPTCHA werkt anders. In plaats van de gebruiker te vragen om objecten in een afbeelding te identificeren, moet de browser een kleine cryptografische berekening uitvoeren voordat het formulier kan worden verzonden. Voor een echte gebruiker gebeurt dit onzichtbaar op de achtergrond voordat hij klaar is met het invullen van het formulier. Voor een bot die duizenden aanmeldingen per minuut probeert, moet elke poging nu een rekenpuzzel oplossen, waardoor de kosten van de aanval toenemen, ongeacht het aantal IP's of apparaten dat de aanvaller gebruikt. OWASP's Authentication Cheat Sheet merkt op dat CAPTCHA moet worden gezien als een defense-in-depth controle die brute force aanvallen “tijdrovender en duurder” maakt. Specifiek bij proof-of-work zijn die kosten ingebouwd in de architectuur in plaats van afhankelijk van de moeilijkheidsgraad van de puzzel.

Waarom CAPTCHA structureel verschilt van snelheidsbeperking

Rate limiting zegt: “je mag het maar X keer per minuut proberen”. CAPTCHA zegt: “elke poging vereist rekenwerk dat niet goedkoop geautomatiseerd kan worden”. Een aanvaller met snelheidsbeperking verspreidt eenvoudigweg verzoeken over IP's. Een aanvaller die geconfronteerd wordt met een proof-of-work CAPTCHA moet een cryptografische puzzel oplossen voor elke afzonderlijke poging, over elk IP, elk apparaat en elke bot in het netwerk. De kosten schalen lineair met het volume, waardoor grootschalige aanvallen economisch onpraktisch worden in plaats van alleen maar lastig.

CAPTCHA.eu gebruikt proof-of-work: onzichtbaar, kookloos, gehost in de EU

CAPTCHA.eu beschermt aanmeldingen, registraties en het resetten van wachtwoorden met onzichtbare proof-of-work verificatie. Geen beeldpuzzels. Geen cookies. Alle gegevens verwerkt in Oostenrijk onder EU-wetgeving. WACA Silver gecertificeerd door TÜV Oostenrijk tegen WCAG 2.2 AA.

  • Bewaking en opsporing van anomalieën

    Zelfs als al het bovenstaande aanwezig is, kunt u door monitoring zien wanneer er iets is veranderd. Een brute force aanval in uitvoering laat duidelijke sporen achter: een plotselinge piek in mislukte aanmeldpogingen, een ongebruikelijke verdeling van IP's van herkomst, of een grote hoeveelheid aanvragen naar een enkel eindpunt op een abnormaal tijdstip.


Detectie is één ding. Reageren is iets anders. Als je een brute force aanval ontdekt, beperkt de volgende volgorde de schade.

  • Tijdelijk de meest actieve IP's of IP-bereiken blokkeren.

    Dit is een kortetermijnmaatregel, geen complete oplossing. Gedistribueerde aanvallen zullen er omheen leiden, maar het vermindert de directe belasting en levert tijd op.

  • Schakel CAPTCHA in op het doel-eindpunt als dit nog niet actief is.

    Zelfs het inzetten tijdens een aanval verhoogt de kosten voor bots die het blijven proberen.

  • Maak de drempels voor tariefbeperking onmiddellijk strenger.

    Verklein het venster voor toegestane pogingen en verhoog de vertragingsduur voor de duur van de aanval.

  • Forceer een wachtwoordherziening voor accounts die afwijkende activiteiten vertonen.

    Als bepaalde accounts ongewoon veel mislukte pogingen hebben gehad, moet er opnieuw geauthenticeerd worden voordat de volgende succesvolle aanmelding wordt toegestaan.

  • Controleer op succesvolle aanmeldingen die voorafgingen aan of samenvallen met het aanvalsverkeer.

    Een aanvaller die al is geslaagd kan binnen zijn terwijl de bredere aanval doorgaat als afleiding.

  • Bewaar je logboeken.

    Ruwe toegangslogs van het aanvalsvenster zijn essentieel voor analyse na een incident en, indien relevant, voor rapportage volgens GDPR of NIS2.

Nog niet beschermd? Voeg vandaag nog CAPTCHA.eu toe aan uw aanmeldingsflow

CAPTCHA.eu integreert in enkele minuten in WordPress, TYPO3, Keycloak, Magento en aangepaste stacks. Oostenrijk-gehost, geen cookies, geen puzzels voor echte gebruikers.


Elke verdediging op deze lijst richt zich op een specifieke aanvalsvector. Geen van de verdedigingen pakt ze allemaal aan.

MFA weerhoudt een aanvaller die al het juiste wachtwoord heeft van toegang tot de account, maar het stopt niet het brute force verkeer dat je server bereikt. Duizenden mislukte MFA-geblokkeerde pogingen genereren nog steeds belasting, verbruiken bronnen en vullen je logboeken.

Beperking van de snelheid regelt het verkeersvolume, maar moderne gedistribueerde aanvallen leiden om drempels op IP-niveau heen zonder te vertragen. Het werkt goed tegen onontwikkelde aanvallen, niet tegen krachtige tegenstanders.

CAPTCHA verhoogt de kosten van elke poging rekenkundig, maar zonder MFA laat een succesvolle CAPTCHA oplossing nog steeds een inlogpoging toe. CAPTCHA filtert bots, MFA houdt gecompromitteerde referenties tegen.

Accountvergrendeling voorkomt onbeperkt raden, maar het creëert een risico op denial-of-service en beschermt niet tegen credential stuffing, waarbij de aanvaller slechts één poging per account nodig heeft.

De conclusie van de richtlijnen van OWASP en van de praktische architectuur van elk goed beveiligd aanmeldsysteem is dat deze lagen ontworpen zijn om elkaar aan te vullen. Een login endpoint dat CAPTCHA, MFA, rate limiting en anomaliemonitoring combineert is echt moeilijk te brute-force op schaal. Elk van deze elementen alleen laat gaten die een vastberaden aanvaller kan benutten.


Wat is de meest effectieve manier om brute force aanvallen te voorkomen?

Geen enkele maatregel houdt alle varianten tegen. De meest effectieve aanpak is een combinatie van MFA (die voorkomt dat accounts worden gecompromitteerd, zelfs als wachtwoorden bekend zijn), CAPTCHA (die de computerkosten van elke geautomatiseerde poging verhoogt) en rate limiting (die het aantal pogingen beperkt). Uit de analyse van Microsoft bleek dat MFA alleen al 99,9% van de onderzochte accountcompromitteringen zou hebben tegengehouden, waardoor het de maatregel met de hoogste prioriteit is als je er maar één kunt implementeren.

Houdt CAPTCHA brute force aanvallen tegen?

Ja, maar het type CAPTCHA is belangrijk. Traditionele visuele CAPTCHA (afbeeldingsrasters, vervormde tekst) wordt steeds vaker opgelost door geautomatiseerde tools en CAPTCHA-oplosdiensten. Proof-of-work CAPTCHA is effectiever omdat het een cryptografische berekening vereist voor elke poging, waardoor de kosten hoger worden ongeacht het vermogen van de aanvaller om afbeeldingen te herkennen. Geen van beide typen vervangt MFA, maar beide verhogen de moeite en kosten van een grootschalige brute force campagne aanzienlijk.

Wat is het verschil tussen brute kracht en credential stuffing?

Brute force-aanvallen raden wachtwoorden zonder voorkennis, waarbij combinaties worden geprobeerd totdat er één werkt. Credential stuffing gebruikt bekende gebruikersnaam/wachtwoordparen van eerdere datalekken en test deze op andere services, waarbij hergebruik van wachtwoorden wordt uitgebuit. Credential stuffing is sneller en gerichter. Een sterk wachtwoordbeleid beschermt goed tegen brute kracht, maar biedt weinig bescherming tegen credential stuffing, omdat de aanvaller het juiste wachtwoord al heeft. MFA en CAPTCHA pakken beide aan.

Is beperking van de snelheid genoeg om brute force aanvallen te voorkomen?

Voor eenvoudige aanvallen met één bron is snelheidsbegrenzing effectief. Tegen moderne gedistribueerde brute kracht, waarbij verzoeken van duizenden verschillende IP-adressen tegelijk komen, is IP-gebaseerde snelheidsbegrenzing alleen onvoldoende. Drempels per account en anomaliedetectie vullen dit aan. In combinatie met CAPTCHA en MFA wordt snelheidsbeperking onderdeel van een robuuste gelaagde verdediging.

Hoe weet ik of mijn website wordt aangevallen met brute kracht?

De duidelijkste signalen zijn: een plotselinge piek in mislukte aanmeldpogingen in uw serverlogboeken, grote aantallen aanvragen bij verificatie-eindpunten, meerdere pogingen tegen verschillende accounts vanaf verschillende IP's (wachtwoordspraying) of een CAPTCHA-dashboard dat een ongebruikelijke verificatiepiek laat zien. Veel brute force aanvallen blijven uren of dagen onopgemerkt op sites zonder actieve monitoring. Het instellen van waarschuwingen voor mislukte verificatie is een van de eenvoudigste en meest waardevolle verbeteringen die een sitebeheerder kan doen op het gebied van monitoring.

Werkt CAPTCHA zonder cookies of banners met toestemming van de gebruiker?

Traditionele CAPTCHA-diensten plaatsen cookies, waardoor ePrivacy-toestemming vereist is. CAPTCHA.eu werkt door zijn architectuur zonder cookies, dus er is geen cookie-gerelateerde nalevingskwestie op te lossen en er is geen toestemmingsbanner-update nodig voor de CAPTCHA-laag. Het verwerkt alle verificatiegegevens in Oostenrijk onder EU-wetgeving. Voor Europese websitebeheerders die botbescherming willen zonder de overhead van hun toestemmingsbeheer uit te breiden, is de architectuur zonder cookies een belangrijk praktisch voordeel.

Welke stromen moet ik prioriteit geven voor bescherming tegen brute kracht?

Aanmeldingsformulieren zijn het primaire doelwit, maar aanvallers richten zich ook op wachtwoord reset-flows (die een vergrendeld account kunnen omzeilen), registratieformulieren (nepaccounts aanmaken op grote schaal) en API-authenticatie-eindpunten. Elk eindpunt dat referenties accepteert of toegangstokens toekent is een potentieel brute force doelwit. Geef prioriteit aan bescherming in deze volgorde: aanmelden, wachtwoord opnieuw instellen, API-eindpunten, registratie.


nl_NLDutch