Jag är nybörjare till kryptografi och vill förstå i mycket enkla termer vad en kryptografisk ” salt ” är när jag kan behöva använda det och varför jag ska eller inte ska använda det.
Kan jag få en mycket enkel och tydlig (nybörjarnivå) förklaring?
Om du känner till några referenser om ämnet, skulle de också vara användbara.
Svar
Anledningen till att salter används är att människor tenderar att välja samma lösenord, och inte alls slumpmässigt. Många använda lösenord där ute är korta riktiga ord, för att göra det lätt att komma ihåg, men detta också möjliggör en attack.
Som du kanske vet sparas lösenord i allmänhet inte i klartext utan snarare hashade. Om du är osäker på syftet med en hash-funktion, läs igenom det först.
Vad angriparna nu kan göra är att helt enkelt skapa en lista med vanliga lösenord och deras motsvarande hash. om hasharna som en webbplats har lagrat med tabellen kommer, om vanliga lösenord används, att avslöja lösenorden för angriparen.
A salt läggs helt enkelt till gör ett lösenord hash-utdata unikt även för användare antar vanliga lösenord . Syftet är att göra förberäkningsbaserade attacker ohjälpsamma. Om ditt lösenord lagras med ett unikt salt, hjälper inte någon förberäknad lösenord-hash-tabell inriktad på osaltad lösenordshash eller inriktning på ett konto med ett annat salt att spricka ditt kontos lösenord. id = ”daa1c4f2d4”>
) förväntas vara globalt unikt . Således kan salter användas för att göra -beräkning attackerar helt ineffektivt.
Det enklaste sättet att kombinera saltet och lösenordet är att helt enkelt sammanfoga dem, dvs det lagrade hashvärdet är Hash(salt||password). lösenord password1 blir nu magiskt, t.ex. 6$dK,3gCA%Jpassword1 vilket sannolikt inte kommer att hittas i en lösenordssprickares tabell.
Saltet kan lagras helt i klar i databasen, bredvid hashvärdet. När angriparen har databasen och vill hitta lösenorden måste han generera den förberäknade tabellen för varje salt individuellt, en kostsam operation.
Ett annat sätt att hjälpa till att försvara sig mot offline lösenordssprickning är att utföra lösenordsträckning, dvs. gör en lösenordshash långsammare att beräkna för alla personer, inklusive inloggningstjänsten och lösenordshackare. En metod som används för att sträcka lösenord uppnås genom att iterera hash-funktionen många gånger, dvs. lagra Hash(Hash(Hash(Hash…(Hash(salt||password)))…).
En annan vanlig idé relaterad till saltning kallas en peppar . Det vill säga ett annat slumpmässigt värde sammankopplat med lösenordet, så att det lagrade värdet är Hash(pepper||salt||password). Peppar lagras sedan alls inte . Både inloggningsservern och lösenordssmälaren måste tvinga det okända pepparvärdet, vilket gör att lösenordshash-jämförelserna saktas för båda parter. tävling hölls för att söka efter en bättre lösenordssträckningsalgoritm. Vinnaren var Argon2 algoritmen. Programmerare rekommenderas att använda Argon2 istället för att implementera sin egen algoritm .
Kommentarer
- Så egentligen, när du bara har ett eller två lösenord lagrade i databasen, är användningen av salt effektivt värdelös? Vad jag förstår är att detta bara är användbart när antalet lösenord som lagras i databasen inte är litet.
- @AbhinavChoudhury: Nej, det försvarar mot regnbågstabeller – dvs förberäknade tabeller för en specifik hash. Ett exempel: Ta ett lösenord ” lösenord1 ”. Om du inte ’ t salt, lagrar du ’ HASH (” lösenord1 ”) i din databas. Nu, om en angripare får dina poster och har förberäknat HASH (*) för alla lösenord med 9 tecken, kan han återställa lösenordet. Om du istället saltade lösenordet, HASH (’ somesaltforyou ’ || ’ lösenord1 ’) kommer INTE att finnas i angriparens regnbågstabell (eftersom den ’ innehåller mer än 9 tecken).
- ” Saltet kan lagras helt i det klara i databasen, bredvid det hashade värdet ” – – den här delen har aldrig riktigt gett mig mening; Jag undrade om du kunde utöka det
- Saltets poäng är att se till att haschen inte finns i en förberedd tabell. Det måste lagras för att verifiera lösenordet (annars ’ sa ” peppar ”). Saltet ska inte vara ” hemligt ”, bara för att göra lösenordet unikt. Det betyder naturligtvis att varje lagrat lösenord måste ha sitt eget, unika (och slumpmässiga) salt.
Svar
Kan du hjälpa mig att förstå vad ett kryptografiskt ”salt” är?
I samband med lösenord skapande, ett ”salt” är data (slumpmässigt eller på annat sätt) som läggs till i en hashfunktion för att göra lösenordets hashade utdata svårare att knäcka.
När kan jag behöva använda den?
Alltid.
Varför ska eller ska jag inte använda den?
Du bör alltid använda ett saltvärde med dina hashfunktioner, av skäl som förklaras nedan.
Det är i allmänhet sant att människor väljer svaga lösenord, och det är verkligen sant att det finns gigabyte med offentligt tillgängliga regnbågstabeller fyllda av hashade värden som representerar dem. Så när någon skapar ett konto på din tjänst och väljer ett lösenord för att säkra sin identitet kan du vanligtvis satsa att lösenordet de väljer blir 1) vanligt, 2) osäkert och 3) tillgängligt för korsreferens i uppslagstabeller.
Till exempel är lösenordet Nowayin1 när hashad via MD5 är 6f367d65bc74b88e21fb9959487ffa3a och är uppenbarligen inte ett bra val. Även om det kan se okej ut (och det gör inte det), det faktum att lösenordets MD5-hash visas i öppna databaser gör det värdelöst.
Men det är bara 128-bitars MD5. Vad sägs om något starkare, som SHA1 (160-bit) eller till och med Whirlpool (512-bit)?
Samma problem.
Till exempel P @ $$ word med SHA1 är 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 och
1qazXSW @ hashade med Whirlpool säga 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .
Rotproblemet med alla dessa lösenord, och miljarder fler som dem, är det faktum att deras vanliga haschar har blivit allmänt känt.
Ett lösenord salt ändrar det.
Om ett slumpmässigt värde (saltet) adderades till användarens valda lösenord, då skulle SHA1-hash 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 inte längre avslöja @ som användarens lösenord, eftersom hashvärdet i regnbågstabellen inte längre matchar det.
Och det tar inte mycket. Ett litet 16-bitars slumpmässigt värde, till exempel, skulle ge 65 536 varianter av varje hash-värde i uppslagstabellerna. Så en databas med 15 miljarder poster skulle nu behöva över 983 miljarder haschar i den för att redogöra för saltet.
Så, det är poängen att salta dina haschar, för att förhindra uppslag och regnbågsbord. Men don ”t hänga din hatt på en saltad hash, eftersom hackare inte slösar mycket tid med regnbågsbord för att räkna ut dina lösenord.
De kommer att använda en fem-server-25-GPU-kluster-system som kör Hashcat som kan bränna genom 350 miljarder gissningar per sekund och spricka hash för varje tänkbart åtta tecken lösenord som innehåller stora och små bokstäver, siffror och specialtecken, på knappt sex timmar. (Och det var tillbaka 2012.)
Tekniker som tangentsträckning som gör att hashkörningar går långsammare kan användas för att kompensera hastigheten på sådan hårdvara, vilket gör ordlista och brutala kraftattacker för långsamma för att vara värda , men hårdvaran blir bara snabbare och snabbare.
UPPDATERING 2018:
Aktuella bästa metoder inkluderar säkert hashning av dina lösenord med Argon2i (föredras framför kryptering), en minneshård funktion som är mycket motståndskraftigt mot FPGA: er, multiplecore GPU: er och dedikerade ASIC-moduler som används för att enkelt knäcka icke-sträckta lösenfraser. I PHP7 -implementeringen av Argon2 hanteras saltet internt för dig.
Svar
Jag ska försöka svara på en del av din fråga som hittills har försummats:
när jag kan behöva använda den och varför jag ska / inte ska använda den.
Det korta svaret är att du som amatör inte ska använda kryptografi på en nivå som kräver att man hanterar salter direkt.
Till exempel bcrypt algoritm för lösenords hashing använder salter internt. Men det avslöjar inte det faktum för utvecklare som använder det – du skickar helt enkelt lösenordet till bcrypt (och valfritt en parameter som anger ”nivån CPU-ansträngning ”som behövs för att generera hash) och den returnerar hash. När du behöver verifiera om ett lösenord är korrekt skickar du bcrypt både lösenordet och den tidigare genererade hash. Det kommer att ange om lösenordet var det som användes för att generera hash.
Gör inte de råd som ges här och försök att hash dina egna lösenord med salt. Det är en detaljnivå på implementeringen, och om du befinner dig på en nivå där det behövs sådana saker, arbetar du på en alltför låg abstraktionsnivå. Kryptografi är väldigt svårt att göra korrekt, och Internet är absolut full av välmenande utvecklare ”helt osäkra hemodlade system för lösenordshashing.
Svar
Citat “ Exam Ref 70-486 Developing ASP.NET MVC 4 Web Applications (MCSD): Developing ASP.NET MVC 4 Web Applications ” av William Penberthy, Pearson Education, 15 september 2013:
Saltning är en process som stärker filkryptering och haschar, vilket gör dem svårare att bryta. en slumpmässig sträng till början eller slutet av inmatningstexten före hashing eller kryptering av värdet. När du till exempel försöker bryta en lista med lösenord måste hackare ta hänsyn till saltet och möjlig lösenordsinformation innan de kan bryta i applikationen. Om varje värde som saltas tilldelas ett annat saltvärde kan möjligheten att skapa en tabell över potentiella lösenordsvärden för en pa ssword-cracking-programmet blir omständligt.
Svar
Ett salt är ett slumpmässigt nummer som behövs för att få åtkomst till krypterad data, tillsammans med lösenordet.
Om en angripare inte känner till lösenordet och försöker gissa det med en brute-force attack, då varje lösenord han försöker måste prövas med varje saltvärde.
Så för ett enbitarsalt (0 eller 1) gör det krypteringen dubbelt så svår att bryta på det här sättet. Ett två-bitars salt gör det fyra gånger så hårt, ett tre-bitars salt åtta gånger så hårt, etc. Du kan föreställa dig hur svårt det är att knäcka lösenord med kryptering som använder ett 32-bitars salt!
Kommentarer
- Nej Salt antas vanligtvis vara känt för angriparen. I det här fallet, förbi något lågt tröskelvärde, förbättrar inte salt säkerheten.
- ” Salt antas vanligtvis vara känt för angriparen ” – > Vem antar detta?
- @Mike: Vem? Någon säger ” Du bör alltid anta att angriparen känner till saltet. ”. Människor på en annan sida säger ” Salter är offentliga ” säger senare ” salterna är kända, för att ’ är industristandard användning av ordet salt. ” En annan säger ” saltet är allmänt känt eller bör åtminstone behandlas som offentligt kunskap. ”.