Användare använder ofta samma lösenord på flera webbplatser. Din webbplats kanske inte har några finansiella data, men vad händer om samma lösenord används för deras bank eller för en onlinebutik?

Du kan hävda att detta inte är ditt problem, men det är vanligt problem, och det är därför varje gång ett intrång inträffar, är en av de omedelbara uttalandena "ändra ditt lösenord och ändra det på andra webbplatser där du har använt samma lösenord".

Om din webbplats använde något som Bcrypt (utan brister i implementeringen - se Ashley Madison) är chansen att en angripare kan räkna ut vilka lösenord som har använts smalare, och det ökar tiden för användare att kunna ändra sina lösenord någon annanstans. Om du bara lagrar lösenordet i din DB utan hashing kan en angripare vandra iväg med e-postadresserna och lösenorden och börja attackera en annan webbplats omedelbart.

E-postadress och lösenordspar handlas ofta mellan angripare också, i form av "kombinationslistor", vilket innebär att även om den ursprungliga angriparen bara är intresserad av din webbplats, kan de få fördelar genom att sälja informationen till någon annan.

Tillagt som svar på kommentar till fråga som nämner 2-vägs krypterad lagring

Problemet med en 2-vägs krypteringsmetod är att informationen som ska dekrypteras måste lagras någonstans i systemet. Om en angripare får åtkomst till din databas är det stor chans att de också har tillgång till din krypteringsnyckel. En hash kan inte vändas på det här sättet - onlineverktyg för att vända hash slår effektivt upp hash i en förberäknad lista.

Även om de inte har krypteringsnyckeln kanske de kan för att räkna ut vad nyckeln var - de kan använda en känd vanlig textattack genom att ange ett lösenord till ditt system och se vad resultatet är. Det skulle förmodligen inte vara en snabb process, men det kan vara värt att göra om det fanns några mål med högt värde i dina uppgifter (kändisar, politiker ...).

Å andra sidan, med en stark, saltad hash, är det enda sättet att hitta det ursprungliga lösenordet med stor säkerhet att hash alla möjliga inmatningar, med lämpligt salt. Med något som Bcrypt skulle det ta år, även om svaga lösenord fortfarande kommer att hittas relativt snabbt.

Bra fråga, och jag är glad att du ställde den. Jag vill att folk ska hitta den här tråden när de googlar den så att de - förhoppningsvis - inte gör samma misstag som många andra företag gör.

Du borde inte bara hash lösenord, bör du salta och se till att din hashingalgoritm använder någon form av SlowEquals . Du ska inte sluta där: du bör använda en säker hashingalgoritm som i hög grad motstår kollisioner , till exempel bcrypt eller scrypt.

Varför salt? Vad är kollisioner?

Jag ska använda md5 som ett exempel eftersom det är mycket känt. Använd inte det, eftersom det är sårbart för kollisioner och är mycket snabbt vilket innebär att det är mycket lättare att bryta. Låt oss föreställa oss att du bara hash dina lösenord utan salt. Du skulle sluta producera en statisk effekt nästan varje gång.

Till exempel skulle " myDarnPassword " konverteras till " aca6716b8b6e7f0afa47e283053e08d9 " när det hashades som md5. Vid den här tiden kan du skapa en ordbokattack och använda regnbågstabeller. Du kan till och med skapa en databas som konverterar så många slumpmässiga tecken till en lätt sökbar databas som inte kräver tidskrävande regnbågsuppslag. Du kan långsamt skapa det över tiden och slå upp hash senare.

Du skulle skapa en tabell ser ut så här:

  + --------- ---------- + ---------------------------------- + | LÖSENORD | UNSALTED_HASH | + ------------------- + --------------------------- ------- + | myDarnPassword | aca6716b8b6e7f0afa47e283053e08d9 | + ------------------- + --------------------------- ------- + | snällaDontSueMe11 | 0dd395d0ec612905bed27020fb29f8d3 | + ------------------- + --------------------------- ------- +  

Då skulle du välja från databasen något så här:

  VÄLJ [lösenord] FRÅN [tabell] VAR [ unsalted_hash] = 'aca6716b8b6e7f0afa47e283053e08d9'  

Och det skulle returnera myDarnPassword , plus alla kollisioner som inträffat.

Med tillräcklig processorkraft och tid kan du skapa biljoner kombinationer och helt enkelt knäcka ett stort antal lösenord på mycket kort tid (jag kan rekommendera att dela upp databaser i lösenordslängder på grund av det stora antalet ). Du behöver dock en enorm mängd hårddiskutrymme för detta.

Vid den tiden är allt du behöver göra att leta upp det utan att slösa bort processorkraft på brute-tvingar allt varje gång. Och om du tidigare har stulit andras lösenord från en databas kan du lägga till dem och konvertera dem till hash. Många webbplatser har redan gjort detta.

När en webbplats validerar ditt lösenord, kommer de att jämföra lösenordet med den lagrade hash, och om det matchar hash i databasen anses det vara ett giltigt lösenord. Du kan då låta användaren logga in.

Saltning av hash kan hjälpa till att besegra denna attack, men det sparar inte dig mot kollisioner. Du kan jämföra hackade hashkoder med din hashlista som genererade kollisioner och sedan ange lösenordet på en webbplats, även om du har fel lösenord: så länge hashen validerar är du pwned .

Vem bryr sig om någon knäcker mina lösenord? Jag bryr mig inte!

Nedan följer bara en liten samling exempel på vad phishers och andra skadliga individer kan med dina oskadade och osaltade lösenord i klartext. Det kan inte nödvändigtvis användas för att rikta in dig direkt, men låt oss säga att Hacker vill rikta in sig på Person A . Låt oss härleda hur du kan rikta dig mot Person A .

1. Du är Hacker . Ditt jobb är att hacka webbplatser och utveckla en databas för att samla denna information.
2. Person A är en person av intresse. Person A dyker upp i en av dina hackade webbplatsers databaser. Du känner nu till deras e-postadress och lösenord de använder för den webbplatsen.
3. Nu kan du försöka logga in på deras e-postadress med lösenord du har stulit från den webbplatsen. Söta, det fungerar!
4. Nu när du har tillgång till deras e-post, laddar du ner alla deras e-postmeddelanden via IMAP eller via deras webb-e-post. Vid denna punkt hittar du massor av intressanta saker. De kommunicerar med Person B .
5. Du kan faktiskt google vissa människors användarnamn och e-postadresser, och det kan visa webbplatser de publicerar på. Detta kommer att visa andra webbplatser som användaren använder. Kanske kan du försöka hacka dessa webbplatser eller kanske bara dra slutsatser om vad de är intresserade av. Nu kan du låtsas vara som dem eller hitta ytterligare information. Information / aktiviteter kan inkludera:
   • Användarnamn . Person A postar online som Mark Buffalo . Det är ett relativt unikt namn. Du kan sedan googla Mark Buffalo och leta efter webbplatser som han publicerar på. Kanske avslöjar han mer av sin personlighet på andra webbplatser?
   • Lösenord . Kanske Mark Buffalo har samma lösenord på den webbplatsen. Kanske kan du logga in på den webbplatsen och se hans privata kommunikation med andra?
   • Personlig information . Eftersom du vet identiteten för Mark Buffalo , vad händer om han delar personlig information på certains webbplats? Vad händer om han lägger in på craigslist som söker efter manliga eller kvinnliga eskorter, och han har lämnat sitt telefonnummer där? Du har redan hittat hans telefoninformation så att du kan hitta ett sätt att ställa upp honom och utpressa honom för pengar / information / makt. Detta har inte mycket att göra med att salta lösenorden om du inte inkluderar telefonnumret, men de hittar sitt telefonnummer på en annan webbplats tack vare din läcka. Det är ett av de många mycket kraftfulla sätten att information kan samlas in och användas mot dig. Det här är trots allt ett Informationssäkerhet -forum, så jag vill använda detta exempel.
   • Familjinformation . Nu blir det läskigt. Vi har Mark Buffalos personliga information. Låt oss titta på hans sociala nätverk. Åh, han har ett Facebook -konto (jag har inte). Kan vi komma åt detta med samma lösenord? Om Buffalo använder samma lösenord / e-postkombination, då förmodligen. Och du kan nog dra slutsatsen från hans e-postmeddelande som du öppnade tidigare, där du hittade många intressanta saker. Vi kan nu logga in och läsa hans Facebook-meddelanden. Nu vet vi vem hans familjemedlemmar är. Vi kan sedan samordna utpressningsattacken lättare.
   • Annan inloggningsinformation . Eftersom vi fick tillgång till hans e-post tidigare ser vi att han också har ett Skype-konto. En av dem är hemlig. Vi loggar in och ser att han flörtar med människor på Skype. Vi har nu mer utpressningsmaterial.
   • Imitation . Du kan nu logga in och efterlikna Buffalo på en mängd olika webbplatser. Kanske är han faktiskt en rakskjutare och har aldrig gått efter några ledsagare eller något liknande? Nå, nu kan du förvandla honom till en eskorterande sökande, åtminstone i utseende, genom att använda hans referenser för att imitera honom online. Föreställ dig skador som kan orsaka en politiker som felaktigt anklagats och tvingas avgå.
   • Saker som gör det lättare att hacka andra människor . Du kan sedan skicka e-post till Person B med infekterade bilagor och låtsas att du känner honom. Du har läst tillräckligt med e-postmeddelanden så att du kan imitera Mark Buffalo till den punkt där du verkar precis som han. Du skapar e-postmeddelandet på ett sätt som gör att Person B intet ont anar vad som verkligen händer, och nu kan du göra samma sak för Person B , eller värre.

Och det är bara en liten samling idéer. Det finns många olika användningsområden för någon annans referenser. Salta och hash dina lösenord, använd kollisionsresistenta hashalgoritmer som bcrypt och scrypt, och förhindra SQL-injektionsattacker. Snälla gör mig inte till en eskorterande sökande! Spara Mark Buffalo!

(Jag är medveten om att vissa webbplatser kan blockera ditt försök att få åtkomst till deras tjänster när du använder en annan IP, men det finns många sätt att kringgå det, och inte alla webbplatser gör det) .

Grattis för din potentiella grupptalan om du blir hackad.

En vanlig typ av intrång är skrivskyddad åtkomst till användartabellen. Detta beror på att den här tabellen används i koden som gör inloggningen som du inte behöver vara autentiserad för. Att få lösenorden skulle då göra det möjligt att läsa åtkomst till all data, men även om angriparen redan har full läsåtkomst på DB kan han fortfarande få skrivåtkomst via lösenorden, kunna logga in på kontot och enkelt ändra vissa data.

En mycket enkel anledning för saltning och hashning av användarnas lösenord är detta:

En användares lösenord är hans / henne hemlighet

Ingen annan borde veta det. Inte du, inte din kollega, inte DBA. Ingen . Enkelt så ...

En del av saltning är att göra det svårare att analysera och stjäla lösenordet och använda deras användarnamn / e-post och lösenordskombination på andra webbplatser.

Det är ganska vanligt att användare återanvänder 1 eller 2 lösenord på flera webbplatser. Att ändra din algoritm till en som salter och tar lite mer tid (t.ex. bcrypt, scrypt och liknande) rekommenderas starkt och ganska enkelt att implementera på de flesta språk.

Syftet med ett salt är tvåfaldigt: för det första introducerar det ett unikt (-ish) element till varje lösenord, så att om två användare råkar använda samma lösenord kommer lösenordets hashade text att variera. Om användare A ser att hennes lösenordshash är "QWERTYU123", och att User B: s lösenordshash också är "QUERTYU123", kan användare A dra slutsatsen att hon har samma lösenord som Användare B.

För det andra, det introducerar en betydande hastighetsstopp för alla som har tillgång till databasen som vill tvinga lösenorden med en ordboksattack. Utan salt kan angriparen helt enkelt hash "TRUSTNO1" för att få hash "QUERTYU123" och skanna sedan lösenordskolumnen för att se om den texten visas. Med ett salt måste angriparen tvätta om "TRUSTNO1" för varje rad i databasen för att testa för en matchning och lägga betydligt till mängden CPU som krävs för att kontrollera varje ordbokspost.

om de har tillgång till databasen behöver de inte lösenordet eftersom de bara kan stjäla data direkt från databasen

Lösenordet är det värdefulla. Det beror på att många, många människor använder samma lösenord. Så lösenordet till din dukklubb kan vara detsamma som de använder för sin nätbank.

Jag ser efter ett system som innehåller mycket "lågkvalitativ" information, inget ekonomiskt annat än namn / adress / e-post etc.

Dessa är också värdefulla. Jag har tappat koll på antalet e-postmeddelanden som jag nyligen har fått från "eBay" eller "Apple" och hävdar att mitt konto har varit begränsat såvida jag inte "verifierar" mina uppgifter. De är vanligtvis uppenbart falska eftersom de inte nämner mitt riktiga namn. Men om du lagrar ett namn och en e-postadress är det mycket lättare att göra en realistisk utskick och be om mer personlig information. Till exempel:

Kära herr Smith på 42 Station Street, Gotham City.

Vi insåg precis att vår klubb överdebiterade dig detta räkenskapsår och vill återbetala 10 USD. Svara med dina bankuppgifter så att vi kan sätta in pengarna på ditt konto.

Så, avvisa inte e-post och namn.

Längst ner linjen är dock att hasning och saltning av din befintliga databas bara borde ta ungefär en timmes kodning och testning. Då kan du göra en "batchkonvertering" av lösenord för vanlig text till de hashade och saltade.

Kryptering av användarinformation som namn, e-post, etc. och lagring i databas snarare än att lagra den i ett råformat ger en extra säkerhet för din applikation. För det andra kan personer som har åtkomst till din databas inte heller läsa data enkelt. Alla typer av information som du lagrar och som kommer från alla kunder har sekretess. Eftersom det är deras data och det är ett utvecklaransvar att lagra det på ett sätt som gör det svårt för hacket att göra mening, vare sig det är låggradig information eller topphemlig information. Dekryptering och kryptering av data bör också göras på serversidan eftersom servrar i allmänhet hålls bakom brandväggen. Så det blir säkrare ur säkerhetsperspektiv.

Jag kan se vad du menar om angriparen också kunde komma åt databasen. Saken är dock att ett väldesignat säkerhetssystem bara låter databasen lagra information som både användaren och servern har krypterat individuellt.

Generellt är lösenordet det första fältet med dolda värden där du kan låta dina användare ge som kan hashas för att dekryptera deras data för att ge ett andra säkerhetsskikt om databasens krypteringsnycklar någonsin är äventyras. På det sättet, även när det finns ett brott, är användarens data fortfarande säker.

I detta sammanhang är hashpunkten baserad på tanken på en envägs- eller dörrfunktion: en funktion som är lätt att beräkna men svår att reversera. När användaren genererar ett lösenord beräknar systemet sin hash och lagrar det värdet i databasen. När användaren skickar in ett lösenord för att komma in i systemet beräknar den sin hash och jämför det med värdet i databasen. Om de är desamma, bra; om inte, så var lösenordet fel och användaren bör hindras från att komma åt systemet. För att detta ska fungera behöver hash två egenskaper: (1) Olika originalvärden hash till olika värden; (2) Det är beräkningsmässigt svårt att gå från hashen till det ursprungliga värdet.

Så varför bry sig sig om hash alls? Om någon hackar in i din databas (inte bara genom datorhackning utan genom socialtekniska attacker, lämnar en utskrift på bussen, agerar av en missnöjd anställd, etc.), allt de får är en serie hashvärden. Det är svårt att återställa det ursprungliga värdet från ett hashvärde, så det här är inte särskilt användbart för en hackare. Om lösenorden för klartext lagras i databasen vinner hackaren om databasen äventyras. han har direkt tillgång till alla konton och lösenord, och han kan i princip göra vad han vill. Denna inställning betyder också att du inte har tillgång till människors lösenord. Det här är bra; även om du litar på dig själv litar du antagligen inte på --- och borde inte behöva lita på --- din motsvarighet i din bank, din föregångare eller efterträdare på jobbet etc. Du borde inte behöva vara beroende av storheten eller infall av en administratör för att säkerställa att din information är säker.

När det gäller salter nämnde jag ovan att hash måste ha två icke-privata egenskaper för att vara effektiva. (Det finns några ytterligare som jag hoppar över för nu.) Funktioner som har dessa egenskaper är inte enkla att hitta, och det vore oklokt att förlita sig på den specifika administratören av en webbplats för att komma med en anständig. Istället finns det allmänt tillgängliga hashes som de flesta använder. Poängen med ett salt är att se till att olika platser effektivt använder olika hash: istället för att bara hasha 'lösenord', istället 'salt' + 'lösenord' för olika värden av 'salt'. Det betyder att om någon använder samma lösenord på två webbplatser, har de faktiskt olika hash på de två systemen, så att en hackare inte kan använda det ena för att bryta det andra. Utan saltet kunde hackare bara tvinga alla hash för lösenord av rimlig längd. Jag nämnde ovan att hash måste vara svårt att vända. Om du har en tabell över alla möjliga hash för lösenord upp till, t ex 10 bokstäver (eller till och med bara de vanligaste lösenorden), är det trivialt att vända hashen; slå bara upp det i tabellen.

Förutom de andra svaren, kom ihåg att det finns många grader av sårbarheter mellan helt säker och fullständig åtkomst till en databas. En sårbarhet kan bara avslöja vissa lösenord, eller bara de första tecknen i den, eller vara svår att associera med en viss användare, etc. Hashing och saltning kan hindra ett mindre brott från att bli ett stort.

Även inkräktare vill begränsa sin egen exponering. Ju längre de använder en sårbarhet eller bakdörr för att komma in i ett system, desto mer sannolikt kommer de att bli upptäckta och utestängda innan de uppnår sitt mål. Om du lämnar dina lösenord oskadade och osaltade, har du bara gett dem ett väldigt enkelt sätt att komma tillbaka in i systemet som alla användare, som är extremt svårt att upptäcka och mildra.

Jag tror att det bästa sättet att uttrycka detta är: året är 2015, den mest privata och personliga informationen som dina användare överlåter till dig är deras lösenord och användar-id. Skydda det, inte med ditt liv utan med din okunnighet, inte med din förmåga utan din oförmåga.

Om du inte vet deras lösenord och inte har något sätt att återställa sitt lösenord, kan ingen stjäla det från dig eller tvinga dig att avslöja den.

Alla behöriga digitala tjuvar, med valet mellan tusen namn och adresser och tusen e-postadresser / användarnamn och lösenord, kommer att ta det senare varje gång. >

Jag förstår kostnad och tid, men om det görs rätt, från början tar det verkligen ingen extra tid alls, och att byta till en säkrare metod är inte det tidskrävande.