Ja, strengsammenligningen (og/eller indeksopslag) kan i princippet lække, hvor mange identiske ledende bytes adgangskodehashen er gemt i databasen og den, der er beregnet ud fra den indtastede adgangskodeshare.
I princippet kunne en angriber bruge dette til iterativt at lære et præfiks af adgangskoden hash, byte for byte:først finder de en hash, der deler sin første byte med hashen i databasen, derefter en, der deler sine første to bytes og så videre.
Nej, det vil næsten helt sikkert være ligegyldigt.
Hvorfor? Tja, af en række årsager:
-
Et tidsangreb kan tillade angriberen at lære en del af brugerens kodeords-hash. En veldesignet adgangskode-hash-ordning (ved hjælp af en salt- og nøglestrækning ), bør dog forblive sikker (naturligvis forudsat, at adgangskoden i sig selv ikke er let at gætte), selvom angriberen kender hele password hash. Således, selvom timingangrebet lykkes, vil selve adgangskoderne være sikre.
-
For at udføre angrebet skal angriberen indsende adgangskoder, hvis hashværdi de kender. Hashværdien afhænger af saltet. Således, medmindre angriberen på en eller anden måde allerede kender saltet, er dette angreb ikke muligt.
(Det er rigtigt, at saltet i de fleste sikkerhedsanalyser af password-hashing-ordninger antages at være offentlig information. Dette er dog kun fordi sådanne analyser forudsætter det værst tænkelige scenario nævnt ovenfor, hvor angriberen allerede har fået en kopi af hele brugerdatabasen, salte og hashes og det hele. Hvis angriberen endnu ikke kender hashen, er der ingen grund til at antage, at de kender saltet.)
-
Selvom angriberen kender saltet, skal de for at udføre det iterative angreb beskrevet ovenfor, generere adgangskoder, der hash til en værdi med et ønsket præfiks. For enhver sikker hash-funktion er den eneste praktiske måde at gøre dette på ved at prøve en fejl, hvilket betyder, at den nødvendige tid til at gøre det skaleres eksponentielt med længden af præfikset.
Hvad dette betyder i praksis er, at for at udtrække tilstrækkeligt mange bits af hashen til at være i stand til at udføre et offline brute force-angreb mod den (som ikke behøver at være dem alle; bare mere end den effektive mængde entropi i adgangskode), angriberen skal udføre omtrent lige så mange beregninger som nødvendigt for at knække selve adgangskoden. For en veldesignet adgangskode-hash-ordning og en sikkert valgt adgangskode er dette ikke muligt.
-
Hvad det iterative angreb kan give angriberen, i princippet, er evnen til at gøre det meste af brute force-beregningen lokalt i deres ende, mens du kun sender et ret lille antal adgangskoder til dit system. Men selv dette gælder kun, hvis de modtager detaljerede og pålidelige timingoplysninger tilbage fra hver adgangskode indsendt. I praksis er real timing-angreb ekstremt ineffektive , og kræver mange (ofte tusinder eller millioner) forespørgsler for at give enhver nyttig information overhovedet. Dette vil højst sandsynligt ophæve enhver potentiel ydeevnefordel, som timingangrebet kunne give angriberen.
Dette punkt er forstærket, at du bruger et ordentligt hashing-skema for nøglestrækning af adgangskoder, da sådanne skemaer bevidst er designet til at være langsomme. Således vil strengsammenligningen i databasen sandsynligvis tage en ubetydelig tid sammenlignet med hashing af adgangskoden i første omgang, og enhver tidsvariation forårsaget af det vil således gå tabt i støjen.