bcrypt vs Argon2 uitgelegd: vergelijk beveiligingseigenschappen, echte prestatiekosten en hoe je veilige parameters kiest voor moderne webbackends.
Wachtwoordhashing laat een backend een wachtwoord bewaren zonder het wachtwoord zelf op te slaan. Wanneer iemand zich aanmeldt, laat de server het wachtwoord door een eenrichtingsfunctie lopen en bewaart het resultaat (de hash). Bij het inloggen hasht de server het door de gebruiker ingetypte wachtwoord en vergelijkt het resultaat met wat is opgeslagen.
Een hash is geen encryptie. Je kunt het niet ontsleutelen. Die eenrichtings-eigenschap is precies waarom hashing voor wachtwoorden wordt gebruikt.
Waarom dan geen gewone snelle hash zoals SHA-256 gebruiken? Omdat snel precies is wat aanvallers willen. Als een database wordt gestolen, raden aanvallers wachtwoorden niet één voor één via inloggen. Ze raden offline met de gestolen hashlijst en duwen pogingen zo snel als hun hardware toelaat. Met GPU's kunnen snelle hashes enorm snel getest worden. Zelfs met unieke salts blijft een snelle hash goedkoop om te bruteforcen.
Een realistisch faalpad: een kleine webapp verliest zijn gebruikers tabel in een breach. De aanvaller krijgt e-mails en wachtwoordhashes. Als die hashes met een snelle functie waren gemaakt, vallen veel voorkomende wachtwoorden en kleine variaties snel. Vervolgens probeert de aanvaller hetzelfde wachtwoord op andere sites (credential stuffing), of gebruikt het om toegang te krijgen tot hoger-geprivilegeerde functies binnen je app.
Een goede wachtwoordhash maakt raden duur. Het doel is niet “onbreekbaar.” Het doel is “te langzaam en te duur om de moeite waard te zijn.”
Een wachtwoord-hashing setup moet zijn:
Wanneer je bcrypt vs Argon2 vergelijkt, kies je hoe je wachtwoordgissingen wilt vertragen na een databaselek.
bcrypt is de oudere, breed ondersteunde optie. Het is ontworpen om CPU-intensief te zijn en heeft één hoofd-afstemmingsknop: de cost factor. Het is ook “saai” op een goede manier: makkelijk te vinden in libraries, eenvoudig te deployen en voorspelbaar.
Argon2 is nieuwer en is ontworpen om geheugen-intensief te zijn. Het kan elke wachtwoordpoging dwingen een noemenswaardige hoeveelheid RAM te gebruiken, niet alleen CPU. Dat is belangrijk omdat aanvallers vaak winnen door enorme aantallen pogingen parallel op GPU's of gespecialiseerde hardware te draaien. Geheugen is moeilijker en duurder te schalen bij dat soort parallelisme.
Argon2 heeft drie varianten:
Als je stack Argon2id ondersteunt en je geheugen veilig kunt afstemmen, is het meestal de beste moderne standaard. Als je maximale compatibiliteit over oudere systemen nodig hebt, is bcrypt nog steeds een solide keuze wanneer je een hoge genoeg cost factor instelt.
De kernvraag is simpel: als een aanvaller de wachtwoorddatabase steelt, hoe duur is het om wachtwoorden op schaal te raden?
Met bcrypt controleer je de cost (work factor). Hogere cost betekent dat elke poging langer duurt. Dat vertraagt aanvallers en vertraagt ook je eigen loginchecks, dus je stemt het af op een punt dat pijnlijk is voor aanvallers maar nog acceptabel voor gebruikers.
Met Argon2id kun je bovenop tijdskosten ook geheugen-hardheid toevoegen. Elke poging vereist CPU-tijd en RAM die op een specifieke manier wordt benaderd. GPU's zijn extreem snel in compute-intensieve taken, maar verliezen veel van hun voordeel wanneer elke parallelle poging substantiële geheugenruimte nodig heeft.
Salts zijn ononderhandelbaar. Een unieke, willekeurige salt per wachtwoord:
Salts maken zwakke wachtwoorden niet sterk. Ze beschermen je vooral na een databaselek door aanvallers te dwingen per gebruiker echt werk te doen.
bcrypt wordt nog veel gebruikt, vooral omdat het overal eenvoudig te deployen is. Het past goed als je brede interoperabiliteit nodig hebt, je stack beperkte crypto-opties heeft, of als je een simpele afstemmingshendel wilt.
De grootste “valkuil” is de 72-byte wachtwoordlimiet. bcrypt gebruikt alleen de eerste 72 bytes van het wachtwoord en negeert de rest. Dit kan verrassend zijn voor mensen die lange passphrases of password managers gebruiken.
Als je bcrypt kiest, maak het wachtwoordlengtegedrag expliciet. Of je handhaaft een maximale lengte (in bytes, niet in tekens) of je verwerkt lange invoer consequent in alle services. Het belangrijkste is dat je stille truncatie voorkomt die verandert wat de gebruiker denkt dat zijn wachtwoord is.
bcrypt is ook minder bestand tegen moderne parallelle krakende hardware dan geheugen-harde opties. De verdediging is nog steeds geldig, maar vertrouwt sterk op het kiezen van een cost factor die elke poging kostbaar maakt.
Als je een nieuw systeem bouwt of je hebt accounts met hoge waarde (betaalde plannen, admin-rollen), is migreren naar Argon2id voor nieuwe hashes terwijl je bestaande bcrypt-hashes blijft accepteren tot gebruikers inloggen een gebruikelijk en laag-risico pad.
Argon2 is gebouwd voor wachtwoordhashing. Argon2id is de variant die de meeste teams kiezen omdat het GPU-weerstand combineert met redelijke bescherming tegen side-channel issues.
Argon2id geeft je drie parameters:
Geheugen is het belangrijkste voordeel. Als elke poging een noemenswaardige hoeveelheid RAM vereist, kunnen aanvallers niet zo veel pogingen parallel draaien zonder veel te betalen voor geheugencapaciteit en bandbreedte.
Het nadeel is operationeel: meer geheugen per hash betekent minder gelijktijdige logins voordat je servers onder druk komen te staan. Als je geheugen te hoog zet, kunnen pieken in logins wachtrijen, time-outs of zelfs out-of-memory fouten veroorzaken. Denk ook aan misbruik: veel gelijktijdige inlogpogingen kunnen een resource-probleem worden als je het werk niet limiteert.
Om Argon2id veilig en bruikbaar te houden, stem je het af als een performance-feature:
Bij wachtwoordhashing is “sneller is beter” meestal het verkeerde doel. Je wilt dat elke poging duur is voor aanvallers, terwijl logins nog steeds snel aanvoelen voor echte gebruikers.
Een praktische manier is een tijdbudget per verificatie op je echte productiehardware. Veel teams mikken op iets als 100 tot 300 ms per hash-check, maar het juiste nummer hangt af van je verkeer en servers. Het verschil tussen bcrypt en Argon2 is waar je die tijd in stopt: bcrypt is vooral CPU-tijd, terwijl Argon2 ook geheugen kan reserveren.
Kies een target hash-tijd en test het onder omstandigheden die op productie lijken. Meet zowel signup/password-change hashing als login-verificatie, maar behandel login als de hot path.
Een lichtgewicht meetplan:
De meeste systemen falen tijdens pieken. Als een marketingmail een golf gebruikers naar de loginpagina stuurt, bepalen je hashing-instellingen of het systeem responsief blijft.
Als één verificatie 250 ms duurt en je server er 40 parallel aankan voordat er wachtrijen ontstaan, kan een golf van 500 inlogpogingen in meerdere seconden wachttijden veranderen. In dat geval kan een kleine verlaging van de kosten plus strikte rate limits de echte veiligheid verbeteren meer dan het doorzetten van parameters tot het punt waarop de login-endpoint fragiel wordt.
Niet elke wachtwoordbewerking heeft dezelfde urgentie. Houd de interactieve loginkost stabiel en doe zwaar werk buiten het kritieke pad. Een veelgebruikt patroon is rehash-on-login (upgraden van een gebruikershash direct na een succesvolle login) of achtergrondjobs voor migraties en imports.
Parameterafstemming draait om het verhogen van de kosten voor aanvallers per poging zonder aanmeldingen traag te maken of je servers te destabiliseren.
Kies een algoritme dat je stack goed ondersteunt. Als Argon2id beschikbaar en goed ondersteund is, is het meestal de standaard. Als je brede compatibiliteit nodig hebt, is bcrypt nog steeds prima.
Stel een targettijd per hash in op productie-achtige hardware. Kies iets dat logins soepel houdt tijdens piekbelasting.
Stel af om die tijd te halen. Bij bcrypt pas je de cost factor aan. Bij Argon2id balanceer je geheugen, iteraties en parallelisme. Geheugen is de hendel die de economie voor aanvallers het meest verandert.
Sla algoritme en instellingen bij de hash op. De meeste standaard hashformaten embedden deze details. Zorg er ook voor dat je databaseveld lang genoeg is zodat hashes nooit worden afgekapt.
Plan upgrades met rehash-on-login. Wanneer een gebruiker inlogt, en hun opgeslagen hash zwakker is dan je huidige beleid, herhash en vervang die.
Als je een basis nodig hebt voordat je meet, begin conservatief en pas aan op basis van timing.
Zie dit als uitgangspunten, geen regels. De juiste instellingen passen bij je verkeer, hardware en piekloginbelastingen.
De meeste fouten in wachtwoordopslag komen door configuratiegaten, niet door een slecht algoritme.
Salt-fouten zijn een grote categorie. Elk wachtwoord heeft zijn eigen unieke salt die samen met de hash wordt opgeslagen. Hergebruiken van salts of één globale salt voor alle gebruikers maakt het eenvoudiger voor aanvallers om werk te hergebruiken en accounts te vergelijken.
Kosten verwaarlozing is er ook een. Teams leveren vaak met een lage cost omdat inloggen sneller aanvoelt en herzien het nooit. Hardware verbetert, aanvallers schalen op, en je ooit-goede instellingen worden goedkoop.
Argon2 over-tunen komt ook vaak voor. Geheugen extreem hoog instellen ziet er op papier goed uit, maar maakt logins traag of veroorzaakt wachtrijen en OOM-fouten tijdens echte pieken.
Wachtwoordlengte-afhandeling is belangrijk, vooral met bcrypt’s 72-byte gedrag. Als je lange wachtwoorden toestaat maar ze stilletjes trunkateert, creëer je verwarrend gedrag en verminder je veiligheid.
Een paar praktische gewoonten voorkomen het meeste:
Houd deze korte lijst bij de hand wanneer je uitrolt of infrastructuur wijzigt:
Een eenvoudige sanity-check: voer een staging-test uit met een golf van logins (succesvol en mislukt) en bekijk end-to-end latency plus CPU- en RAM-gebruik. Als het loginpad worstelt, stem kosten af en verscherp rate limits. Los het niet op door essentiële zaken zoals salts te schrappen.
Stel je een kleine SaaS-app voor met een paar duizend gebruikers. Het grootste deel van de dag is rustig, maar je ziet korte inlogpieken na een nieuwsbrief of bij het begin van de werkdag. Hier wordt de keuze een capaciteitsoefening.
Je kiest Argon2id om de kosten van offline kraken te verhogen. Kies een target verificatietijd op je echte serverhardware (bijvoorbeeld 100 tot 250 ms), en stem parameters zo af dat je die tijd haalt terwijl je RAM in de gaten houdt, omdat geheugeninstellingen kunnen bepalen hoeveel gelijktijdige logins je aankunt.
Een praktisch afstemschema:
Als je al oudere hashes met zwakkere instellingen hebt, blijf ze verifiëren maar upgrade stilletjes. Bij een succesvolle login rehash je met de huidige instellingen en sla je de nieuwe waarde op. In de loop van de tijd migreren actieve gebruikers naar sterkere hashes zonder gedwongen resets.
Na release monitor je login als elk ander kritisch endpoint: tail-latency (p95/p99), CPU en RAM tijdens pieken, mislukte-loginpieken en hoe snel oude hashes worden vervangen.
Schrijf je beleidsregels op en behandel ze als levende instellingen. Bijvoorbeeld: “Argon2id met X geheugen, Y iteraties, Z parallelisme” of “bcrypt cost factor N”, plus de datum van keuze en wanneer je het opnieuw zult beoordelen (elke 6 tot 12 maanden is een goed startpunt).
Zorg voor een upgradepad zodat je niet vastzit aan oude hashes. Rehash-on-login is eenvoudig en werkt in de meeste systemen.
Een sterke hash helpt, maar vervangt geen online-abuse controles. Rate limits, lockouts en zorgvuldige wachtwoordreset-flows zijn net zo belangrijk voor echte wereldbeveiliging.
Als je je backend bouwt met een no-code platform zoals AppMaster, controleer dan of je authenticatiemodule sterke wachtwoordhashing als default gebruikt en of je hashing-kosten zijn afgestemd op hetzelfde type infrastructuur waarop je zult deployen. Die korte test aan het begin is vaak het verschil tussen “veilig en soepel” en “veilig maar onbruikbaar onder belasting.”
What problem does password hashing solve?Wachtwoordhashing laat je een login verifiëren zonder het echte wachtwoord op te slaan. Je slaat een eenrichtings-hash op, hasht de invoer van de gebruiker en vergelijkt de resultaten; als je database lekt, moeten aanvallers nog steeds wachtwoorden raden in plaats van ze te lezen.
Why not just encrypt passwords instead of hashing them?Encryptie is omkeerbaar met een sleutel, dus als die sleutel wordt gestolen of verkeerd beheerd, kunnen wachtwoorden worden teruggewonnen. Hashing is eenrichtingsgewijs ontworpen, dus zelfs jij kunt de opgeslagen waarde niet “decrypteren” naar het originele wachtwoord.
Why is SHA-256 a bad choice for storing passwords?Snelle hashes zijn geweldig voor aanvallers omdat ze offline veel pogingen per seconde kunnen uitvoeren, vooral met GPU's. Wachtwoordhashes moeten opzettelijk traag zijn (en bij voorkeur geheugen-intensief) zodat grootschalig raden duur wordt.
What is a salt, and does it actually make passwords safer?Een salt is een unieke, willekeurige waarde die naast elke wachtwoordhash wordt opgeslagen. Het voorkomt dat identieke wachtwoorden identieke hashes opleveren en stopt aanvallers met het hergebruiken van voorgecomputeerde tabellen, maar het maakt zwakke wachtwoorden op zichzelf niet sterk.
When should I choose Argon2id vs bcrypt?Kies Argon2id als je stack het goed ondersteunt en je geheugen veilig kunt tunen, want het is ontworpen om parallel kraken te bemoeilijken. Kies bcrypt als je maximale compatibiliteit nodig hebt en een eenvoudiger afstemmingsmodel, en stel dan een voldoende hoge cost factor in.
What’s the big gotcha with bcrypt and long passwords?bcrypt heeft een limiet van 72 bytes: het gebruikt alleen de eerste 72 bytes van een wachtwoord en negeert de rest. Om verrassingen te vermijden, handhaaf een duidelijke maximale lengte in bytes of behandel lange invoer consequent zodat gebruikers geen stille truncatie ervaren.
Which Argon2id parameter matters most, and why?Geheugen is de belangrijkste parameter omdat het beperkt hoeveel pogingen aanvallers parallel kunnen uitvoeren zonder veel te betalen voor RAM en bandbreedte. Te veel geheugen kan jou echter ook schaden door te verminderen hoeveel logins je servers tegelijk kunnen verwerken; stem dus af op piekverkeer, niet alleen op single-request tests.
How slow should password hashing be in a web backend?Streef naar een voorspelbare verificatietijd op je echte deployment-hardware, vaak rond 100–300 ms per controle, en voer dan load-tests voor concurrency uit. De juiste instelling blijft responsief tijdens inlogpieken en maakt offline raden toch kostbaar.
How do I upgrade hashing settings without forcing everyone to reset passwords?Sla het algoritme en de parameters bij de hash op zodat je oude accounts kunt verifiëren en later de kosten kunt verhogen. Een veelgebruikte aanpak is rehash-on-login: na een succesvolle login, als de opgeslagen hash zwakker is dan het huidige beleid, hercomputeer je deze met de nieuwe instellingen en sla je die op.
What are the most common mistakes that weaken password storage?Veelvoorkomende fouten zijn onder meer ontbrekende of hergebruikte salts, het uitrollen met een lage cost en deze nooit herzien, en het te extreem tunen van Argon2-geheugen tot het punt dat logins tijdens pieken time-outs geven. Let ook op wachtwoordlengtebehandeling (vooral bij bcrypt) en bescherm de login-endpoint met rate limits en korte lockouts.
27 jan 2026
7 min
26 jan 20268 min
21 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
