Citat:
Originally posted by Drew@Jul 27 2008, 23:44
Det är ju åtminstone vänligt av osCommerce att lägga med saltet i databasen. Känns lite meningslöst att salta då.
|
Det är inte alls meningslöst. Med ett dynamiskt salt (unikt för varje användare) måste lösenordet knäckas för varje användare. Med ett enda fast salt kan man räkna ut ett lösenord och sedan jämföra mot samtliga användare för se om det träffar någon, eller helt sonika räkna ut regnbågstabeller för det aktuella saltet.
Exempel:
Användare 1 - Lösen: apa
Användare 2 - Lösen: banan
== Fast salt ==
Säg att vi (attackeraren) hashar lösenordet banan tillsammans med det fasta saltet. Då kan vi testa denna hash mot hasharna för båda användarna och se, vi får en träff med en enda uträkning.
== Dynamiskt salt ==
Nu hashar attackeraren ordet banan för varje enskild användare, vilket ökar tidsförbrukningen avsevärt om det är många användare.
Man kan ju dessutom ha både ett fast (i sin applikationskod) och ett dynamiskt (i databasen) salt, för att göra det svårare om man bara får reda på det ena saltet. Man kan om man vill försöka lagra saltet i en egen tabell, eller med applikationskod räkna ut saltet från exempelvis användarnamn och registreringsdatum, men det är inte säkert att det är värt besväret.