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

Verkligheten är att kompromisser för lösenordsdatabaser är 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 ge 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 pre-berä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ä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. 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änster ofta att de inte oroar 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 hashordlösenord under 2012.

Dåligt lösenordsförfarande

Detta är inte det svåraste att implementera , men många webbplatser klarar fortfarande att förstöra det på flera olika sätt:

• Lagra lösenord i vanlig text : I stället för att störa hash kan vissa av de värsta brottslingarna bara dumpa lösenorden i vanligt textform till en databas. Om en sådan databas äventyras är dina lösenord uppenbarligen skadade. 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 sedan kontrollera 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 salt, men de kan å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ändning av 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. Om en enda siffra användes som ett salt, kan angriparen enkelt 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 ett lösenord hade hashed (eller hashed och saltat), kan de inte använda 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.

Så många använder sig av uppenbara lösenord som det troligen skulle vara var 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.

RELATERAD: Hur Attackers Actually "Hack Accounts" Online och Så här skyddar du dig själv

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

Andra personuppgifter leker 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 - 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 agera i enlighet därmed.

Använd inte lösenord på flera webbplatser för det första. 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 använder det på nytt - men det borde du inte göra det för det första.

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

Så här använder du Java, Silverlight och andra plugins i moderna webbläsare

De senaste versionerna av Google Chrome, Mozilla Firefox och Microsoft Edge stöder bara Flash-plugin. Du måste hitta en alternativ webbläsare om du vill använda Java, Silverlight eller något annat ActiveX eller NPAPI-baserat plugin. De flesta webbanvändare kan komma undan utan dessa plugins. Det är därför som webbläsarutvecklare inte stöder dem längre.

(how-top)

Så här byter du region på din Nintendo Switch (och spelar spel från andra länder)

Med Switch har Nintendo lämnat en lång arv av regionlåsande konsoler. Nu, om du köper en konsol i USA kan du köpa patroner från Japan, eller bläddra i andra regionens eShops för nya spel eller billigare priser. Så här byter du region på din Switch. Medan omkopplaren inte är regionlåsad finns det fortfarande vissa skillnader som kan göra att regionerna ändras snabbare.

(how-top)