Spotify säkerhetsproblem + Hash på KTH

Efter att vi förra veckan fick reda på att vår favvotjänst Spotifys protokoll är knäckt till en opensource-klient, damp det ikväll ner ett mail där Spotify berättar om säkerhetsproblem. Inte konstigt att lamporna lyser sent i kontoret i Stockholm:

Min tolkning av vad som kommunicerats: Ifall någon:

1. ...kände till protokollet som blev känt som öppnat så sent som förra veckan, samt
2. ...lattjade med det innan 19 december förra året (då en viss bugg fixades) så har de potentiellt kunnat komma åt en, märk, saltad lösenordshash ifall man vetat någons användarnamn.
3. ...Ifall man kunnat knäcka denna hash (möjligt för enkla/korta/dåliga lösenord) möjliggör det sen att man kunnat hämta annan information på kontot som adress, kön etc.
   

Eventuellt finns nu alltså användardata och lösenord på drift. Dessutom kan ett knäckt lösenord i kombination med epostadressen användas för att logga in på andra ställen då ofta folk har samma lösenord överallt.

MEN: Ingen databas på drift och inga adminkonton knäckta verkar det som. Med andra ord.. ingen kris, även om det inte låter så bra. Aftonbladet skriver exempelvis om det, liksom IDG. Här uppmärksammar Magnus Jonasson det hela.

Bra krishantering tycker jag i mailet som skickades ut... Brevet som sändes ut tycker jag är stark "krishantering". undra förresten ifall de har utsatts för utpressningsförsök - annars brukar ju sånt här komma ut på annat håll först...

Spotify uppmanar nu användare att byta lösenord, något som får sajten att se ut som till höger under alltför högt tryck när säkert ganska många av miljonen
användare försöker byta lösenord samtidigt. Ifall du nu ska byta lösenord borde du kika på den här posten om hur man kan skapa supersäkra lösenord: Lösenordssäkerhet + Målformulering = Sant.

Fler gamla lösenordesproblem:

• Dataföreningen hackad av VFH
• Bilddagboken hackad

- - -

Förresten, en liten teknisk utvikning: Jag har bakgrund från KTH och där när någon frågar om "hasch" så är det inte en femma svart afghan folk menar utan "hash" - sättet som exempelvis lösenord sparas eller hanteras genom olika standardiserade kontrollsummegenerarande algoritmer. Exempelvis IN: ett lösenord - UT: ett 128 bitars teckenrad.

Vill du se vad en hashningsfunktion som MD5 (Message Digest 5) genererar - öppna då exempelvis Macens terminalfönster eller motsvarande i Linux/Dos och skriv "md5 -s dittlösenord". Nu kommer en "hash" att genereras för lösenordet, och det är detta som ofta sparas som "krypterat" i användardatabaser. Haken är att det finns rainbow-tables ute på nätet eller nerladdningsbara som gör den motsatta funktionen.

Exempelvis här knäcker vi lätt hashen "925d7518fc597af0e43f5606f9a51512" och får fram "martin" på nolltid.

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.

Man kan också som kodare använda den säkrare hash-algoritmen SHA1 (Secure Hash Algoritm). Läs mer om de spännande funktionerna på Wikipedialänkarna!

UPDATE: David Hall på Månhus, duktig på datasäkerhet tycker det här behöver förtydligas och utvecklar bra: 26a8012b7f9b9c441bcca35eeec32f18, exempelvis att SHA1 utan salt inte är bättre än MD5 med samt att användarnamnet inte är optimalt som salt. Mina rader ovan ska ses som snabba från-höften-kommentarar för att bidra med en överblick.

En sak kan jag dock med säkerhet säga - när det gäller sökmotoroptimerade titlar på blogginlägg har David en del att lära :P

- - -

UPPDATERING: DeSpotify: Vi vill inte skada Spotify

"Det enda som krävdes var att lägga till en delad spellista. Som svar spottade Spotify ut en uppsjö detaljer om ägarkontot. Namn, födelsedatum, e-postadress och en krypterad lösenordsfil."