MD5-hashes van wachtwoorden zijn niet eenvoudig te kraken.

De kraakbaarheid van MD5 bestaat eruit dat je relatief eenvoudig twee verschillende inputs kunt genereren (die, specifiek voor MD5, aan speciale criteria moeten voldoen) die tot dezelfde hashwaarde leiden. Hierbij gaat het om relatief lange inputs, niet om wachtwoorden van 20 tekens of minder. Zie het plaatje in https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities om een idee te krijgen van de lengte (2 bestanden van 128 bytes, met een paar verschillen op zeer specifieke plaatsen).

Uit https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability:
Met andere woorden, de betrouwbaarheid is met minder dan 5 (van 128) bits gedaald als je, gegeven een onbekende input (het wachtwoord), die input wilt vinden (of iets totaal anders, een "collission") die tot dezelfde MD5 hash leidt. Cryptografisch is MD5 -m.b.t. preimage attacks- "gekraakt" vanwege die afname met bijna 5 bits voor een preimage attack - echter: "This attack is only theoretical" - want 2^125 is nog steeds een astronomisch groot getal.

Elk snel hash-algoritme, ook van de nog als veilig bekend staande soorten (zoals SHA-256 of SHA-3 varianten), is ongeschikt om zwakke wachtwoorden (dat zijn ooit gelekte -ook lange en/of complexe- of voorspelbare wachtwoorden) mee te hashen - omdat je van een ellenlange lijst van die zwakke wachtwoorden alle hashes kunt uitrekenen (en desgewenst opslaan in wat een "rainbow table" wordt genoemd).

Vervolgens kun je, voor elke wachtwoordhash afkomstig van de server, checken of deze vóórkomt in je tabel. Als dat het geval is, weet je het wachtwoord. Je zou dit "kraken" kunnen noemen, maar dat vind ik onterecht; in elk geval heeft dit niets met cryptografisch kraken te maken. Sterke wachtwoorden (die nog nooit gelekt, lang genoeg en onvoorspelbaar zijn) vind je hier niet mee.

Met andere woorden: als de website SHA-256 (waar zeer snelle hardware voor ontwikkeld is) i.p.v. MD5 zou gebruiken, zou dat prima zijn geweest? NEE!

Ik vind het dus een onjuist verwijt. Het grootste probleem hier is dat veel mensen ooit eerder (niet alleen door henzelf) gebruikte wachtwoorden kiezen. Als de betreffende website ooit eerder gekozen wachtwoorden zou weigeren, en de opgeslagen wachtwoord-hashes regelmatig zou scannen op nieuwe gelekte wachtwoorden en bij gevonden "matches" de gebruikers zou dwingen (password-reset) om een ander wachtwoord te kiezen, zou zelfs MD5 in principe goed genoeg zijn.

Vanwege het feit dat MD5 voor een andere toepassing ernstig is gekraakt, en er bij softwareontwikkelaars verwarring zou kunnen onstaan over "welke toepassing ook alweer", is het onverstandig om MD5 te blijven gebruiken. Het verwijt hier "het zwakke en eenvoudig te kraken MD5-algoritme" zou echter voor een rechter geen stand moeten houden, want het is fundamenteel onjuist.

Dit nog los van het feit dat ik nergens zie dat wachtwoordhashes zouden zijn gelekt, bijv. doordat de website gehacked is. Als dat gebeurt zit het er dik in dat ook allerlei andere persoonsgegevens op straat liggen, die ongetwijfeld niet eens gehashed of versleuteld op de server staan. Wat is er erger?

Je kunt natuurlijk beargumenteren dat mensen hun eigen wachtwoorden hergebruiken en dat het vooral daarom erg is als die wachtwoorden, samen met e-mailadressen, op straat komen te liggen. Maar is hergebruik van eigen wachtwoorden de schuld van die website?

Het verstandigst is het (voor website-eigenaren) om state-of-the-art "memory-hard" algoritmes zoals Argon2id te toe te passen, maar persoonlijk heb ik liever dat ze hun hun geld en tijd (is ook geld, als je capabel personeel kunt vinden) besteden aan de beveiliging van de website en het minimaliseren van (te veel en/of te lang) opgeslagen persoonsgegevens.

De "veiligheid" heeft weinig met collision attacks te maken. Colission attacks zijn maar een fractie van de onveiligheid. De actuele veiligheid is laag omdat MD5 gewoon te snel is en je miljoenen wachtwoorden per seconde kan proberen. Plus het feit dat er "rainbow tables" zijn waar je bijna instant een hash terug naar een wachtwoord kan herleiden. (Mits deze niet te lang is)

Mooi uiteen gezet Erik! Geen speld tussen te krijgen. De vraag is natuurlijk of rechters hier daadwerkelijk rekening mee gaan houden in hun uitspraken. Het persoonlijk begrip van de materie is vaak te laag en de druk van de publieke opinie te hoog.
Neemt niet weg dat lange, unieke wachtwoorden gebruiken, een absolute must is, voor iedereen.

Dank!

Ik hoop vooral dat techneuten dit gaan snappen, en organisaties zoals de AP en haar Europese collega's. In dit specifieke geval kan zo'n blunder je hele case onderuit halen, terwijl er, naar verluidt, veel grotere privacy-risico's bestonden.

Klopt, en omdat meer dan enkele sterke wachtwoorden onthouden "onmenselijk" is: gebruik een wachtwoordmanager.

De rechter hoeft dat begrip ook niet te hebben. Daarvoor zijn getuige-deskundigen die dan worden gehoord. Maar ik denk niet dat de boete er alleen komt door de MD5. het zal vooral met de onrechtmatige verwerking samenhangen, aangevuld met een tekortschieten van het geheel aan informatiebeveiliging.

Dat is wel een van de meeste domme beveiliging sugesties ooit. Hoe zie je dat in de praktijk voor je?
Dan krijg je dezelfde troep wat je vaak met gebruikersnamen ziet die al in gebruik zijn. Mensen die boos raken door dat ze niet hun eigen gekozen alias mogen gebruiken (denk aan diensten als discord aan games etc) Maar goed dat is het menselijke deel dat intereseert me niet zo.

Maar hoe ga je voorkomen dat een crimineel niet gewoon een bot opzet voor registratie en allerlei bekende wachtwoorden probeert met de registratie in plaats van via inlog. Want als je duplicering van ieder wil voorkomen moet je dus ook naar ieder communiceren dat er een duplicaat is gevonden. Een soort wie ben ik met de server. Hoi server heb jij toevallig wachtwoord welcome01 opgeslagen staan? "Nee" Ok welcome02 dan "Ja' Thank you!

Tuurlijk daar kan je weer dan een max aantal pogingen tegen aan gooien maar gezien de gebruikers niet weten van te voren of hun wachtwoord zou werken krijg je een buttload aan support tickets als je hun legitieme registratie pogingen ook nog gaat blocken voor X duration en je conversie daalt ook enorm.

Vervolgens is het een kwestie voor de criminelen om een email lijst te bemachtigen van de gebruikers en de wachtwoorden er tegen aan te proberen die als duplicaat waren gevonden. En je weet ook die lijsten zijn er meestal binnen no time Dus wat je hiermee bewerkstellige is een soort aangepaste bruteforce medemogelijk gemaakt door deze beveiliging methode. Het stopt zeker het kraken want die heb je helemaal niet meer nodig de site doet het al lekker voor je.

Dus ja theoretisch mogelijk in de praktijk mag ik hopen niemand ooit zo dom te zijn het door te voeren.