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

"Vår lösenord databas blev stulen igår. Men oroa dig inte: dina lösenord krypterades. "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 kompromisser för 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 ideal värld: Du skapar ett konto och anger ett lösenord. I stä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. Lösenordet "lösenord" kan till exempel omvandlas 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 hash för vanliga lösenord och kontrollera sedan om de finns i databasen. Attackers gör det med uppslagstabeller - stora listor med 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. Istä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ändarkontoskulle 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. Istället för att kunna generera hashser som applicerades på varje användarkonto i hela databasen på en gång, 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 rätt säkerhetsprocedurer bör säga att de använde saltad lösenordshastighet. 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.

Bad Password Practices

Detta är inte det svåraste att implementera, men många webbplatserklarar fortfarande att rota upp det på flera olika sätt:

• Lagra lösenord i vanlig text : I stället för att stör med 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 inkorporerade alla möjliga salt. Till exempel, om en enstaka siffra användes som ett salt, skulle angriparen enkelt kunna generera listor över hackar som inkorporerade alla möjliga salt.

Företag 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. Var alltid fel på försiktighetssidan.

Andra problem

Det är troligt att saltvärdet också finns i lösenordsdatabasen. Det här är inte så illa - om ett unikt saltvärde användes för varje användare, skulle attackerna behöva spendera massiva mängder CPU-ström som bryter mot alla 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 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 ut för dig och vill spricka 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 lättare 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 helt inkompetent och agerar i enlighet därmed.

Använd först 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, var god och ändra det lösenord du använder där. Du bör också ändra lösenordet på andra webbplatser om du återanvända 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