Inloggen
Gratis proefabonnement

Zo voorkomt u misbruik van wachtwoord opnieuw instellen op uw website (2026)

Illustratie over het voorkomen van misbruik bij het opnieuw instellen van wachtwoorden, waarbij bedreigingen zoals geautomatiseerde aanvallen, opsomming van gebruikers, e-mail flooding en credential stuffing worden afgewisseld met beveiligingen zoals rate limiting, CAPTCHA-verificatie, bescherming tegen het bestaan van accounts en waarschuwingen voor monitoring.
captcha.eu

De meeste teams beschermen hun inlogpagina zorgvuldig en laten de wachtwoord reset-flow vrijwel open. Aanvallers weten dit. Ze gebruiken de reset-flow om geldige accounts op te sommen, inboxen te overspoelen met geautomatiseerde e-mails, tokens te stelen door zwakke koppelingen te genereren en de aanmeldingsbeveiliging te omzeilen die u hebt ingesteld. In deze gids wordt elk patroon van misbruik bij het opnieuw instellen uitgelegd, evenals de praktische stappen die ze tegenhouden.

Geschatte leestijd: 13 minuten

Probeer CAPTCHA.eu gratis - zonder creditcard
Alle integraties weergeven

In een oogopslag

Waarom reset-stromen worden misbruikt

De reset-flow omzeilt je inlogpagina volledig. Als het zwakker is dan uw login, gebruiken aanvallers het als de gemakkelijkste weg naar accounttoegang.

Vier misbruikpatronen die je moet kennen

Accounttelling, reset flooding, token diefstal en zwak herstelontwerp. Elk heeft een andere verdediging nodig en geen van deze problemen wordt opgelost door inlogbeveiliging alleen.

De snelste enkele fix

Geef hetzelfde antwoord terug, of er nu een account bestaat of niet. Deze enkele wijziging elimineert de opsomming van accounts zonder engineeringkosten

Wat deze gids behandelt

Waarom wachtwoord reset stromen doelwit worden

De wachtwoord reset flow is de achterdeur naar je authenticatiesysteem. Het is zijn taak om gebruikers weer binnen te laten zonder hun wachtwoord, wat betekent dat het de normale geloofsbrievencontrole moet omzeilen. Dat maakt het structureel zwakker dan inloggen en aanvallers maken direct gebruik van dat gat.

Drie dingen maken resetflows tot een aantrekkelijk doelwit. Ten eerste voegen de meeste teams sterke botbeveiliging toe aan aanmeldingen, maar verwaarlozen ze het reset-eindpunt volledig. Ten tweede onthullen reset-flows nuttige informatie aan aanvallers: of een account bestaat, welke e-mailadressen geregistreerd zijn en hoe snel reset-tokens verlopen. Ten derde zijn reset-formulieren publiekelijk toegankelijk en eenvoudig te automatiseren: een bot kan duizenden reset-verzoeken per uur genereren tegen een formulier zonder snelheidsbeperking of CAPTCHA.

Het resultaat is dat zelfs teams die het inloggen hebben gehard, MFA hebben toegevoegd en rate limiting hebben geïmplementeerd, het resetten van wachtwoorden vaak achterlaten als een onbeschermde zij-ingang. OWASP's Forgot Password Cheat Sheet (Het wachtwoord vergeten spiekbriefje) noemt kwetsbaarheden in de reset-flow als een van de meest gebruikte zwakke punten in de authenticatie in productietoepassingen. Het zwakste punt in je authenticatiesysteem is het enige dat telt voor een vastberaden aanvaller, en als dat punt je resetformulier is, telt alle bescherming op je aanmeldpagina voor niets.

De vier patronen van misbruik bij het resetten van wachtwoorden

Wachtwoord reset misbruik is niet één aanvalstype. Het is een categorie van vier verschillende patronen, elk met verschillende doelen en verschillende verdedigingsmechanismen.

MISBRUIKPATROON
WAT AANVALLERS DOEN
WAT ZE WINNEN
Account opsomming
Resetverzoeken indienen voor veel e-mailadressen en kijken of de reacties verschillen voor bestaande en niet-bestaande accounts
Een gevalideerde lijst met echte account-e-mailadressen voor gebruik bij phishing, credential stuffing of gerichte aanvallen
Overstroming resetten
Automatisch grote aantallen resetmails triggeren naar één of meerdere accounts
Inbox-overload waardoor phishingmails, intimidatie van gebruikers of aantasting van de reputatie van de mailinfrastructuur worden begraven
Token diefstal en brute kracht
Onderschep resetlinks via referrer headers, gearchiveerde URL's of browsergeschiedenis; of forceer korte/voorspelbare tokens
Geldig reset token waarmee ze een nieuw wachtwoord kunnen instellen en het account kunnen overnemen zonder het origineel te kennen
Zwak herstelontwerp
Misbruik maken van onveilige herstelmethoden: herbruikbare tokens, niet-verlopende koppelingen, beveiligingsvragen met raadbare antwoorden of verwisselen van SIM om SMS-codes te onderscheppen.
Accounttoegang via het herstelpad zonder de aanmeldingsstroom te hoeven onderbreken

Deze vier patronen komen vaak samen voor in één aanvalscampagne. Een aanvaller kan beginnen met opsomming om echte accounts te identificeren en vervolgens reset flooding gebruiken om verwarring te zaaien terwijl hij een token diefstal of SIM swap uitvoert tegen een specifiek doelwit van hoge waarde. Verdediging tegen alle vier vereist gelaagde controles, niet één enkele oplossing.

Zeven verdedigingen die werken

  • Zend consistente antwoorden terug voor bestaande en niet-bestaande accounts

    Dit is de belangrijkste verandering die je kunt maken en het kost bijna niets om te implementeren. Wanneer een gebruiker een verzoek indient om een e-mailadres opnieuw in te stellen, retourneer dan exact hetzelfde bericht, dezelfde HTTP-statuscode en dezelfde responstijd, of het account nu bestaat of niet. Een bericht als “Als er een account met dat adres bestaat, ontvangt u een reset e-mail” sluit de opsomming van accounts volledig af. De meest voorkomende fout is het terugsturen van “We hebben u een reset e-mail gestuurd” voor echte accounts en “Geen account gevonden” voor niet bestaande accounts. OWASP's Forgot Password Cheat Sheet markeert dit patroon specifiek als een van de meest voorkomende enumeratie kwetsbaarheden in productietoepassingen. Repareer de responstekst, maar controleer ook de responstijd: als uw toepassing de database bevraagt voordat het een antwoord terugstuurt, kan het tijdsverschil tussen een echt hit en een misser informatie lekken. Gebruik asynchrone verwerking of kunstmatige vertraging om de timing consistent te maken.

  • CAPTCHA toevoegen aan het aanvraagformulier voor opnieuw instellen

    CAPTCHA op het resetformulier houdt twee misbruikpatronen tegelijk tegen: reset flooding en accounttelling op schaal. Een aanvaller die duizenden e-mailadressen test op geldige accounts moet deze verzoeken automatiseren. Een proof-of-work CAPTCHA dwingt een cryptografische berekening af voor elke aanvraag, waardoor automatisering op grote schaal economisch onpraktisch is zonder dat dit invloed heeft op legitieme gebruikers die één aanvraag per keer indienen. Voor Europese websites is de keuze van de CAPTCHA hier belangrijker dan bijna overal elders. Het resetformulier is een veiligheidskritische pagina waar gebruikers zich al in een kwetsbare situatie bevinden: ze zijn de toegang tot hun account kwijt. Door daar een op cookies gebaseerde gedrags-CAPTCHA aan toe te voegen, introduceert u op precies het verkeerde moment ePrivacy-toestemmingsvragen. Een cookieloze proof-of-work CAPTCHA integreert zonder extra toestemmingsmeldingen te vereisen op herstelpagina's. Voor een volledige uitleg over hoe dit werkt, zie onze gids over wat onzichtbare CAPTCHA is.

Bescherm uw wachtwoord reset stroom zonder cookies of toestemming overhead

CAPTCHA.eu stopt reset flooding en opsomming op schaal met onzichtbare proof-of-work verificatie. Geen cookies, Oostenrijks gehost, WCAG 2.2 AA gecertificeerd door TÜV Oostenrijk.

Gratis proefabonnement starten
Alle integraties bekijken

    • Beperk de snelheid per account en per IP

      Beperking van de snelheid op het reset eindpunt beperkt het volume van misbruik, zelfs als CAPTCHA al is ingesteld. Pas limieten toe op twee niveaus: per IP-adres en per account. Beperking op IP-niveau vertraagt een aanvaller die een klein aantal adressen gebruikt. Beperking op accountniveau zorgt ervoor dat zelfs een gedistribueerde aanval een enkele inbox niet herhaaldelijk kan overspoelen. Een redelijke startdrempel is drie tot vijf resetverzoeken per account per uur. Weiger na die limiet nieuwe verzoeken stilletjes: stuur hetzelfde consistente antwoord terug zonder een nieuwe e-mail te sturen. Vertel de gebruiker niet dat hij een limiet heeft bereikt, want dan lekt er informatie over je logica voor limieten. Pas ook limieten toe op het token validatie eindpunt: een aanvaller die een reset token probeert te forceren moet veel token pogingen doen, en door de snelheid van dat eindpunt te limiteren verwijder je het aanvalsoppervlak volledig voor korte tokens.

    • Gebruik cryptografisch sterke, kortstondige tokens voor eenmalig gebruik

      Reset tokens zijn de sleutels tot de accounts van je gebruikers. Genereer ze met een cryptografisch veilige willekeurige getallengenerator, geen tijdstempel, geen sequentiële ID, geen hash van voorspelbare invoer. NIST SP 800-63B beveelt ten minste 20 bytes entropie aan voor resetcodes, wat zich vertaalt naar een token van ten minste 40 hexadecimale tekens of een equivalente base64-codering. Stel een korte vervaldatum in: een uur is ruim voor de meeste toepassingen; 15 tot 30 minuten is geschikt voor contexten met een hoger beveiligingsniveau. Verval het token onmiddellijk nadat het is gebruikt: een token dat geldig blijft na een wachtwoord reset is een hardnekkige achterdeur. Verloop ook alle andere actieve tokens voor dat account wanneer een nieuwe reset wordt aangevraagd: als een aanvaller een nieuwe reset uitvoert nadat de gebruiker er al een heeft ontvangen, zou het oude token niet meer mogen werken.

    • Lekken van tokens voorkomen via referrer headers en caching

      Reset tokens die worden geleverd in URL's lopen een specifiek risico: het token kan lekken via de HTTP Referrer header als de resetpagina externe bronnen bevat (analytische scripts, lettertypen, CDN-activa of afbeeldingen van derden). Wanneer een gebruiker op een koppeling op uw resetpagina klikt, kan de browser de volledige URL (inclusief het token) als Referrer naar externe servers sturen. Voorkom dit door Referrer-Policy: no-referrer in te stellen op je resetbevestigingspagina. Stel ook de juiste cache-control headers in om te voorkomen dat geresette URL's worden opgeslagen in de browsergeschiedenis of proxycaches. Instrueer de applicatie om reset token-waarden niet te loggen in toegangslogs of foutopsporingssystemen, aangezien deze een veel voorkomende bron zijn van onbedoelde blootstelling aan token in productieomgevingen.

    • Beveiligingsvragen vervangen door geverifieerde secundaire kanalen

      Beveiligingsvragen zijn geen veilige herstelmethode. De antwoorden op veelvoorkomende beveiligingsvragen (meisjesnaam van de moeder, huisdier uit de kindertijd, eerste school) zijn vaak openbaar beschikbaar via sociale media, gegevensmakelaars of gericht onderzoek. Ze bieden de schijn van verificatie zonder de inhoud. Vervang beveiligingsvragen door geverifieerde secundaire kanalen: e-mail naar een adres dat bij de registratie is bevestigd of app-gebaseerde TOTP-codes. Als herstel via sms onvermijdelijk is, begrijp dan dat het verwisselen van simkaarten dit kwetsbaar maakt voor accounts met een hoge waarde. Voor accounts waar veel op het spel staat (beheerderstoegang, betalingsgegevens, medische dossiers), moet je een tweede geverifieerd kanaal vereisen in plaats van één herstelpad.

    • Gebruikers informeren en controleren op afwijkende resetpatronen

      Stuur gebruikers een melding wanneer een reset is aangevraagd, niet alleen wanneer deze is voltooid. Een bericht als “Er is een wachtwoordreset aangevraagd voor uw account. Als u dit niet was, kunt u deze e-mail negeren - uw wachtwoord is niet gewijzigd” geeft gebruikers de kans om te reageren voordat een aanvaller een gestolen token gebruikt. Bij het monitoren is een plotselinge piek in reset-aanvragen een vroeg signaal van een opsommings- of flooding-campagne. Stel waarschuwingen in voor ongebruikelijke resetvolumes per IP, per account of voor de applicatie als geheel. Correleer resetpieken met mislukte aanmeldingspatronen: aanvallers testen vaak opgesomde accounts op de aanmeldingspagina voordat ze overschakelen op de resetstroom als ze daar op snelheidsbeperking of CAPTCHA stuiten.

    De minimaal haalbare reset-beveiligingshouding

    Als je slechts drie dingen implementeert: consistente antwoorden (Verdediging 1), CAPTCHA op het resetformulier (Verdediging 2) en tokens met een korte levensduur voor eenmalig gebruik (Verdediging 4), dan dicht je de meest gebruikte kwetsbaarheden voor resetten. Voeg de anderen geleidelijk toe op basis van de gevoeligheid van de accounts die u beschermt.

    Waar CAPTCHA past in wachtwoord reset beveiliging

    CAPTCHA op het wachtwoord reset formulier dient een specifieke en beperkte rol: het stopt geautomatiseerd misbruik van het reset eindpunt. Het voorkomt dat bots duizenden e-mailadressen testen op geldige accounts en het voorkomt geautomatiseerde reset flooding tegen specifieke gebruikers. Het lost geen zwakke tokengeneratie op, voorkomt niet dat token lekken via referrer headers en vervangt geen consistent antwoordontwerp.

    Deze positionering is belangrijk omdat sommige teams te veel vertrouwen op de CAPTCHA (door het als enige controle te gebruiken) of te weinig gebruiken (door het over te slaan omdat “gebruikers geen puzzel hoeven op te lossen om hun wachtwoord opnieuw in te stellen”). Beide missen het punt. Onzichtbare proof-of-work CAPTCHA voegt geen zichtbare wrijving toe voor legitieme gebruikers die een verzoek indienen om hun wachtwoord te resetten. Het verhoogt alleen de kosten voor bots die er duizenden indienen. Dat is precies waar CAPTCHA thuishoort in de verdedigingsstapel.

    Specifiek voor de WordPress resetstroom is onze WordPress CAPTCHA gids heeft betrekking op integratie op het niveau wp-login.php. Voor Keycloak vereist de stroom voor het resetten van aanmeldingsgegevens een apart FTL-fragment van de aanmeldings- en registratiestroom: onze Keycloak integratiegids behandelt alle drie de stromen met specifieke configuratiestappen.

    Misbruik bij het resetten van wachtwoorden en GDPR-verplichtingen

    Een succesvolle aanval waarbij het wachtwoord opnieuw wordt ingesteld en onbevoegden toegang krijgen tot een account, vormt een inbreuk op persoonsgegevens onder GDPR. Als het gecompromitteerde account persoonlijke gegevens bevatte (wat voor bijna alle gebruikersaccounts geldt), moet je voldoen aan de beoordelings- en meldingsverplichtingen van artikel 33.

    Er is ook een specifieke GDPR-hoek aan het resetformulier zelf. Traditionele CAPTCHA-diensten die cookies plaatsen op herstelpagina's creëren een ePrivacy-toestemmingsvereiste op een onhandig moment: een gebruiker die de toegang tot zijn account is kwijtgeraakt, moet nu door een cookie-toestemmingsbanner navigeren voordat hij zijn account kan herstellen. Een cookieless proof-of-work CAPTCHA lost dit probleem structureel op. Er is geen toestemmingsmechanisme nodig voor de CAPTCHA-laag zelf, wat een zinvolle compliance vereenvoudiging is voor DPO's die de documentatielast van authenticatiestromen beheren.

    De artikel 32-hoek

    Artikel 32 van de GDPR vereist passende technische beveiligingsmaatregelen. Voor elke website die persoonlijke gegevens opslaat achter gebruikersaccounts, wordt het steeds moeilijker om de reset-flow te verdedigen bij een beoordeling door een toezichthoudende autoriteit. Reset flooding, opsomming en token diefstal zijn goed gedocumenteerde aanvalspatronen met bekende tegenmaatregelen. Het implementeren van deze maatregelen maakt deel uit van een redelijke Artikel 32 houding.

    Checklist voor implementatie

    Gebruik deze checklist om uw huidige reset-flow te controleren. De items zijn gerangschikt op impact per implementatie-inspanning: de bovenste items bieden de meeste bescherming voor het minste werk.

    • Consistente reacties: Controleer of uw resetformulier hetzelfde bericht, dezelfde statuscode en dezelfde reactietijd retourneert voor bestaande en niet-bestaande accounts.
    • CAPTCHA op het resetformulier: Voeg onzichtbare proof-of-work CAPTCHA toe aan het formulier voor een resetverzoek. Voor WordPress: zie de WordPress gids. Voor Keycloak: zie de Sleutelhanger gids.
    • Snelheidsbeperking per account en per IP: Limieten toepassen op beide niveaus. Weiger stil na de drempel: laat niet zien dat de limiet bestaat.
    • Cryptografisch sterke tokens: Bevestig dat je tokengenerator een CSPRNG met ten minste 20 bytes entropie gebruikt. Verwerp sequentiële ID's, tijdstempels en hash-of-email patronen.
    • Vervaldatum token: Tokens verlopen binnen één uur na uitgifte. Tokens vervallen onmiddellijk bij gebruik. Nieuwe reset-verzoeken maken alle eerdere tokens voor die account ongeldig.
    • Referrer-Policy header: Stel in Verwijzingsbeleid: geen verwijzer op bevestigingspagina's voor opnieuw instellen. Controleer alle externe bronnen die op deze pagina's worden geladen.
    • Geen beveiligingsvragen: Vervangen door verificatie op basis van e-mail of TOTP. Controleer alle oudere stromen met beveiligingsvragen die nog actief zijn in uw applicatie.
    • Meldingen voor verzoeken opnieuw instellen: Stuur gebruikers een e-mail wanneer een reset wordt geactiveerd, niet alleen wanneer deze is voltooid.
    • Bewaking en waarschuwingen: Stel waarschuwingen in voor reset volumepieken per IP en per account. Correleer met patronen van mislukte aanmeldingen.
    • HTTPS overal op resetstromen: Zorg ervoor dat alle resetpagina's en eindpunten voor het indienen van tokens HTTPS gebruiken met de huidige TLS. Weiger reset-tokens die via HTTP zijn ingediend.

    Veelgestelde vragen

    Wat is wachtwoord reset misbruik?

    Misbruik van het resetten van wachtwoorden is het misbruiken van een herstelstroom voor accounts om onbevoegde toegang te krijgen, geldige accounts op te sommen, inboxen te overspoelen of hersteltokens te stelen. Het is te onderscheiden van wachtwoord reset poisoning, wat een specifieke technische kwetsbaarheid is waarbij een aanvaller manipuleert hoe de reset link wordt gegenereerd. Misbruik van een reset is een bredere categorie die vier verschillende aanvalspatronen omvat: opsomming, overstroming, diefstal van tokens en een zwak herstelontwerp.

    Wat is het verschil tussen wachtwoord reset misbruik en wachtwoord reset vergiftiging?

    Wachtwoord reset poisoning is een specifieke techniek binnen de bredere categorie van reset misbruik. Poisoning treedt op wanneer een aanvaller de HTTP Host header manipuleert om een reset-link om te leiden naar een domein dat onder controle staat van de aanvaller. Misbruik van resets omvat een bredere reeks patronen: accounttelling door middel van antwoordverschillen, overspoelen van resets om inboxen te overweldigen, token brute-forcing en het uitbuiten van zwakke herstelmethoden zoals beveiligingsvragen of sms-onderschepping.

    Houdt CAPTCHA misbruik bij het resetten van wachtwoorden tegen?

    CAPTCHA stopt de geautomatiseerde misbruikpatronen: reset flooding en grootschalige accounttelling. Het lost geen zwakke tokengeneratie op, voorkomt geen tokenlekkage via referrer headers en vervangt geen consistent antwoordontwerp. Gebruik CAPTCHA als één laag in een bredere reset-beveiligingsstapel, niet als de enige controle.

    Hoe kunnen aanvallers accounts opsommen via het resetformulier?

    Als je resetformulier verschillende antwoorden terugstuurt voor bestaande en niet-bestaande accounts (verschillende berichttekst, verschillende HTTP-statuscodes of meetbaar verschillende reactietijden), kan een aanvaller resetverzoeken indienen voor een lijst met e-mailadressen en observeren welke de “account gevonden”-reactie terugsturen. Dit onthult je geregistreerde gebruikers zonder dat je een wachtwoord hoeft te kraken. De oplossing is om altijd hetzelfde antwoord terug te sturen, ongeacht of het account bestaat.

    Hoe lang moet een reset-token geldig zijn?

    Een uur is een redelijk maximum voor de meeste toepassingen. Voor contexten met een hoger beveiligingsniveau (financiële accounts, gezondheidszorg, administratieve toegang) is 15 tot 30 minuten geschikter. Het token moet onmiddellijk na gebruik verlopen en alle eerdere tokens voor een account moeten ongeldig worden gemaakt als een nieuwe reset wordt aangevraagd. Tokens die geldig blijven na gebruik zijn een hardnekkige achterdeur.

    Is het resetten van wachtwoorden een GDPR-probleem?

    Ja, op twee manieren. Ten eerste is een succesvolle aanval die leidt tot onbevoegde toegang tot een account een inbreuk op persoonsgegevens onder GDPR, waardoor een beoordeling op grond van artikel 33 en mogelijke meldingsverplichtingen in gang worden gezet. Ten tweede creëert een op cookies gebaseerde CAPTCHA op herstelpagina's een vraag over toestemming voor ePrivacy op een moeilijk moment voor gebruikers. Een CAPTCHA zonder cookies verwijdert die toestemmingsvereiste volledig uit de herstelstroom.

    Gerelateerde lezen

    Primaire bronnen

    OWASP Wachtwoord vergeten spiekbriefje: consistente reacties, veilig tokenontwerp en aanbevelingen voor tariefbeperking
    OWASP Authenticatie spiekbriefjeherauthenticatie en veilige authenticatiepraktijken
    PortSwigger Web Beveiligings Academie: Wachtwoord reset vergiftigingtechnische details over exploitatie van hostheaders in resetstromen
    NIST SP 800-63Brichtlijnen voor gememoriseerde geheime authenticatiemiddelen en vereisten voor reset-geheime entropie
    OWASP testgids: Zwakke wachtwoord reset-functionaliteiten
    CAPTCHA.eu: Wat is wachtwoordherstelvergiftiging?: definitie en onderscheid tussen vergiftiging en breder reset-misbruik
    CAPTCHA.eu: Hoe accountovernameaanvallen voorkomenbredere auth-beveiligingscontext inclusief reset-stromen

    Recente berichten

    nl_NLDutch
    en_USEnglish de_DEGerman fr_FRFrench es_ESSpanish it_ITItalian nl_NLDutch