Miljoner lösenord till LinkedIn på vift

Jag hade aldrig hört talas om LinkedIn, men efter lite googling så tolkar jag det som en mer seriös variant av Facebook. Alltså att man har mer seriösa kontakter och inte informerar sina vänner varje gång man besöker toaletten eller liknade stora händelser i livet.

Nå annars bör såklart användare av tjänsten byta lösenord och vi andra även tänka på hur vi har våra. Detta vore faktisk ett bra reportage som de kunde ha här på sweclockers om olika sätt man kan göra för att lösenordsproblemet? Det finns flera olika system, min erfarenhet är dock att folk i allmänhet knappt funderar på säkerhet. T.ex. använder lösenordet på främmande dator utan det rädsla för att råka ut för keyloggers..

Nästan varenda tjänst idag kräver att man använder lösenord, dessutom ska man kunna x-antal pinkoder för alla olika apparater man har. Att ha olika lösenord på allt är inte praktisk möjligt för många. Ha samma lösenord på några tjänster, så är det svårt att minnas vilka ifall man skulle bli av med något.

Så jag skulle faktisk veta hur man bör hantera lösenord på ett praktisk fungerande sätt. Som det är idag så är det mer mer för mig att hoppas på det bästa och ha brister i sitt lösenordssystem, där bristerna har fördelar att jag faktisk kan minnas lösenordet för de viktigaste tjänsterna..

Jag vet inte hur mycket det används i sverige men här har alla som har ett mer kvalificerat jobb ett konto på linkedin för att kunna få bättre jobb genom kontakter etc. Mycket jobbsökande sker genom det.

Ja, det låter tyvärr troligt. Jag kan inte begripa varför denna inkompetens existerar. Jag menar, salt är ju så basalt i dessa sammanhang att det är svårt att tänka sig en programmerare som vet vad kryptografiskt hash är utan att ha en susning om att salt ska användas.

För er alla på forumet som händelsevis inte vet vad vi talar om ska jag försöka mig på en kort förklaring:
Hash är en så kallad envägsfunktion som ger en specifikt kod för varje meddelande. Koden är alltid lika lång. Det spelar ingen roll om du hashar en bit eller en terabyte, hasen blir ändå t.ex. 128 bitar lång. Givetvis finns det, av matematisk nödvändighet, flera meddelanden som ger samma hash. Detta kallas för kollision, men ingenting som man behöver bry sig om i detta sammanhang.

Lösenord skyddas genom att aldrig lagras. Endast hashen lagras. På så sätt kan man aldrig "läsa" eller "avkryptera" ett lösenord. I stället hashas lösenordet som anges och jämförs med det lagrade hashet. Är de samma är lösenordet korrekt (eller en kollision, men det är utomordentligt osannolikt).

Nu råkar det vara så att alla identiska lösenord blir till identiska hash. Så, om någon får tag i en hashdatabas och lyckas knäcka ett enda hash (genom att generera testlösenord och se vad dessa får för hash) så kommer denna person automatiskt få lösenordet till *alla* som råkar ha samma lösenord (men olika login). Eftersom människor är taskiga slumpgeneratorer och många väljer "pwd123" eller något annat idiotisk är sannolikheten stor att ett enda knäckt hash leder till massor av exponerade lösenord. Detta löses enkelt genom att man alltid adderar extra data helt slumpmässigt till lösenordet. Denna data kallas för "salt" (man "saltar" hashet). Saltet i sig måste inte vara hemligt utan lagras i klartext i databasen. Det är bra om även saltet är hemligt, men det är inte alls nödvändigt. Så, två stolpskott som har "pwd123" som lösenord kommer få olika hash tack vare olika salt. Saltet slumpas fram helt godtyckligt när lösenordet skapas och saltet+hashet lagras i "lösenordsdatabasen". Nu, om någon knäcker "pwd123" plus saltet "lsrijhtw" så kommer det inte hjälpa denne att identifiera andra lösenord "pwd123" eftersom då hashet då t.ex. är "324lj65htkj" i stället. Så det enda en cracker kan veta är då:
? + "lsrijhtw" = 0x1ab2c3d4... (hash)
? + "324lj65htkj" = 0x3a12ef8a..."
osv. osv. Även om "?" är samma lösenord kan inte knäckningen av det första avslöja att det andra också det samma.

Salt är alltså ett snorenkelt och sketabilligt sätt att göra lösenord väldigt, väldigt mycket säkrare. Det är skillnaden mellan att brute-forca ett fåtal och vinna insikter om resten vid varje knäckning, eller att behöva börja från början vid varje enskilt lösenord/hash. Det kostar så lite i kodutrymme och utvecklingstid (även på en simpel mikrokontroller) att det bara är skamvrån som gäller. Finns inga tekniska eller ekonomiska ursäkter.

Ja, det låter tyvärr troligt. Jag kan inte begripa varför denna inkompetens existerar. Jag menar, salt är ju så basalt i dessa sammanhang att det är svårt att tänka sig en programmerare som vet vad kryptografiskt hash är utan att ha en susning om att salt ska användas.

För er alla på forumet som händelsevis inte vet vad vi talar om ska jag försöka mig på en kort förklaring:
Hash är en så kallad envägsfunktion som ger en specifikt kod för varje meddelande. Koden är alltid lika lång. Det spelar ingen roll om du hashar en bit eller en terabyte, hasen blir ändå t.ex. 128 bitar lång. Givetvis finns det, av matematisk nödvändighet, flera meddelanden som ger samma hash. Detta kallas för kollision, men ingenting som man behöver bry sig om i detta sammanhang.

Lösenord skyddas genom att aldrig lagras. Endast hashen lagras. På så sätt kan man aldrig "läsa" eller "avkryptera" ett lösenord. I stället hashas lösenordet som anges och jämförs med det lagrade hashet. Är de samma är lösenordet korrekt (eller en kollision, men det är utomordentligt osannolikt).

Nu råkar det vara så att alla identiska lösenord blir till identiska hash. Så, om någon får tag i en hashdatabas och lyckas knäcka ett enda hash (genom att generera testlösenord och se vad dessa får för hash) så kommer denna person automatiskt få lösenordet till *alla* som råkar ha samma lösenord (men olika login). Eftersom människor är taskiga slumpgeneratorer och många väljer "pwd123" eller något annat idiotisk är sannolikheten stor att ett enda knäckt hash leder till massor av exponerade lösenord. Detta löses enkelt genom att man alltid adderar extra data helt slumpmässigt till lösenordet. Denna data kallas för "salt" (man "saltar" hashet). Saltet i sig måste inte vara hemligt utan lagras i klartext i databasen. Det är bra om även saltet är hemligt, men det är inte alls nödvändigt. Så, två stolpskott som har "pwd123" som lösenord kommer få olika hash tack vare olika salt. Saltet slumpas fram helt godtyckligt när lösenordet skapas och saltet+hashet lagras i "lösenordsdatabasen". Nu, om någon knäcker "pwd123" plus saltet "lsrijhtw" så kommer det inte hjälpa denne att identifiera andra lösenord "pwd123" eftersom då hashet då t.ex. är "324lj65htkj" i stället. Så det enda en cracker kan veta är då:
? + "lsrijhtw" = 0x1ab2c3d4... (hash)
? + "324lj65htkj" = 0x3a12ef8a..."
osv. osv. Även om "?" är samma lösenord kan inte knäckningen av det första avslöja att det andra också det samma.

Salt är alltså ett snorenkelt och sketabilligt sätt att göra lösenord väldigt, väldigt mycket säkrare. Det är skillnaden mellan att brute-forca ett fåtal och vinna insikter om resten vid varje knäckning, eller att behöva börja från början vid varje enskilt lösenord/hash. Det kostar så lite i kodutrymme och utvecklingstid (även på en simpel mikrokontroller) att det bara är skamvrån som gäller. Finns inga tekniska eller ekonomiska ursäkter.