JSON opmaken
JSON opmaken, controleren en samenvouwen.
Ontwikkelaar
Het type hash bepalen aan de hand van het formaat.
De lengte is de belangrijkste aanwijzing, maar niet doorslaggevend.
| Lengte (hex) | Waarschijnlijk algoritme |
|---|---|
| 32 tekens | MD5 of NTLM |
| 40 tekens | SHA-1 |
| 56 tekens | SHA-224 |
| 64 tekens | SHA-256 |
| 96 tekens | SHA-384 |
| 128 tekens | SHA-512 |
Een hexadecimale waarde van 32 tekens kan MD5 zijn of NTLM uit de Windows-wereld. De lengte alleen beslist dat niet; de context wel.
Sommige formaten zijn juist eenduidig omdat ze een voorvoegsel meedragen. Een waarde die met $2y$ begint is bcrypt, $argon2id$ is Argon2, en $6$ wijst op SHA-512-Crypt zoals dat in Unix-systemen wordt gebruikt.
Die voorvoegsels bevatten meestal ook de kostenfactor en het zout, wat ze goed herkenbaar maakt.
Bij Base64-gecodeerde hashes verandert de lengte, en dan helpt terugrekenen naar het aantal bytes.
Hier wordt de bepaling praktisch relevant.
Vind je in een database wachtwoorden als MD5- of SHA-1-waarden, dan is dat een ernstig probleem. Die algoritmen zijn extreem snel, en juist dat maakt ze ongeschikt voor wachtwoorden: een gewone grafische kaart probeert miljarden combinaties per seconde.
Ook SHA-256 is ongeschikt als wachtwoordhash, hoewel het cryptografisch niet gebroken is. De reden is dezelfde: het is te snel.
Voor wachtwoorden zijn bewust trage algoritmen nodig met een instelbare kostenfactor. De gangbare aanbevelingen noemen Argon2, bcrypt en scrypt, plus PBKDF2 met een hoog aantal iteraties waar de andere niet beschikbaar zijn.
Argon2id geldt momenteel als de beste keuze voor nieuwe ontwikkeling.
En een zout hoort er altijd bij: een willekeurige waarde per wachtwoord die voorkomt dat gelijke wachtwoorden gelijke hashes opleveren en die vooraf berekende tabellen onbruikbaar maakt. De genoemde algoritmen maken het zelf aan.
Vind je in een bestaand systeem MD5-hashes, dan is de gebruikelijke route: bij de volgende geslaagde aanmelding opnieuw hashen en de oude waarden geleidelijk vervangen.
De AVG vraagt bovendien om passende technische maatregelen: wachtwoorden opslaan met een verouderd algoritme is na een datalek moeilijk te verdedigen tegenover de toezichthouder.
Een paar verduidelijkingen die steeds weer nodig zijn.
Een hash is geen versleuteling. Hij is niet omkeerbaar — er is geen sleutel om terug te rekenen.
Toch kunnen zwakke hashes "gekraakt" worden, niet door omkering maar door proberen. Bij korte of veelvoorkomende wachtwoorden volstaat vaak opzoeken in een vooraf berekende tabel.
Een hash zegt ook niets over de lengte van de oorspronkelijke invoer: één letter en een heel boek leveren een waarde van dezelfde omvang op.
Voor controlesommen van bestanden zijn hashes juist ideaal, en daar is SHA-256 de juiste keuze. Overheden en softwareleveranciers publiceren controlesommen bij hun downloads.
Bij een gedownload bestand loont vergelijken echt: het kost seconden en ontdekt zowel overdrachtsfouten als gemanipuleerde downloads.
Deze tool werkt lokaal in je browser.
Alleen waarschijnlijk. Maar voorvoegsels als $2y$ zijn wel eenduidig.
Nee. Ze zijn veel te snel en laten massaal proberen toe.
Argon2id, bcrypt of scrypt, en PBKDF2 met veel iteraties als het niet anders kan.
Het voorkomt dat gelijke wachtwoorden gelijke hashes geven en maakt tabellen onbruikbaar.
Nee, maar zwakke hashes worden gekraakt door te proberen.
Nee.