Ja, de stringvergelijking (en/of index-lookup) kan in principe lekken hoeveel identieke leidende bytes de wachtwoordhash die in de database is opgeslagen en de hash die is berekend op basis van de ingevoerde wachtwoordshare.
In principe zou een aanvaller dit kunnen gebruiken om iteratief een voorvoegsel van de wachtwoordhash te leren, byte voor byte:eerst vinden ze een hash die zijn eerste byte deelt met de hash in de database, dan een die zijn eerste twee
Nee, dit zal vrijwel zeker niet uitmaken.
Waarom? Wel, om een aantal redenen:
-
Een timingaanval mag de aanvaller in staat stellen een deel van de wachtwoord-hash van de gebruiker te achterhalen. Een goed ontworpen hash-schema voor wachtwoorden (met behulp van een salt en key stretching ), moet echter veilig blijven (ervan uitgaande natuurlijk dat de wachtwoorden zelf niet gemakkelijk te raden zijn), zelfs als de aanvaller de volledige wachtwoord hash. Dus zelfs als de timing-aanval slaagt, zijn de wachtwoorden zelf veilig.
-
Om de aanval uit te voeren, moet de aanvaller wachtwoorden opgeven waarvan hij de hash-waarde kent. De hashwaarde is afhankelijk van het zout. Dus tenzij de aanvaller op de een of andere manier het zout al kent, is deze aanval niet mogelijk.
(Het is waar dat in de meeste beveiligingsanalyses van wachtwoord-hash-schema's wordt aangenomen dat de salt openbare informatie is. Dit is echter alleen omdat dergelijke analyses uitgaan van het hierboven genoemde worstcasescenario, waarbij de aanvaller al een kopie van de volledige gebruikersdatabase, salts en hashes en zo. Als de aanvaller de hash nog niet kent, is er geen reden om aan te nemen dat hij de salt zou kennen.)
-
Zelfs als de aanvaller de salt kent, moet hij, om de hierboven beschreven iteratieve aanval uit te voeren, wachtwoorden genereren die hashen naar een waarde met een gewenst voorvoegsel. Voor elke veilige hashfunctie is de enige praktische manier om dit te doen een proeffout, wat betekent dat de tijd die nodig is om dit te doen exponentieel wordt geschaald met de lengte van het voorvoegsel.
Wat dit in de praktijk betekent, is dat, om voldoende bits van de hash te extraheren om er een offline brute force-aanval op uit te kunnen voeren (wat niet allemaal hoeft te zijn; net meer dan de effectieve hoeveelheid entropie in de wachtwoord), de aanvaller moet ongeveer net zoveel rekenwerk uitvoeren als nodig is om het wachtwoord zelf te kraken. Voor een goed ontworpen wachtwoord-hashschema en een veilig gekozen wachtwoord is dit niet haalbaar.
-
Wat de iteratieve aanval kan geeft de aanvaller in principe de mogelijkheid om de meeste brute force-berekeningen lokaal uit te voeren, terwijl hij slechts een vrij klein aantal wachtwoorden naar uw systeem verzendt. Maar zelfs dit geldt alleen als ze gedetailleerde en betrouwbare timinginformatie terugkrijgen van elk wachtwoord ingediend. In de praktijk zijn real timing-aanvallen extreem inefficiënt , en er zijn vele (vaak duizenden of miljoenen) zoekopdrachten nodig om elke . op te leveren al met al nuttige informatie. Dit zal hoogstwaarschijnlijk elk potentieel prestatievoordeel tenietdoen dat de timingaanval de aanvaller zou kunnen bieden.
Dit punt wordt nog versterkt door een correct wachtwoord-hashschema te gebruiken dat de sleutels uitrekt, aangezien dergelijke schema's opzettelijk zijn ontworpen om traag te zijn. De stringvergelijking in de database zal dus waarschijnlijk een verwaarloosbare hoeveelheid tijd in beslag nemen in vergelijking met het hashen van het wachtwoord in de eerste plaats, en eventuele timingvariaties die hierdoor worden veroorzaakt, gaan dus verloren in de ruis.