Waartegen het hashen van een wachtwoord je eigenlijk beschermt

De korte versie

Het hashen van een wachtwoord beschermt gebruikers wanneer je wachtwoorddatabase wordt gestolen.

Dat is de belangrijkste taak. Niet het enige detail, niet het volledige beveiligingsmodel, maar wel de centrale reden waarom we wachtwoorden hashen in plaats van ze direct op te slaan.

Een goed gehasht wachtwoord is moeilijk terug te draaien. Als een aanvaller een kopie van je gebruikerstabel bemachtigt, zou die niet meteen moeten leren dat het wachtwoord van Alice Spring2026! is. In plaats daarvan krijgt de aanvaller een opgeslagen hash die tijd, geld en hardware kost om tegen gokpogingen te testen.

Dat onderscheid is belangrijk. Wachtwoordhashing is niet bedoeld om login op zichzelf veilig te maken. Het stopt geen phishing. Het stopt niet dat iemand gelekte wachtwoorden probeert op je loginformulier. Het beschermt geen sessiecookie na het inloggen. Het koopt tijd en vermindert schade na een heel specifieke fout: je opslag van wachtwoordverificatiegegevens wordt blootgesteld.

Als je die grens begrijpt, neem je betere beslissingen over algoritmen, work factors, resets, logging en incidentrespons.

Wat een wachtwoordhash is

Een wachtwoordhash is de output van een eenrichtingsfunctie die op een wachtwoord wordt toegepast, meestal met een unieke salt en een bewust traag algoritme voor wachtwoordhashing.

Wanneer een gebruiker een account aanmaakt, zou het systeem ongeveer dit moeten doen:

1. Het wachtwoord ontvangen via HTTPS.
2. Een willekeurige, unieke salt genereren.
3. Het wachtwoord en de salt door een functie voor wachtwoordhashing halen, zoals Argon2id, bcrypt, scrypt of PBKDF2.
4. De algoritmenaam, parameters, salt en resulterende hash opslaan.
5. Het oorspronkelijke wachtwoord weggooien.

Wanneer de gebruiker later inlogt, herhaalt het systeem hetzelfde hashingproces met het ingevoerde wachtwoord en de opgeslagen parameters. Als de resulterende hash overeenkomt met de opgeslagen hash, slaagt de login.

Het belangrijke deel: de applicatie hoeft het oorspronkelijke wachtwoord niet te kennen. Ze hoeft alleen te verifiëren dat het ingevoerde wachtwoord het verwachte resultaat oplevert.

Daarom is het opslaan van wachtwoorden met omkeerbare encryptie meestal het verkeerde model. Als je applicatie elk wachtwoord kan decrypten, kan iedereen die de decryptiesleutel steelt hetzelfde doen. Wachtwoorden zouden normaal gesproken niet in omgekeerde richting verifieerbaar moeten zijn, niet slechts verborgen.

Waar hashing je tegen beschermt

1. Directe openbaarmaking van wachtwoorden na een database-inbraak

Als een aanvaller een database met wachtwoorden in plaintext steelt, is de schade onmiddellijk. Elk wachtwoord is blootgesteld. Gebruikers lopen niet alleen risico op jouw site, maar overal waar ze dat wachtwoord hebben hergebruikt.

Als de database goed gehashte wachtwoorden bevat, heeft de aanvaller meer werk te doen. Die moet kandidaat-wachtwoorden raden, elke gok hashen met de juiste salt en parameters, en het resultaat vergelijken.

Voor zwakke wachtwoorden kan dit nog steeds snel gaan. Voor sterke, unieke wachtwoorden kan het onpraktisch zijn.

Hashing verandert een catastrofale openbaarmaking in een race: kunnen gebruikers hun wachtwoorden resetten en kun jij het incident indammen voordat aanvallers er veel kraken?

Dat is niet perfect. Het is nog steeds een inbraak. Maar het is een drastisch betere faalmodus.

2. Bulkaanvallen op je volledige gebruikersbestand

Salts zijn een belangrijk onderdeel van wachtwoordopslag omdat ze voorkomen dat aanvallers veel gebruikers tegelijk efficiënt aanvallen met vooraf berekende tabellen.

Een salt is niet geheim. Die wordt naast de hash opgeslagen. De taak ervan is uniciteit.

Als twee gebruikers hetzelfde wachtwoord kiezen, zorgen unieke salts ervoor dat hun opgeslagen hashes verschillen. Dat voorkomt dat aanvallers in één oogopslag zien dat veel gebruikers hetzelfde wachtwoord delen. Het voorkomt ook klassieke rainbow table-aanvallen, waarbij aanvallers enorme vooraf berekende lijsten met wachtwoord-naar-hash-koppelingen gebruiken.

Zonder salts kan één gekraakte hash elke gebruiker met hetzelfde wachtwoord onthullen. Met salts moet elke wachtwoordgok voor elke gebruiker afzonderlijk worden getest.

3. Snel offline raden

Zodra aanvallers een wachtwoorddatabase hebben, kunnen ze offline raden. Dat betekent dat je login-rate limits, CAPTCHA, IP-blokkering en monitoring er niet meer toe doen. De aanvaller kan gokpogingen testen op eigen hardware.

Hier wordt de keuze van het algoritme belangrijk.

Algemene hashes zoals SHA-256 en SHA-512 zijn ontworpen om snel te zijn. Dat is goed voor bestandsintegriteit en digitale handtekeningen. Het is slecht voor wachtwoordopslag.

Algoritmen voor wachtwoordhashing zijn ontworpen om traag, instelbaar en soms memory-hard te zijn. Argon2id, bcrypt, scrypt en PBKDF2 laten je allemaal kostenparameters aanpassen zodat elke gok betekenisvolle tijd kost.

Argon2id wordt breed aanbevolen voor nieuwe systemen omdat het zo kan worden geconfigureerd dat het zowel CPU-tijd als geheugen vereist, wat grootschalig kraken met GPU's duurder maakt. bcrypt blijft veelgebruikt en acceptabel wanneer het goed is geconfigureerd, al heeft het beperkingen zoals de verwerking van wachtwoordlengte. PBKDF2 wordt nog steeds gebruikt in sommige compliance-gedreven omgevingen, vooral waar FIPS-gevalideerde componenten vereist zijn.

Het principe is eenvoudig: maak legitieme logins acceptabel snel, terwijl je miljarden gokpogingen duur maakt.

Waar hashing je niet tegen beschermt

1. Phishing

Als een gebruiker zijn wachtwoord intypt op een valse loginpagina, helpt hashing op jouw server niet. De aanvaller ontvangt het wachtwoord voordat jouw systeem het ooit ziet.

De verdedigingen hier zijn anders: multi-factor authentication, passkeys, gebruikerseducatie, domeinhygiëne, phishingbestendige authenticatie en zorgvuldige wachtwoordresetflows.

Wachtwoordhashing is een vangnet voor opgeslagen geheimen. Het is geen verdediging tegen gebruikers die worden misleid om die geheimen prijs te geven.

2. Credential stuffing

Credential stuffing gebeurt wanneer aanvallers gebruikersnaam-wachtwoordparen nemen die bij de ene dienst zijn gelekt en ze op een andere proberen.

Je wachtwoordhashes kunnen uitstekend zijn, en credential stuffing kan nog steeds werken als gebruikers wachtwoorden hergebruiken.

Dit is een online aanval op je loginformulier, geen offline aanval op je database. Je hebt rate limiting, anomaliedetectie, controles op gelekte wachtwoorden, MFA en verstandige lockout policies nodig die geen eenvoudige denial-of-service-mogelijkheden creëren.

Dezelfde praktische manier van denken geldt voor elk blootgesteld formulier. Als je je authenticatieoppervlak beoordeelt, is het de moeite waard om te lezen waarom je contactformulier je grootste spamrisico is; de mechanismen verschillen, maar de les is vergelijkbaar: publieke inputs hebben misbruikbeperking nodig, niet alleen schone backendcode.

3. Wachtwoorden die in logs of analytics terechtkomen

Hashing helpt alleen als het plaintext-wachtwoord snel wordt weggegooid en nooit ergens anders naartoe wordt gekopieerd.

Veelvoorkomende fouten zijn onder meer:

• Volledige request bodies loggen bij mislukte loginpogingen.
• Wachtwoorden naar tools voor foutmonitoring sturen.
• Wachtwoordvelden vastleggen in sessiereplayproducten.
• Inloggegevens opnemen in URLs tijdens slecht ontworpen reset- of migratieflows.
• Tijdelijke plaintext-wachtwoorden opslaan tijdens imports.

Deze fouten omzeilen wachtwoordhashing volledig. Als plaintext in logs, back-ups, datawarehouses of tools van derden belandt, is je hashfunctie irrelevant.

Behandel wachtwoordvelden als toxische data. Redigeer ze voordat je logt. Sluit ze uit van analytics. Houd ze uit URLs. Beperk wie productietraces kan benaderen.

4. Slechte sessiebeveiliging

Na het inloggen ontvangt de browser van de gebruiker meestal een sessiecookie of token. Als dat token wordt gestolen, heeft de aanvaller het wachtwoord mogelijk helemaal niet nodig.

Wachtwoordhashing beschermt niet tegen cross-site scripting, onveilige cookies, session fixation, zwakke tokengeneratie of te lange sessieduur.

Sessiecookies verdienen hun eigen review: HttpOnly, Secure, passende SameSite, kortlevende sessies voor hoog risico en server-side invalidatie bij wachtwoordwijzigingen. Het bredere privacy- en browserlandschap blijft ook verschuiven, zoals besproken in wat er in 2026 voor cookies veranderde.

5. Zwakke wachtwoordreset en accountherstel

Veel accountovernames beginnen niet met het wachtwoord. Ze beginnen met de resetflow.

Als resettokens voorspelbaar, langlevend, gelekt via referrer headers of naar gecompromitteerde e-mailaccounts verzonden zijn, redt wachtwoordhashing je niet.

Gebruik resettokens met hoge entropie, korte vervalvensters, eenmalig gebruik en duidelijke gebruikersmeldingen. Omdat e-mail vaak het herstelkanaal is, is basale domeinauthenticatie ook belangrijk. Als je team DNS-records als mysterieuze ceremonie behandelt, begin dan met een ontwikkelaarsvriendelijke rondleiding door MX, SPF, DKIM en DMARC.

De algoritmekeuze: wat je nu moet gebruiken

Gebruik voor nieuwe applicaties Argon2id als je platform het goed ondersteunt. Het is de winnaar van de Password Hashing Competition en is ontworpen voor wachtwoordopslag, inclusief weerstand tegen GPU-zwaar kraken.

Een redelijke moderne hiërarchie ziet er zo uit:

1. Argon2id voor nieuwe systemen waar beschikbaar.
2. bcrypt wanneer Argon2id niet praktisch is en bcrypt-ondersteuning volwassen is.
3. scrypt wanneer memory-hard configuratie goed wordt ondersteund.
4. PBKDF2 waar platform- of compliancebeperkingen dat vereisen.

Vermijd gewone SHA-256, SHA-512, MD5 of een zelfgemaakte combinatie zoals sha256(password + salt). Snelle hashes zijn geen functies voor wachtwoordopslag. Slimme maatwerkconstructies zijn meestal slechter dan saaie standaardoplossingen.

Vermijd ook het bedenken van je eigen wachtwoordbeleid rond algoritmetrivia. Gebruikers hebben geen baat bij een checklist met 12 regels voor wachtwoordsamenstelling als die hen richting voorspelbare patronen duwt. Langere unieke wachtwoorden, wachtwoordmanagers, screening op gelekte wachtwoorden en MFA zijn meestal belangrijker.

Kostenfactoren zijn niet instellen-en-vergeten

Wachtwoordhashing heeft parameters. Argon2id heeft geheugen, iteraties en parallellisme. bcrypt heeft een cost factor. PBKDF2 heeft een iteratieaantal.

Deze waarden moeten worden gekozen op basis van je productieomgeving. Te laag, en aanvallers raden goedkoop. Te hoog, en je loginsysteem wordt traag of kwetsbaar voor denial-of-service.

Een praktisch doel ligt vaak in de orde van tientallen tot enkele honderden milliseconden per wachtwoordverificatie op je daadwerkelijke servers, afhankelijk van verkeer en risico. Hoogbeveiligde systemen kunnen meer kiezen. Systemen op consumenten­schaal hebben mogelijk zorgvuldige capaciteitsplanning nodig.

Kopieer geen cost factor uit een vijf jaar oude blogpost. Hardware verandert. Libraries veranderen. Je verkeer verandert.

Bekijk parameters periodiek opnieuw en plan voor rehashing. Een gangbaar patroon is om het algoritme en de parameters bij elke hash op te slaan. Bij een succesvolle login, als de opgeslagen parameters verouderd zijn, hash je het ingevoerde wachtwoord opnieuw met de nieuwere configuratie en werk je het record bij.

Peppers: nuttig, maar geen vervanging

Een pepper is een geheime waarde die aan het proces voor wachtwoordhashing wordt toegevoegd en apart van de database wordt opgeslagen, vaak in een secrets manager of hardware security module.

In tegenstelling tot een salt moet een pepper geheim blijven.

Peppers kunnen schade beperken als de database lekt maar applicatiegeheimen niet. Ze zijn het nuttigst in volwassen omgevingen met goed sleutelbeheer. Ze zijn minder nuttig als dezelfde aanvaller zowel de database als de applicatieconfiguratie kan stelen.

Als je een pepper gebruikt, plan rotatie dan zorgvuldig. Rotatie kan vereisen dat gebruikers opnieuw inloggen of wachtwoorden resetten, afhankelijk van het ontwerp. Een pepper is een extra laag, geen reden om de onderliggende hashinstellingen te verzwakken.

De operationele checklist

Als je verantwoordelijk bent voor een echt systeem, is de praktische checklist kort:

• Sla wachtwoorden alleen op met een standaardalgoritme voor wachtwoordhashing.
• Gebruik een unieke willekeurige salt per wachtwoord.
• Geef de voorkeur aan Argon2id voor nieuwe builds.
• Stem kostenparameters af op productieachtige hardware.
• Sla algoritme en parameters bij elke hash op.
• Rehash bij login wanneer parameters verouderd raken.
• Log nooit wachtwoorden en stuur ze niet naar analytics-tools.
• Gebruik TLS overal waar inloggegevens worden ingediend.
• Voeg MFA of passkeys toe waar het risico dat rechtvaardigt.
• Bescherm resetflows net zo serieus als loginflows.
• Zorg voor een incidentplan voor geforceerde resets en gebruikersmeldingen.

Wachtwoordhashing is niet glamoureus. Het is loodgieterswerk. Maar het is het soort loodgieterswerk dat bepaalt of een inbraak een pijnlijk incident wordt of een ramp voor alle gebruikers.

<!-- tool-cta:start -->

💡 Probeer dit: Zie hoe dezelfde invoer met de Hash Generator aan verschillende algoritmen wordt gekoppeld, waardoor het verschil tussen snelle hashes en hashes op wachtwoordniveau concreet wordt.

<!-- tool-cta:end -->

Het eerlijke mentale model

De beste manier om over wachtwoordhashing te denken is dit:

Hashing beschermt het wachtwoord niet terwijl de gebruiker het typt. Het beschermt het account niet nadat de gebruiker is ingelogd. Het beschermt gebruikers niet die wachtwoorden op het web hergebruiken.

Het beschermt de opgeslagen verificatiewaarde.

Dat klinkt smal, maar het is buitengewoon belangrijk. Databases lekken. Back-ups lekken. Staging-systemen worden gekopieerd. Leveranciers krijgen toegang die ze niet zouden moeten hebben. Oude exports blijven langer in objectopslag staan dan iemand zich herinnert.

Wanneer dat gebeurt, wordt je ontwerp voor wachtwoordopslag het verschil tussen aanvallers die wachtwoorden ontvangen en aanvallers die een duur raadprobleem ontvangen.

Dat is waartegen het hashen van een wachtwoord je eigenlijk beschermt.