IT-säkerhet enligt HPS

Update @2011-10-26: Aftonbladet rapporterar om ett 50-tal ytterligare siter, dessa är t o m äldre än Bloggtoppen, samma lirare publicerade dem för över två månader sedan.

Våren 2008 saknar egentligen fortfarande motstycke gällande läckta lösenord: Efterfesten och Bilddagboken samt ett par andra mindre siter trillade dit i en våg av intrång från nyår och framåt. (Sök på "efterfesten hackat" eller motsvarande.) Sammantaget handlade det om ett par hundra tusen lösenord som var svagt skyddade. Fest utbröt på Flashback och Fragbite, många mail- och Facebook-konton (med samma lösenord) fick lida i efterdyningarna.

Nu har sidan Bloggtoppen har blivit av med mellan 50 och 90 000 vanilj-MD5-hashade lösenord. Det har under dagen rapporterats i mainstream-media, t o m på TV och radio. Dock inte för att det rör sig om många lösenord eller för att hasharna, även den här gången, var värdelösa. Nej, förmodligen bara för att några av dem twittrades på en politikers kapade konto. Jaja...

 

Anmärkningsvärt nog var det ganska precis en månad sedan som läckan skedde och det var inte heller i "undergroundkretsar" utan det var mitt på ljusa dagen på ni-vet-vilket-forum. SQL injection, förstås. Än mer anmärkningsvärt är att SVT ger en väldigt... öppensinnig(?) rapportering i artikeln Kolla om du finns med i Bloggtoppen-läckan. De länkar till databasdumpen och berättar (i princip) hur man gör för att knäcka MD5-hashar. Enligt SVT kunde de enkelt knäcka 80 % av lösenorden m h a en vanlig rainbow-site.

 

Säker lagring av lösenord

"Hur ska man hasha lösenord?" är det nog många söker på (SEO FTW) så vi tar det kort. Svaret är egentligen förvillande enkelt men jag utvecklar det lite här för sakens skull (något ska man ju ha att göra på tisdagkvällar). Låt mig citera vad en av mina favoritböcker, Security Engineering, säger om hashfunktioner på sidan 141:

 

The first main property of a random function is one-wayness. [...] A second property of pseudorandom functions is that the output will not give any information at all about even part of the input. [...] A third property of pseudorandom functions with sufficiently long outputs is that it is hard to find collisions.

 

Det är egentligen bara den första som är intressant i fallet med lösenordslagring. Det ska vara svårt att gå från h(x) till x där h(x) är hashen av lösenordet x. Vetskap om hash ska inte innebära vetskap om lösenord.

 

Enligt databasdumpen från Bloggtoppen var det någon anställd på Aftonbladet som hade lösenordet "tejp" och Bloggtoppen använde hashfunktionen MD5. Alltså:

 

MD5(tejp) = 24b5c8dc3ae3aa06240d463dd681d8ab

 

Problemet är att det inte är svårt att gå från lösenordshashen "24b5c8dc3ae3aa06240d463dd681d8ab" till lösenordet "tejp". Det är lätt. Den huvudsakliga anledningen till detta är att lösenordet är svagt; "tejp" är, som bekant, inte ett särskilt starkt lösenord.

Problemet är att även lösenord som "jonathan28" kan knäckas relativt enkelt och det är ju inte lika väntat. Det är ju trots allt tio tecken långt och inte helt värdelöst. Nu skulle jag inte längre hävda att det huvudsakligen är lösenordets fel att det knäcktes, det är hashfunktionen, MD5:s fel. I klartext, beräkningarna som en dator måste göra för att beräkna h(x) från x är för få vilket innebär att man kan gissa lösenord för snabbt. För MD5 är sex miljoner lösenordsgissningar i sekunden inga konstigheter för en vanlig, gammal laptop som min med vanlig COTS-programvara som Cain. Med den bakgrunden är det klart att Jonathan får problem.

 

Således, det måste krävas fler beräkningar för att beräkna h(x) från x, fler beräkningar för att gissa ett lösenord, helt enkelt.

 

En "hashfunktion" som har denna egenskap är PBKDF2 eller Password-based key derivation function 2 som egentligen används för att göra en kryptonyckel av ett lösenord. Förutom denna egenskap (tekniken bakom heter key stretching) som teoretiskt kan tvinga ner en angripare i ett par hundra gissningar i sekunden har den även key salting som inför ytterligare en önskvärd egenskap i lösenordshasharna: att samma lösenord aldrig hashas likadant varje gång. Jag har inte gått in på det här ovan men saltet hindrar de där sex miljonerna gissningar per sekund från att bli många miljoner fler med hjälp av en time-memory tradeoff-princip (sök på "rainbow tables").

 

Så, använd PBKDF2 för att hasha dina användares lösenord. Om du samtidigt tvingar användare att välja relativt starka lösenord skulle du, åtminstone i teorin, inte behöva oroa dig ifall en databasdump kommer på vift. Och varför skulle man annars ödsla tid med att hasha lösenorden från första början?

 

--

Stefan Pettersson