Als een site het missen van een Salt niet als aanvalsvector ziet (onder het motto: het is toch zo ook al gehashed?) dan kan ik best begrijpen dat er niets mee gebeurt. Vergeet niet dat niet iedere Security Officier volledig op de hoogte is van de stand van zaken mbt mogelijke collisions in hashalgoritmes
Sorry maar dat gaat in dit geval echt nergens over. Het gebruiken van een salt is gewoon security 101, en kwetsbaarheden met collisions hebben daar niets mee te maken.
Ongeacht het gebruikte hash algoritme, je wil niet dat de hash van Pietje en Henkie hetzelfde zijn als ze toevallig hetzelfde wachtwoord gebruiken. En in het verlengde daarvan, je wil ook niet dat een aanvaller die beschikt over een database van hashes met een dictionary attack of simpelweg brute force in een keer de hele database kan checken ipv dat hij dat per persoon moet doen (in het geval van LinkedIn met 161 miljoen gebruikers vergroot het niet gebruiken van een salt de kans dus met 161 miljoen dat een attacker een wachtwoord van een gebruiker achterhaalt).
Dus iets wat vandaag nog goed is (vb: SHA1) kan morgen al compleet onveilig blijken.
Klopt, met twee kanttekeningen: ten eerste was SHA-1 gisteren al niet goed meer, en ten tweede is SHA-512 net zo slecht. Het gaat namelijk niet echt om het aantal bits in de hash. Zelfs MD5 is wat dat betreft gewoon afdoende - al zou je een biljard hashes per seconde kunnen berekenen, dan nog ben je gemiddeld 10
16 jaar bezig om een collision te vinden.
Het specifieke probleem van wachtwoorden is dat de input space (het aantal mogelijke wachtwoorden) veel kleiner is dan de output space (het aantal mogelijke hashes), dat is zelfs bij een relatief kleine 128 bits hash zoals MD5 nog het geval. Als je uitgaat van wachtwoorden van louter alphanumerieke tekens van maximaal 10 tekens lang (dit zijn de meest voorkomende wachtwoorden), dan zijn er maar 62
10 =~ 10
17 verschillende wachtwoorden mogelijk. En dat terwijl er 2
128 =~ 10
38 verschillende hashes bestaan. De kans op collision is dus sowieso erg klein.
Een hash algoritme met als doel wachtwoorden te hashen is natuurlijk pas echt compromized op het moment dat een pre-image attack mogelijk is. Oftewel, als door te kijken naar de bits van de hash een sterk gereduceerde set van mogelijke inputs te genereren is, waarna je die kunt proberen. Maar ondanks het feit dat MD5 inmiddels een hoop flaws kent is dit er niet een van, en die bekende flaws zijn voor het doel van het hashen van wachtwoorden eigenlijk compleet oninteressant.
De reden waarom MD5 en SHA (welke variant dan ook) niet voldoen is omdat ze veel te snel te berekenen zijn. Als je wachtwoorden wilt hashen, kun je beter kijken naar algoritmes die aan
key stretching doen, zoals PBKDF2 (ook gebruikt op tweakers.net) of bcrypt. Het mooie daarvan is dat ze kunnen meegroeien met de hardware - als de hardware in de loop der tijd steeds sneller en sneller wordt dan vergroot je gewoon het aantal iteraties in het algoritme.
En wil je het als SO goed doen en je krijgt de overstap naar SHA512 niet intern verkocht omdat je leidinggevende er geen nut in ziet (het werkt zo toch ook? laat dan eens een collision zien?
Als een SO het op die manier probeert te verkopen dan heeft ie niet echt verstand van z'n vak
[Reactie gewijzigd door .oisyn op 22 juli 2024 20:19]