Hasha lösenord rätt

Så här bör autentisering med lösenord implementeras i en webbapplikation.

Den senare tidens attacker där angriparen har kommit över lösenordsdatabasen aktualiserar frågan hur ett säkert lösenordsystem bör implementeras. Artikeln fokuserar främst på webbapplikationer då dessa varit mest utsatta, men många av koncepten går att applicera för andra typer av system.

Följande metoder kan användas för att kontrollera och spara lösenord:

Klartext: Lösenordet lagras i klartext. Bevisligen ett attraktivt alternativ för lata programmerare då metoden används i många system. Om en angripare kommer över lösenorden finns ingen ytterligare säkerhet varför metoden ska undvikas. Ett argument för metoden brukar vara att användaren kan få tillbaka sitt bortglömda lösenord. Ett bättre alternativ är att generera ett nytt lösenord.

Hash: För att slippa lagra lösenordet i klartext kan det hashas. En kryptografisk säker hashfunktion ska användas, exempelvis MD5 eller SHA-1. En hashfunktion är en envägsfunktion, som är lätt att beräkna från ena hållet men inte det andra. Jämför med en tandkrämstub: det är lätt att trycka ut tandkrämen men desto svårare att få tillbaka den i tuben. Det är med andra ord svårt räkna fram lösenordet eller delar av lösenordet från hashvärdet. Resultatet från hashfunktionen är en bitsträng av bestämd längd, exempelvis 160 bitar för SHA-1. Vilken hashfunktion ska väljas? MD5 är "kryptografisk skakig" eftersom ett antal svagheter har upptäckts och publicerats, varför SHA-1 är att föredra.

Hash + salt: Tre typer attacker förekommer mot hashade lösenord:

• Ordboksattack: Orden i listan hashas och jämförs med lösenordet. Denna process kan snabbas upp genom att använda "rainbow tables" vilket är ordlistan plus förgenererade hashvärden. Eftersom hashberäkningen redan är gjord krävs endast en strängjämförelse vilket är mycket snabbt.
• Råstyrkeattack ("brute force"): Som ordboksattacken men indata genereras i sekvens vilket innebär att alla möjliga kombinationer kan testas.
• Hybrid: En kombination av de båda ovanstående. Till exempel ord ur ordlistan plus suffix ("tomat42").

För att skydda sig mot förgenererade hashvärden samt att ett ordbokshashvärde kan jämföras mot alla hashade lösenord kan ett så kallat salt-värde användas. Det är ett slumptal på exempelvis 8 bytes som hashas tillsammans med lösenordet och lagras tillsammans med det hashade lösenordet. Ett salt på 8 bytes (64 bitar) innebär 2\^64 olika kombinationer för ett och samma lösenord. Längden är tilltagen i överkant med tanke på utvecklingen på hårdvara och borde hålla i många år framöver. En del Unix-system använde förr ett salt-värde på endast 12 bitar, något som visade sig vara för lite. Tänk på att använda en kryptografisk slumptalsgenerator för att generera salt-värde. Detta för att garantera att slumptalet inte går att förutsäga.

• Hash + salt + iteration: För att ytterligare försvåra en attack kan hashfunktionen köras flera gånger. Hashfunktionen tar då föregående iterations hashvärde som indata vilket upprepas ett antal gånger. Hur många gånger beror på aktuellt algoritm och hårdvara, samt hur lång fördröjning vid inloggning som kan accepteras. Mellan 40 000-150 000 iterationer kan vara ett riktmärke, men testa själv på aktuell hårdvara. Välj ett intervall för antalet iterationer och slumpa fram ett värde i detta intervall, vilket sparas tillsammans med hash- och salt-värdet

Tänk också på följande:

• Lösenfras: Uppmana gärna användaren att använda en lösenfras istället för ett lösenord. En lösenfras är en hel mening istället för ett enstaka ord. Längden på fältet i webbsidan innehållande lösenfrasen eller lösenordet bör inte begränsas då det ändå hashas. Förklara gärna för användaren varför det är viktigt att välja ett säkert lösenord, och betona vikten av att inte använda samma lösenord i flera olika system. Använd Sitics Förebyggande råd angående lösenord och Testa lösenord som inspiration.
• Bevara versaler och gemener: Konvertera aldrig lösenordet till exempelvis versaler eftersom då minskar antalet kombinationer drastiskt. Windows protokollet LANMAN gör just detta, vilket är en av anledningarna till att det att det är sårbart. För övrigt lagras ett LANMAN-hashvärde för varje lösenord i alla Windows-versioner med undantag för Vista. Slå därför av generering av LANMAN-hash, vilket görs genom en ändring i registret, om Windows NT, 2000 eller XP används.
• SSL kryptering: Skicka aldrig loginuppgifterna okrypterade. Överväg att kryptera hela session.
• Felmeddelande: Använd aldrig olika felmeddelanden beroende på om det är användarnamnet som är fel eller lösenordet. Då kan nämligen angriparen få fram användarnamn.
• Loggning: Logga alla misslyckade inloggningsförsök men logga aldrig angivet lösenord.
• Bortglömt lösenord: Undvik frågor så som "vad hette din mamma som ogift?". Svaren är lättgissade och kortsluter starka lösenord. Ett bättre alternativ är att e-posta ett nygenererat lösenord till en tidigare angiven adress.
• Lösenordspolicy: Det kan vara värt att införa en policy som styr minimilängd, förekomst av siffror och specialtecken med mera. Det angivna lösenordet skulle också kunna kontrolleras mot en ordlista. Var försiktig med att sätta en livslängd på lösenordet. Användare hatar att byta lösenord och tenderar att rotera gamla lösenord eller börja använda svaga lösenord om de tvingas byta allt för ofta.
• Online-attacker: För att undvika ordboksattacker mot inloggningssidan bör fördröjningar och inaktiveringar läggas in. Exempelvis kan ett konto inaktiveras i 15 minuter efter 10 misslyckade inloggningsförsök. Tyvärr kan denna metod användas för att stänga ute legitima användare, varför metoden bör användas med motta.

Skulle dessa råd kunnat förhindra attackerna mot Aftonbladet, Dataföreningen, SvenskaFans och Bilddagboken? Nej, men skadan skulle ha blivit mindre då färre lösenord skulle ha knäckts. I ett av fallen var lösenorden i klartext och i de andra fallen var hashningen bristfällig. Att förhindra att en angripare kommer åt lösenordsdatabasen, exempelvis genom att använda "sql injection", är högsta prioritet. Men det gäller att ha god säkerhet på alla nivåer för att minska skadan, och därför är säker lösenordshantering viktigt.

Varför bry sig om säker hantering av lösenord då lösenord i sig är en säkerhetsrisk? Användare skriver upp lösenord, använder samma lösenord på olika system och så vidare. I dagsläget anser många bevisligen att lösenord ger en tillräcklig god säkerhet, och att det skulle kosta för mycket i pengar eller användbarhet att använda andra säkrare lösningar. Hur många användare skulle Bilddagboken tappa ifall de började köra med skrapkoder? Vi kommer med andra ord få dras med lösenord en lång tid framåt och då är det lika bra att implementera systemen så säkert som det bara går.

Mer information:
PKCS #5: Password-Based Cryptography Standard