De juiste manier om wachtwoorden op te slaan: hashing, salting en bcrypt versus Argon2 versus PBKDF2

Kort antwoord: Veilige wachtwoordopslag betekent dat elk wachtwoord wordt gehasht met een unieke, willekeurige salt met behulp van een traag, geheugenintensief algoritme, en nooit in platte tekst of omkeerbare encryptie wordt opgeslagen. Gebruik voor nieuwe systemen Argon2id met de huidige OWASP-parameters; behoud voor oudere systemen bcrypt met een kostenfactor van minimaal 12; gebruik PBKDF2 alleen waar FIPS-validatie dit vereist. De aanbevolen actie: controleer uw huidige hash-algoritme en parameters vandaag nog, aangezien dit een cryptografische implementatiebeslissing is die gemakkelijk ongemerkt verkeerd kan worden genomen.

Gepubliceerd: juni 2026 | Bijgewerkt: augustus 2026 | Beoordeeld door het cryptografie-adviessteam van Encryption Consulting

De meeste mensen denken er na het klikken op 'Aanmelden' nooit over na hoe hun wachtwoorden worden opgeslagen. Ze vertrouwen er gewoon op dat bedrijven er op de juiste manier mee omgaan. Maar dat vertrouwen is niet altijd terecht. Wachtwoordopslag is een van de meest voorkomende fouten in de applicatiebeveiliging, en de gevolgen van een verkeerde aanpak kunnen ernstig zijn.

Elk jaar worden miljoenen gebruikersgegevens gelekt. In veel gevallen waren die gegevens opgeslagen op een manier die het kraken ervan gemakkelijk maakte. Geen salting, zwakke hashes , soms zelfs platte tekst. Dit zijn geen uitzonderingen. Het zijn terugkerende problemen die echte gebruikers treffen.

Dit artikel legt uit hoe veilige wachtwoordopslag er in de praktijk uitziet, van de basisprincipes van hashing en salting tot een praktische vergelijking van bcrypt, Argon2 en PBKDF2. Als u een authenticatiesysteem bouwt of evalueert, is dit een goed startpunt.

Waarom veilige wachtwoordopslag belangrijk is

Wanneer aanvallers een wachtwoordendatabase stelen, hebben ze niet direct alle wachtwoorden in handen. Wat ze wel hebben, is een set opgeslagen representaties. Als die correct zijn aangemaakt, zijn de gegevens grotendeels nutteloos voor hen. Zo niet, dan kunnen ze binnen enkele uren duizenden echte wachtwoorden achterhalen.

Het risico beperkt zich niet tot één account. Mensen hergebruiken wachtwoorden voor verschillende diensten. Een gekraakt wachtwoord van een ogenschijnlijk onschuldige app kan toegang geven tot e-mailaccounts, bankrekeningen of bedrijfssystemen. Deze kettingreactie is de reden waarom zelfs kleine applicaties verantwoordelijkheid dragen voor de algehele beveiliging van hun gebruikers.

Er is ook een compliance-aspect. Kaderwerken zoals NIST SP 800-63B, GDPR en PCI-DSS stellen allemaal eisen aan de bescherming van authenticatiegegevens. Slechte wachtwoordopslag is zowel een technische als een wettelijke overtreding, met mogelijke boetes en reputatieschade tot gevolg.

Op welke beveiligingsveronderstellingen is deze analyse gebaseerd?

Elke aanbeveling in dit bericht gaat uit van een specifiek dreigingsmodel: een aanvaller die de wachtwoorddatabase offline heeft verkregen, via een datalek, een medewerker of een verkeerd geconfigureerde back-up, en die onbeperkt kan proberen wachtwoorden te raden zonder snelheidsbeperking, accountblokkering of monitoring. Dit is de juiste aanname om rekening mee te houden bij het ontwerpen, omdat online snelheidsbeperking een controlemechanisme is dat kan falen of omzeild kan worden, terwijl offline kraakbestendigheid een eigenschap is van de opgeslagen gegevens zelf.

De analyse gaat er ook van uit dat de aanvaller toegang heeft tot standaard GPU-hardware, en niet tot een ASIC-farm van een natiestaat; dat wachtwoorden afkomstig zijn van echt gebruikersgedrag, wat betekent dat een aanzienlijk deel kort, op een woordenboek gebaseerd of hergebruikt is, en niet uniform willekeurig; en dat de salt openbaar is (opgeslagen naast de hash, zoals het hoort), zodat de kosten van het algoritme, en niet de geheimhouding van de salt, de aanval moeten weerstaan.

Inzicht in hashing en wachtwoordsalting

Een cryptografische hashfunctie neemt een wachtwoord als invoer en produceert een uitvoer van vaste lengte, een zogenaamde hash of digest. De belangrijkste eigenschap is dat dit proces slechts in één richting werkt. Je kunt een hash niet terugdraaien om het oorspronkelijke wachtwoord te achterhalen. Daarom slaan systemen in plaats van wachtwoorden direct op, hun hashes op. Bij het inloggen wordt het ingevoerde wachtwoord gehasht en vergeleken met de opgeslagen hash.

Dit klinkt veilig genoeg. Maar algemene hashfuncties zoals MD5 en SHA-256 zijn ontworpen voor snelheid, niet voor wachtwoorden. Een moderne GPU kan miljarden SHA-256-hashes per seconde berekenen. Die snelheid is een voordeel voor aanvallers die brute-force- of woordenboekaanvallen uitvoeren.

Password salting pakt een specifieke aanval aan: rainbow tables. Een rainbow table is een vooraf berekende opzoektabel van hashes voor veelgebruikte wachtwoorden. Een aanvaller kan een gestolen hash gebruiken en deze binnen enkele seconden opzoeken zonder enige berekening uit te voeren.

Een salt is een unieke, willekeurig gegenereerde tekenreeks die aan elk wachtwoord wordt toegevoegd voordat het wordt gehasht. Zelfs als twee gebruikers hetzelfde wachtwoord hebben, zorgen hun salts ervoor dat de resulterende hashes volledig verschillend zijn. Dit maakt rainbow tables nutteloos en dwingt aanvallers om elke hash afzonderlijk te kraken.

Salts zijn niet geheim. Ze worden samen met de hash opgeslagen. Hun waarde komt voort uit het feit dat ze uniek en willekeurig zijn, niet uit het feit dat ze verborgen zijn. Salting is geen encryptie. Het is een manier om aanvallen met voorberekening te voorkomen.

Een uitgewerkt voorbeeld: Waarom de keuze van een algoritme alles verandert

Cijfers maken het verschil concreet. Neem een ​​wachtwoord van 8 tekens, bestaande uit alleen kleine letters, wat neerkomt op ongeveer 208 miljard mogelijke combinaties. Een moderne consumenten-GPU kan tot wel 10 miljard ongezouten SHA-256-hashes per seconde berekenen. Dit betekent dat de sleutelruimte binnen een minuut uitgeput is, met of zonder zout. Het toevoegen van zout voorkomt namelijk dat vooraf berekende regenboogtabellen worden gegenereerd, maar vertraagt ​​een brute-force-aanval per hash tegen snelle hashes niet.

Voer dezelfde aanval uit op een wachtwoord dat is opgeslagen met Argon2id volgens de door OWASP aanbevolen basislijn (46 MiB geheugen, 1 iteratie, 1 graad van parallellisatie), en het beeld verandert. Dezelfde GPU die 10 miljard SHA-256-hashes per seconde berekende, wordt nu beperkt door de geheugenbandbreedte, niet door de pure rekenkracht, en kan met die geheugenkosten doorgaans slechts een paar duizend Argon2id-hashes per seconde verwerken. Dezelfde 208 miljard combinaties die met pure SHA-256 minder dan een minuut duurden, kosten nu maanden tot jaren aanhoudende GPU-tijd. Om de aanval op te schalen, is voldoende hardware met een equivalent geheugen nodig om veel instanties parallel te draaien, wat veel duurder is dan het toevoegen van GPU-cores. Dat verschil, en niet een verschil in wiskundige kracht, is de hele reden waarom geheugenintensieve algoritmen bestaan.

bcrypt uitgelegd: sterke en zwakke punten en wanneer je het moet gebruiken.

bcrypt werd in 1999 speciaal ontwikkeld voor het hashen van wachtwoorden. Het bevat automatische salting en een configureerbare kostenfactor, ook wel werkfactor genoemd, die bepaalt hoe rekenintensief het hashen is. Hoe hoger de kostenfactor, hoe langer de tijd die nodig is per hash, wat aanvallers die op grote schaal wachtwoorden proberen te kraken, vertraagt.

Sterke punten:

• Ingebouwde zouttoevoer: bcrypt genereert en bewaart automatisch een unieke salt voor elk wachtwoord, waardoor een veelvoorkomende foutbron voor ontwikkelaars wordt geëlimineerd.
• Adaptieve kostenfactor: Naarmate de hardware verbetert, kunt u de werkfactor verhogen om de weerstand tegen aanvallen te behouden.
• In de praktijk beproefd: Na meer dan 25 jaar onderzoek zijn er geen fundamentele kwetsbaarheden gevonden.
• Brede ondersteuning: Beschikbaar in vrijwel alle belangrijke programmeertalen en frameworks.

Beperkingen:

• Limiet van 72 tekens: bcrypt kort invoerwaarden langer dan 72 bytes in. Dit kan een probleem vormen bij lange wachtzinnen als hier niet correct mee wordt omgegaan.
• Geen geheugenhardheid: bcrypt vereist geen significant RAM-geheugen, waardoor het kwetsbaarder is voor zeer parallelle hardwareaanvallen in vergelijking met nieuwere opties.

Argon2 vs. PBKDF2 vs. bcrypt: belangrijke verschillen

Niet alle wachtwoord-hashalgoritmes bieden dezelfde mate van bescherming. Hieronder een vergelijking van de drie belangrijkste opties op basis van de belangrijkste factoren.

Kenmerk	bcrypt	argonxnumx	PBKDF2
Geheugenhardheid	Niet moeilijk te onthouden	Geheugenintensief met configureerbaar RAM-gebruik	Niet moeilijk te onthouden
Ingebouwde zouttoevoer	Ja, automatisch	Ja, automatisch	Nee, moet handmatig worden afgehandeld.
Parallelismecontrole	Niet ondersteund	Ondersteund via Argon2id	Niet ondersteund
Maximale wachtwoordlengte	Beperkt tot 72 bytes	Geen limiet	Geen limiet
NIST aanbevolen	Niet vermeld in SP 800-63B	Ja	Ja
GPU-weerstand	Gemiddeld	Hoge	Laag tot matig
Volwassenheid	Meer dan 25 jaar	Beschikbaar sinds 2015	Beschikbaar sinds 2000

Argon2: De moderne standaard

Argon2 won de Password Hashing Competition in 2015 en wordt aanbevolen door NIST in SP 800-63B. Het is verkrijgbaar in drie varianten. Argon2d is bestand tegen GPU-aanvallen. Argon2i is bestand tegen side-channel-aanvallen. Argon2id combineert beide en is de aanbevolen keuze voor de meeste scenario's voor wachtwoordopslag.

Wat Argon2 onderscheidt, is de geheugenhardheid. Het vereist een configureerbare hoeveelheid RAM tijdens de berekening. Dit maakt parallelle aanvallen op gespecialiseerde hardware zoals ASIC's of FPGA's aanzienlijk duurder. Meer geheugen betekent minder gelijktijdige kraakpogingen die een aanvaller kan uitvoeren. De huidige richtlijnen van OWASP vermelden 46 MiB geheugen met 1 iteratie en 1 graad van parallellisme als de voorkeursbasis, met een slankere configuratie van 19 MiB en 2 iteraties als een acceptabel alternatief voor omgevingen met beperkt geheugen.

PBKDF2: De nalevingsoptie

PBKDF2 is de oudste van de drie en wordt veel gebruikt in FIPS-gevalideerde omgevingen omdat het is gebaseerd op goedgekeurde HMAC- constructies. Als uw organisatie FIPS 140-2 of 140-3 compliance vereist, wat gebruikelijk is in de federale en gereguleerde financiële sector, kan PBKDF2 met SHA-256 of SHA-512 vereist zijn. Het mist geheugenhardheid, waardoor het de zwakste van de drie is tegen hardwareaanvallen. Compenseer dit met een hoog aantal iteraties: de huidige richtlijnen schrijven ten minste 600,000 iteraties voor met HMAC-SHA-256, of ongeveer 210,000 iteraties met de rekenkundig duurdere HMAC-SHA-512.

Wat zijn de beperkingen van op hashing gebaseerde wachtwoordopslag?

• Hashing beschermt de opgeslagen database, maar biedt geen bescherming tegen credential stuffing, phishing of hergebruik van wachtwoorden; een correct gehasht wachtwoord dat via een phishingpagina wordt gestolen, is hoe dan ook gecompromitteerd, ongeacht het algoritme.
• De sterkte van een algoritme kan zwakke gebruikerswachtwoorden niet compenseren; een veelvoorkomend woord dat door Argon2id wordt beschermd, is nog steeds te kraken met een gerichte woordenboekaanval, alleen langzamer dan met een snelle hashfunctie.
• Het verhogen van de geheugenkosten of het aantal iteraties verhoogt het servergebruik tijdens het inloggen. Parameteroptimalisatie is daarom een ​​echte afweging in de capaciteitsplanning, geen gratis beveiligingsupgrade.
• Het overzetten van een bestaande gebruikersgroep naar een nieuw algoritme kan niet direct gebeuren, omdat oude hashes niet kunnen worden geconverteerd zonder het wachtwoord in platte tekst; de migratie moet geleidelijk plaatsvinden, bij elke volgende succesvolle aanmelding van een gebruiker.

Welk algoritme moet u gebruiken? Een beslissingstabel voor bedrijven

Scenario	Aanbevolen algoritme	Voorgestelde parameters
Nieuwe applicatie, geen beperkingen door bestaande systemen.	Argon2id	46 MiB geheugen, 1 iteratie, 1 graad van parallellisme (OWASP-basislijn)
Het bestaande systeem maakt al gebruik van bcrypt.	Behoud bcrypt, plan de migratie.	Kostenfactor van minimaal 12; herhash naar Argon2id bij volgende aanmelding
FIPS 140-2/140-3 gevalideerde omgeving	PBKDF2-HMAC-SHA256	Minimaal 600,000 iteraties, unieke willekeurige salt per wachtwoord
Model voor doelwitten van hoge waarde / verhoogde dreiging	Argon2id, hogere geheugenkosten	64 MiB of meer, afgestemd op een acceptabele inloglatentie op uw hardware.
Resourcebeperkt (mobiel, ingebed, serverloos)	Argon2id, slanker profiel	19 MiB geheugen, 2 iteraties, 1 graad van parallellisme

Aanbevolen werkwijzen voor het veilig opslaan van wachtwoorden

Het kiezen van het juiste algoritme is slechts het begin. Een degelijke implementatie moet het volgende omvatten:

• Kies het juiste algoritme: Gebruik Argon2id voor nieuwe systemen. Behoud bcrypt voor bestaande systemen met een kostenfactor van 12 of hoger. Gebruik PBKDF2 alleen wanneer naleving dit vereist.
• Stel uw parameters in: Voor Argon2id adviseert OWASP 46 MiB geheugen, 1 iteratie en 1 graad van parallellisatie als basisvereisten. Pas deze waarden naar boven aan op basis van de capaciteit van uw server en de acceptabele inloglatentie.
• Gebruik altijd unieke, willekeurige zouten: Zelfs als uw bibliotheek automatisch salting afhandelt, is het belangrijk te weten dat dit wel degelijk het geval is. Gebruik nooit statische waarden of opeenvolgende identificatoren als salts.
• Sterke wachtwoorden afdwingen: Hashing vervangt geen goed wachtwoordbeleid. Stel minimale lengtes in, weiger wachtwoorden waarvan bekend is dat ze gelekt zijn en ondersteun multifactorauthenticatie.
• Aparte opslag van inloggegevens: Bewaar wachtwoordhashes in een speciale opslag met strikte toegangscontrole. Applicaties mogen alleen toegang krijgen tot de inloggegevens tijdens de authenticatie.
• Plan voor algoritmemigratie: Ontwerp je systeem zo dat de inloggegevens bij de volgende aanmelding opnieuw worden gegenereerd. Hierdoor kun je algoritmes of parameters upgraden zonder een massale wachtwoordreset te hoeven uitvoeren.

Hoe encryptieconsultancy kan helpen

Het correct opslaan van wachtwoorden is een cruciale beslissing op het gebied van cryptografische implementatie. Net als bij de meeste cryptografische beslissingen is het gemakkelijk om fouten te maken die niet direct zichtbaar zijn. Een verkeerd algoritme, een ontbrekende salt, een onvoldoende aantal iteraties of een FIPS-incompatibele implementatie kunnen er aan de oppervlakte prima uitzien, terwijl ze uw organisatie stilletjes blootstellen aan ernstige risico's. Dat is waar de adviesdiensten van Encryption Consulting op het gebied van encryptie van pas komen.

Ons team helpt organisaties bij het beoordelen en versterken van hun cryptografische implementaties in cloud-, on-premises- en hybride omgevingen. Of u nu een nieuw authenticatiesysteem bouwt, een bestaand systeem evalueert of zich voorbereidt op een compliance-audit volgens PCI-DSS, NIST SP 800-63B of GDPR, wij beschikken over de expertise om te evalueren wat er daadwerkelijk aanwezig is en de praktische ervaring om u te helpen eventuele problemen op te lossen.

Hier komen onze adviesdiensten op het gebied van encryptie direct van pas bij de opslag van wachtwoorden en de beveiliging van authenticatie:

Evaluatie van cryptografische implementatie: We beoordelen uw huidige implementatie voor wachtwoordopslag, inclusief de keuze van algoritmen, salting-methoden, parameteroptimalisatie en de manier waarop inloggegevens worden gescheiden en de toegang ertoe wordt gecontroleerd. Dit geeft u een duidelijk beeld van waar de zwakke punten zich bevinden voordat een inbreuk of audit deze aan het licht brengt.

Algoritmekeuze en migratieplanning: De overstap van bcrypt naar Argon2id, of van een verouderde PBKDF2-implementatie naar een implementatie die voldoet aan de huidige NIST-aanbevelingen voor het aantal iteraties, vereist zorgvuldige planning om te voorkomen dat bestaande authenticatieprocessen worden verstoord. Wij ontwerpen migratiepaden die de inloggegevens bij de volgende aanmelding geleidelijk opnieuw hashen, zonder gedwongen wachtwoordresets en zonder verstoring voor de gebruiker.

FIPS-naleving: Voor organisaties die actief zijn in federale of gereguleerde financiële omgevingen waar FIPS 140-2- of 140-3-validatie vereist is, helpen wij u bij het selecteren en configureren van PBKDF2-implementaties die voldoen aan de nalevingsvereisten en tegelijkertijd de zwakkere hardwarebestendigheid van het algoritme compenseren door middel van een juiste parameterconfiguratie.

Compliance-analyse: Frameworks zoals PCI-DSS, GDPR en NIST SP 800-63B stellen allemaal eisen aan de bescherming van authenticatiegegevens. Wij brengen uw huidige implementatie in kaart aan de hand van deze eisen, identificeren tekortkomingen en stellen een duidelijk stappenplan op voor verbetering.

Slechte wachtwoordopslag is een van de meest voorkomende en tegelijkertijd meest vermijdbare beveiligingsfouten. Als uw organisatie de procedures voor het beheer van inloggegevens nog niet formeel heeft geëvalueerd, is dit het juiste moment.

Conclusie

Het opslaan van wachtwoorden is geen aantrekkelijk onderwerp, maar wel essentieel. De keuzes die op dataniveau worden gemaakt, bepalen of een inbreuk een beperkt incident blijft of een veel groter probleem wordt. Elke andere beveiligingsmaatregel in een applicatie is uiteindelijk afhankelijk van hoe inloggegevens worden opgeslagen, en gezien hoe vaak mensen wachtwoorden hergebruiken, reikt de schade van een zwakke implementatie vaak veel verder dan de oorspronkelijke applicatie.

Wat dit gebied lastig maakt, is dat de gevolgen zelden zichtbaar zijn totdat er iets misgaat. Een zwakke hashing-keuze vertraagt ​​de prestaties niet en activeert geen waarschuwingen. Het blijft onopgemerkt in productie totdat er een inbreuk plaatsvindt en aanvallers de opgeslagen hashes beginnen te kraken. Het goede nieuws is dat de richtlijnen hier niet dubbelzinnig zijn. NIST heeft duidelijke aanbevelingen gepubliceerd en er bestaan ​​volwaardige bibliotheken in elke belangrijke programmeertaal om deze algoritmen correct te implementeren.

De weg vooruit is duidelijk. Gebruik Argon2id voor nieuwe implementaties. Onderhoud bcrypt op een verantwoorde manier voor bestaande systemen met een kostenfactor van minimaal 12. Grijp alleen naar PBKDF2 wanneer compliance dit vereist, en compenseer dit met een hoog aantal iteraties. Voeg altijd een salt toe, optimaliseer altijd uw parameters en plan vanaf het begin voor toekomstige algoritmemigraties. Beschouw dit als een doorlopende praktijk, niet als een eenmalige instelling.

Veelgestelde Vragen / FAQ

Welk wachtwoord-hashalgoritme moet een nieuw project gebruiken?

Argon2id maakt gebruik van de huidige OWASP-standaard van 46 MiB geheugen, 1 iteratie en 1 graad van parallellisatie. Het is geheugenintensief, wordt aanbevolen door NIST en heeft geen praktische limiet voor de wachtwoordlengte.

Is bcrypt nog steeds veilig om te gebruiken?

Ja, met een kostenfactor van minstens 12. bcrypt is al meer dan 25 jaar aan een grondig onderzoek onderworpen zonder fundamentele fouten, maar het mist geheugenbestendigheid. Daarom zouden nieuwe systemen de voorkeur moeten geven aan Argon2id wanneer er geen beperkingen zijn ten aanzien van bestaande systemen.

Waarom is het toevoegen van zout alleen niet voldoende om snelle brute-force-aanvallen te stoppen?

Het toevoegen van een zoutwaarde maakt vooraf berekende regenboogtabellen onbruikbaar door elke hash uniek te maken, maar vertraagt ​​de berekening per hash zelf niet. Een snelle, niet-gezouten hashfunctie zoals de ruwe SHA-256 kan zelfs met een unieke zoutwaarde nog steeds snel per wachtwoord worden gekraakt; alleen een opzettelijk traag en geheugenintensief algoritme is daartegen bestand.

Wanneer is PBKDF2 een betere keuze dan Argon2id?

Wanneer validatie volgens FIPS 140-2 of 140-3 een harde vereiste is, aangezien PBKDF2 is gebouwd op goedgekeurde HMAC-constructies die Argon2 momenteel niet heeft, compenseer dan het gebrek aan geheugenhardheid met ten minste 600,000 iteraties van HMAC-SHA-256.

Hoe moet een organisatie overstappen van een ouder algoritme naar Argon2id?

Bij elke volgende succesvolle aanmelding van een gebruiker: controleer eerst de oude hash, genereer vervolgens een nieuwe hash met Argon2id en sla de nieuwe hash op. Dit voorkomt een gedwongen massale wachtwoordreset tijdens de geleidelijke migratie.

Referenties

• OWASP-spiekbriefje voor wachtwoordopslag
• NIST SP 800-63B, Richtlijnen voor digitale identiteit