Citat:
Originally posted by eg0master@Sep 27 2008, 11:12
Däremot måste vi anta (när vi värderar styrkan av algoritmen) att nyckeln (i det här fallet saltet) är okänd. Och då är ju ett unikt salt per användare, som är lagrat i databasen sannolikt den bästa lösningen.
|
Om vi skapar en algoritm som är helt bombsäker så länge nyckeln är hemlig men värdelös om man känner till nyckeln, då? Vad är då meningen med att kryptera lösenorden från första början, när både lösenorden och kryptonyckeln lagras sida vid sida?
Jag föredrar en hash med dubbla salt, ett som lagras i applikationskoden och ett dynamiskt som lagras med användaren i databasen. På så sätt måste man få reda på båda för att knäcka lösenordet. Det finns åtskilliga exempel på när knäckare fått tag på databasen med hjälp av en SQL-injektion, men inte fått tag på applikationskoden. En lösning som kräver både applikationskod och databas för att knäcka (utan råkraftsattack) är därför säkrare än en som bara kräver databasen.