Sla wachtwoorden op met Argon2id, ingesteld op minimaal 19 MiB geheugen, 2 iteraties en 1 graad van parallellisme, met een unieke salt per wachtwoord. Dat is de minimumconfiguratie uit de OWASP Password Storage Cheat Sheet. Bevat uw database nog MD5-, SHA-1- of ongesalte hashes, dan kunt u dat verhelpen zonder een massale wachtwoordreset en zonder zwakke hashes achter te laten voor slapende accounts.
Wat u gebruikt en de minimale instellingen
De cheat sheet noemt deze minima:
| Situatie | Algoritme | Minimale instellingen |
|---|---|---|
| Voorkeur | Argon2id | 19 MiB geheugen, 2 iteraties, parallellisme 1 |
| Argon2id niet beschikbaar | scrypt | kostenparameter 2^17, blokgrootte 8, parallellisme 1 |
| Legacy-systemen op bcrypt | bcrypt | work factor 10 of hoger, wachtwoordlimiet van 72 bytes |
| FIPS-140-compliance vereist | PBKDF2 | 600.000 of meer, HMAC-SHA-256 |
Argon2id is de primaire variant in RFC 9106 en elke implementatie van dat document moet deze ondersteunen. Het werkt als Argon2i tijdens de eerste helft van de eerste doorloop over het geheugen en als Argon2d voor de rest.
De bcrypt-limiet van 72 bytes
De cheat sheet hanteert voor bcrypt een wachtwoordlimiet van 72 bytes. De bronnen geven niet aan hoe afzonderlijke libraries met langere invoer omgaan, dus test uw eigen library. Hash een wachtwoord van 72 a-tekens gevolgd door b en verifieer vervolgens 72 a-tekens gevolgd door c. Slaagt de verificatie, dan kapt uw library het wachtwoord stilzwijgend af.
Beperk daarna de wachtwoordlengte in uw formulieren tot 72 bytes en communiceer dat duidelijk, of plan de overstap naar Argon2id. RFC 9106 staat wachtwoorden toe van maximaal 2^32-1 bytes.
Waarom snelle hashes tekortschieten
MD5 en SHA-1 zijn ontworpen om snel te zijn, en SHA-256 is om dezelfde reden ongeschikt: een aanvaller kan er razendsnel enorme aantallen gokpogingen mee doen. De aanvaller hasht kandidaten uit gelekte wachtwoordlijsten, woordenlijsten of via brute force en vergelijkt de uitkomsten met uw rijen. GPU's en gehuurde cloudservers maken dat goedkoop.
Een unieke salt dwingt de aanvaller om hashes één voor één te kraken. Ook rainbow tables werken dan niet meer en identieke wachtwoorden leveren niet langer identieke hashes op. RFC 9106 raadt een salt van 16 bytes aan voor wachtwoordhashing. Beproefde libraries genereren en bewaren de salt voor u, dus schrijf dat onderdeel niet met de hand.
De work factor afstellen
Er bestaat geen universeel getal. Het hangt af van uw server en uw aantal gebruikers en u vindt het door te experimenteren op de hardware die u daadwerkelijk gebruikt. De vuistregel is dat één hash minder dan een seconde moet duren.
Te hoog instellen heeft een prijs. Elke inlogpoging kost CPU en een stortvloed aan pogingen kan de server uitputten. Benchmark onder realistische gelijktijdigheid en kies een waarde die u op piekbelasting kunt dragen.
Controleer de eenheid die uw Argon2-library verwacht. RFC 9106 definieert de geheugengrootte in kibibytes, terwijl de cheat sheet MiB noemt. 19 MiB is 19456 KiB en als u 19 doorgeeft waar de library KiB verwacht, krijgt u 19 KiB geheugen. Die instelling werkt wel, maar is veel zwakker dan bedoeld.
De work factor wordt doorgaans in de hash-uitvoer opgeslagen. Dat helpt bij migratie, want bij het inloggen ziet u met welke parameters een bepaalde hash is aangemaakt.
Pepper als extra laag
Een pepper is een geheim dat voor alle opgeslagen wachtwoorden geldt en buiten de database wordt bewaard, in een secrets vault of een HSM. Het helpt wanneer een aanvaller alleen de database bemachtigt, via SQL injection of een gestolen back-up. Op zichzelf voegt het niets toe, dus beschouw het als defence in depth.
Rotatie is het probleem. Een gecompromitteerde pepper kan niet worden gewijzigd zonder het wachtwoord van elke gebruiker te kennen, dus vervanging dwingt een reset af voor iedereen die ermee beschermd was. Bepaal wie eigenaar is van die procedure voordat u een pepper invoert.
Oude hashes upgraden
De aanpak van de cheat sheet om een work factor te verhogen, is wachten tot de gebruiker zich de volgende keer authenticeert en het wachtwoord dan opnieuw te hashen met de nieuwe instellingen. Migreren van MD5-, SHA-1- of ongesalte hashes volgt dezelfde logica, al is die uitbreiding van ons.
- Markeer elke opgeslagen hash met het bijbehorende algoritme, in een aparte kolom of via het hashformaat. Als u niet zeker weet wat er in de tabel staat, helpt de hash-identifier u de formaten te herkennen.
- Verifieer bij het inloggen met het algoritme dat bij de opgeslagen hash hoort.
- Bereken bij succes, als de hash legacy is of onder uw huidige parameters valt, een nieuwe Argon2id-hash van het ingevoerde wachtwoord met een verse salt.
- Overschrijf de oude waarde in dezelfde bewerking.
ok = verify(row.scheme, row.hash, submitted)
if ok and (row.scheme != "argon2id" or needs_rehash(row.hash)):
row.hash = argon2id_hash(submitted) # fresh salt, current parameters
row.scheme = "argon2id"
save(row)Slapende accounts
Gebruikers die nooit meer inloggen, worden nooit geüpgraded, waardoor hun zwakke hashes onbeperkt in de tabel blijven staan. Een oplossing is om die nu in te pakken. Draai Argon2id over de bestaande MD5- of SHA-1-waarde, sla het resultaat op met een schemamarkering zoals argon2id(md5) en verwijder de kale hash.
Bij het inloggen berekent u de legacy hash van het ingevoerde wachtwoord, verifieert u die tegen de Argon2id-wrapper en vervangt u bij succes de wrapper door een gewone Argon2id-hash. Leg exact vast hoe de legacy waarde is gecodeerd (hex of ruwe bytes), want een mismatch laat elke login voor dat schema mislukken. Test het ingepakte pad eerst op een kopie van de tabel.
Inpakken maakt een zwak wachtwoord niet sterk. Het voorkomt wel dat een gestolen tabel met MD5-snelheid kan worden aangevallen.
Het alternatief is om de oude hashes na een afkapdatum te verwijderen en bij de volgende aanmelding een reset te eisen. De cheat sheet beschrijft dat als een optie, afhankelijk van de applicatie. Raakt de wijziging een codebase die u niet volledig beheert, dan kan ons team veilige softwareontwikkeling de aanpassing beoordelen.
Waar u begint
- Controleer de gebruikerstabel: welke algoritmen er worden gebruikt, of er salts zijn en of er wachtwoorden in platte tekst of omkeerbaar versleuteld zijn opgeslagen. Versleuteling is alleen acceptabel als u het oorspronkelijke wachtwoord moet kunnen terughalen, en de cheat sheet raadt aan dat niet nodig te hebben.
- Kies Argon2id met minimaal 19456 KiB, 2 iteraties en parallellisme 1 en benchmark dit op productiehardware totdat één hash minder dan een seconde duurt.
- Zit u op bcrypt, voer dan de hierboven beschreven test van 72 bytes uit en kies tussen een lengtebeperking en een overstap naar Argon2id.
- Voeg een algoritmemarkering toe aan het schema, pas de logincode aan zodat deze met het oude schema verifieert en bij succes opnieuw hasht.
- Pak de resterende legacy hashes in met Argon2id, of stel een afkapdatum in waarna ze worden verwijderd en een reset vereist is.
- Voegt u een pepper toe, bewaar die dan in een secrets vault en leg eerst de rotatie- en gedwongen-resetprocedure vast.
