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

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

ange ditt lösenord

”Vår lösenordsdatabas stalades 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 ska vi verkligen ta dessa försäkringar till nominellt värde?

Verkligheten är att lösenordsdatabasen komprometterar är 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, oavsett hur dåliga ett företags säkerhetspraxis är.

Hur lösenord ska lagras

Så här ska företag lagra lösenord i ettidealvä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. Till exempel kan lösenordet "lösenord" förvandlas 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 det och kontrollerar om hashvärdet stämmer med värdet som lagras i databasen. På ingen punkt sparar tjänsten någonsin ditt lösenord på hårddisken.

kryptografisk-hash-funktion

För att bestämma ditt faktiska lösenord, en angriparemed åtkomst till databasen skulle behöva förberäkna hasherna för vanliga lösenord och sedan kontrollera om de finns i databasen. Angripare gör detta med uppslagstabeller - enorma listor med hascher som matchar lösenord. Hashar kan sedan 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 hash. Om de är det, så känner angriparen att deras lösenord är ”password1”.

För att förhindra detta bör tjänsterna "salta" sinahashes. Istället för att skapa en hash från själva lösenordet lägger de till en slumpmässig sträng framtill eller i slutet av lösenordet innan de haskar det. Med andra ord skulle en användare ange lösenordet "lösenord" och tjänsten lägger till salt och hash ett lösenord som ser mer ut som "password35s2dg." Varje användarkonto bör ha sitt eget unika salt, och detta skulle säkerställa att varje användarkonto skulle ha ett annat hashvärde för sitt lösenord i databasen. Även om flera konton använde lösenordet "password1", skulle de ha olika hash på grund av de olika saltvärdena. Detta skulle besegra en angripare som försökte beräkna hash för lösenord. Istället för att kunna generera hash som tillämpades på varje användarkonto i hela databasen på en gång måste de generera unika hash för varje användarkonto och dess unika salt. Detta skulle ta mycket mer beräkningstid och minne.

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

Dåliga lösenordsmetoder

klartext-lösenord-databas

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

  • Lagra lösenord i vanlig text: Snarare än att bry sig om hasning, några avvärsta gärningsmän kan bara dumpa lösenorden i vanlig textform i en databas. Om en sådan databas komprometteras är dina lösenord uppenbarligen komprometterade. Det spelade ingen roll hur stark de var.
  • Haga lösenorden utan att salta dem: Vissa tjänster kan hash lösenord och gedär uppe och väljer att inte använda salter. Sådana lösenordsdatabaser skulle vara mycket sårbara för uppslagstabeller. En angripare kan generera hasherna för många lösenord och sedan kontrollera om de fanns i databasen - de kunde göra detta för varje konto på en gång om inget salt användes.
  • Återanvända salter: Vissa tjänster kan använda salt, men de kanåteranvända samma salt för varje lösenord för användarkonton. 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 bara några siffror används är detskulle vara möjligt att generera uppslagstabeller som innehåller alla möjliga salt. Till exempel, om en enstaka siffra användes som ett salt, kunde angriparen enkelt generera listor med hasjer som inkluderade alla möjliga salt.

Företag berättar inte alltid hela historien, så även om de säger att ett lösenord har hashats (eller hashats och saltats) kanske de inte använder bästa praxis. Fel alltid på sidan med försiktighet.

Andra bekymmer

Det är troligt att saltvärdet också finnsi lösenordsdatabasen. Detta är inte så illa - om ett unikt saltvärde användes för varje användare, skulle angriparna behöva spendera enorma mängder CPU-kraft för att bryta alla dessa lösenord.

I praktiken använder så många uppenbara lösenordatt det sannolikt skulle vara lätt att bestämma många användarkontonas lösenord. Till exempel, om en angripare känner till din hash och de känner till ditt salt, kan de enkelt kontrollera om du använder några av de vanligaste lösenorden.

RELATERAD: Hur angripare faktiskt "hackar konton" online och hur du skyddar dig själv

Om en angripare har det åt dig och villknäcka ditt lösenord, de kan göra det med brute kraft så länge de vet saltvärdet - vilket de förmodligen gör. Med lokal, offlineåtkomst till lösenordsdatabaser, kan angripare anställa alla de våldsattacker de vill ha.

Andra personuppgifter läcker sannolikt också när alösenordsdatabasen ä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 åtkomst till någons konto.

Hjälp, vad ska jag göra?

Oavsett 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.

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 lärt sig inget användbart. Om du använder samma lösenord överallt kan de få åtkomst till dina andra konton. Så här blir många konton "hackade".

generera-random-lösenord

Se till att om en tjänst komprometterasändra lösenordet du använder där. Du bör också ändra lösenordet på andra webbplatser om du återanvänder det där - men du borde inte göra det i första hand.

Du bör också överväga att använda tvåfaktorautentisering, vilket skyddar dig även om en angripare lär dig 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 - såvida de inte lagrar något annat viktigt i databasen, som ditt kreditkortsnummer.

Bildkredit: Marc Falardeau på Flickr, Wikimedia Commons