26a8012b7f9b9c441bcca35eeec32f18

· 478 ord · 3 minut(er) att läsa

Martin Sandberg skriver om säkerhetsbristen som fanns i Spotify innan mitten av december då man kunde få ut en saltad hash av valfri användares lösenord. (via Joakim Jardenberg)

Kan tillägga att jag, av lärare från KTH, sett stavningen av hash försvenskad till hasch vilket gör att man inte ens i skrift kan skilja substansen och det datalogiska begreppet åt.

Nu är sajter som tar säkerheten seriöst bättre än så här. Exemplevis Spotify använder “saltade” funktioner, dvs stoppar in ett annan data tillsammas med ursprungslösenordet - ofta tar man något kopplat till användarnamnet, ett user-id etc. Då blir säkerheten högre, men ändå uppmanar alltså Spotify oss att byta.

Nej, man bör inte ta användarnamnet som (enda) salt till hashen. Det ökar förstås komplexiteten något men det gör det fortfarande möjligt att sammanställa en rainbow table som kan återanvändas vid attackförsök på olika ställen om de lägger till saltet på samma sätt. Man bygger i förväg upp en tabell med hashar av “lösenord+användarnamn” för de vanligaste lösenorden och de vanligaste användarnamnen som man kan återanvända på system som bygger upp hashen på samma sätt. Förutom de universellt vanligaste lösenorden kan man lägga till användarnamnet självt som lösenord samt användarnamnet baklänges osv. Regnbågstabellen blir a gånger större för a användare så det blir betydligt besvärligare än helt utan salt men det är dumt när man kan offra en kolumn i användardatabasen till att ha ett unikt, slumpgenererat, salt per användare. Därigenom omöjliggör man möjligheten för någon att utnyttja tabeller gjorda på förhand och en attackerande dator måste hasha kombinationen möjliga lösenord och givet salt för varje användare.

Man kan också som kodare använda den säkrare hash-algoritmen SHA1 (Secure Hash Algoritm).

Man ska absolut inte tolka det här som att man ska använda sig av enbart SHA-1 istället för MD5 + salt. Saltar man inte en SHA-1-hash så är det lika enkelt att använda regnbågstabeller där.

Sedan ska man vara uppmärksam att man i MD5 inte bara hittat kollisioner (dvs. hittat två olika strängar som ger samma hash) utan även kan få med valfri text som en del av dessa strängar. Så med ett gäng Playstation-3:or kan man förutsäga vem som blir USA:s nästa president eller skapa falska webbplatscertifikat. Därför bör man inte använda MD5 som hashfunktion. I takt med att hårdvara blir snabbare och bristerna i MD5 utreds mer kan det visa sig bli möjligt att få fram rätt lösenord (eller ett av de korrekta lösenorden, även om det inte lär finnas någon kollision med lösenordens begränsade längd) givet en saltad hash på kort tid.

Vad gäller SHA-1 har man teoretiskt visat svagheter så att man skulle kunna finna kollisioner som kräver färre beräkningar än ren brute-force även om man ännu inte hittat någon kollision. Däremot har man hittat kollisioner för delresultat av SHA-1 (vid 70 pass av totala 80). Så man bör kanske inte heller välja SHA-1 för framtida bruk.