Varför du borde oroa dig när en tjänst lösenordsdatabas läcker ut

"Vår lösenordsdatabas blev stulen igår. Men oroa dig inte: dina lösenord var krypterade. "Vi ser regelbundet uttalanden som den här online, inklusive igår, från Yahoo. Men borde vi verkligen ta dessa försäkringar till nominellt värde?

Verkligheten är kompromisserna med lösenordsdatabaser är en oro, oavsett hur ett företag kan försöka snurra det. Men det finns några saker du kan göra för att isolera dig själv, oavsett hur illa ett företags säkerhetspraxis är.

Hur lösenord ska sparas

Så här ska företag lagra lösenord i en idealisk värld: Du skapar ett konto och anger ett lösenord. Istället för att lagra själva lösenordet genererar tjänsten en "hash" från lösenordet. Detta är ett unikt fingeravtryck som inte kan vändas om. Till exempel kan lösenordet "lösenord" bli till något som ser mer ut som "4jfh75to4sud7gh93247g ...". När du anger ditt lösenord för att logga in genererar tjänsten en hash från den och kontrollerar om hashvärdet matchar det värde som lagras i databasen. På något sätt sparar tjänsten någonsin ditt lösenord själv till disken.

För att bestämma ditt faktiska lösenord måste en angripare med tillgång till databasen förberäkna hasherna för vanliga lösenord och kontrollera om de finns i databasen. Attackers gör det med uppslagstabeller - stora listor över hash som matchar lösenord. Käftarna kan då jämföras med databasen. Till exempel skulle en angripare känna till hash för "password1" och sedan se om några konton i databasen använder den hash. Om de är, vet angriparen att deras lösenord är "password1".

För att förhindra detta bör tjänsterna "salta" sina haschar. I stället för att skapa en hash från själva lösenordet lägger de till en slumpmässig sträng till framsidan eller slutet av lösenordet innan det har halkat det. Med andra ord skulle en användare skriva in lösenordet "lösenord" och tjänsten skulle lägga till saltet och hash ett lösenord som ser mer ut som "password35s2dg." Varje användarkonto ska ha sitt eget unika salt och detta skulle säkerställa att varje användarkonto skulle ha ett annat hashvärde för deras lösenord i databasen. Även om flera konton använde lösenordet "password1", skulle de ha olika haschar på grund av de olika saltvärdena. Detta skulle besegra en angripare som försökte förberäkna hash för lösenord. I stället för att kunna generera hashser som applicerades på varje användarkonto i hela databasen samtidigt, skulle de behöva skapa unika haschar för varje användarkonto och dess unika salt. Detta skulle ta mycket mer beräkningstid och minne.

Därför säger tjänsten ofta att inte oroa sig. En tjänst som använder lämpliga säkerhetsprocedurer bör säga att de använde saltade lösenordshackar. Om de bara säger att lösenorden är "hashed", är det mer oroande. LinkedIn har till exempel sina lösenord, men de har inte saltat dem, så det var en stor sak när LinkedIn förlorade 6,5 miljoner hashed lösenord under 2012.

Dåliga lösenordspraxis

Det här är inte det svåraste att implementera, men många webbplatser lyckas fortfarande krossa det på olika sätt:

Lagring av lösenord i vanlig text: I stället för att bry sig om hash kan vissa av de värsta brottslingarna bara dumpa lösenorden i vanlig textform till en databas. Om en sådan databas äventyras är dina lösenord uppenbarligen komprometterade. Det spelar ingen roll hur stark de var.
Hashing lösenorden utan att salta dem: Vissa tjänster kan ha lösenord och ge upp där och väljer att inte använda salter. Sådana lösenordsdatabaser skulle vara mycket sårbara för uppslagstabeller. En angripare kan generera hash för många lösenord och kontrollera sedan om de fanns i databasen - de kunde göra det för varje konto omedelbart om inget salt användes.
Återanvändning av salter: Vissa tjänster kan använda ett salt, men de får återanvända samma salt för varje användarkonto lösenord. Detta är meningslöst - om samma salt användes för varje användare skulle två användare med samma lösenord ha samma hash.
Använda Korta Salter: Om salter med några få siffror används skulle det vara möjligt att generera uppslagstabeller som innehåller alla möjliga salt. Till exempel, om en enstaka siffra användes som ett salt, skulle angriparen enkelt kunna generera listor över haschar som inkorporerade alla möjliga salt.

Företagen kommer inte alltid att berätta hela historien, så även om de säger att ett lösenord hade hashed (eller hashed och saltat), kanske de inte använder de bästa metoderna. Ta alltid fel på försiktighetssidan.

Andra problem

Det är troligt att saltvärdet också finns i lösenordsdatabasen. Detta är inte så illa - om ett unikt saltvärde användes för varje användare, skulle attackerna behöva spendera massiva mängder av CPU-ström som bryter mot alla dessa lösenord.

I praktiken använder så många personer tydliga lösenord som det är troligt att det är lätt att bestämma många användarkonton lösenord. Om till exempel en angripare känner till din hash och de vet ditt salt, kan de lätt kontrollera om du använder några av de vanligaste lösenorden.

Om en angripare har det för dig och vill knäcka ditt lösenord, kan de göra det med brute force så länge som de vet saltvärdet - vilket de förmodligen gör. Med lokal, offlineåtkomst till lösenordsdatabaser kan angripare använda alla de brutna våldsattackerna de vill ha.

Andra personuppgifter läcker också sannolikt när en lösenordsdatabas är stulen: Användarnamn, e-postadresser och mer. När det gäller Yahoo läckan läcktes också säkerhetsfrågor och svar, vilket, som vi alla vet, gör det enklare att stjäla tillgång till någons konto.

Hjälp, vad ska jag göra?

Vad en tjänst säger när dess lösenordsdatabas är stulen, är det bäst att anta att varje tjänst är fullständigt inkompetent och agera i enlighet därmed.

Först, använd inte lösenord på flera webbplatser. Använd en lösenordshanterare som genererar unika lösenord för varje webbplats. Om en angripare lyckas upptäcka att ditt lösenord för en tjänst är "43 ^ tSd% 7uho2 # 3" och du bara använder det lösenordet på den specifika webbplatsen, har de inte lärt sig något användbart. Om du använder samma lösenord överallt kan de komma åt dina andra konton. Det här är hur många människors konton blir "hackade".

Om en tjänst blir äventyrad måste du ändra det lösenord du använder där. Du bör också ändra lösenordet på andra webbplatser om du återanvänder det där - men det borde du inte göra i första hand.

Du bör också överväga att använda tvåfaktorsautentisering, vilket skyddar dig även om en angripare lär sig ditt lösenord.

Det viktigaste är att inte återanvända lösenord. Kompromissade lösenordsdatabaser kan inte skada dig om du använder ett unikt lösenord överallt - om inte de lagrar något annat viktigt i databasen, som ditt kreditkortsnummer.

Bildkredit: Marc Falardeau på Flickr, Wikimedia Commons