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

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.

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.

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.

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-conformiteit 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. NIST adviseert minimaal 600,000 iteraties met HMAC-SHA-256.

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 minimaal 19 MiB geheugen, 2 iteraties en 1 graad van parallellisatie. Pas dit 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.