Salt (kryptografi)

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 15 oktober 2019; kontroller kräver 17 redigeringar .

Salt (även en inmatningsmodifierare för hashfunktion ) är en datasträng som skickas till hashfunktionen tillsammans med indatamatrisen ( preimage ) för att beräkna hashen ( bild ).

Används för att göra det svårare att bestämma förbilden för en hashfunktion genom att iterera genom en ordbok med möjliga indatavärden (förbilder), inklusive attacker med regnbågstabeller . Gör att du kan dölja det faktum att du använder samma prototyper när du använder olika salter för dem. Det finns statiskt salt (samma för alla ingångsvärden) och dynamiskt salt (genereras för varje ingångsvärde individuellt).

Användningsexempel

Låt lösenorden hashas med hjälp av MD5- algoritmen och lagras som hashvärden i databasen . I händelse av en databasstöld kan de ursprungliga lösenorden återställas med hjälp av förberedda regnbågstabeller , eftersom användare ofta använder opålitliga lösenord som lätt kan väljas från ordböcker [1] . Om lösenordet är "saltat", det vill säga när du beräknar hashvärden, lägg till indata en sträng med flera slumpmässiga tecken som kommer att vara saltvärdet, då kommer de resulterande värdena inte att matcha vanliga hashvärdesordböcker. Genom att känna till saltet kan du skapa nya ordböcker att iterera över, så saltets värde måste hållas hemligt. För salt gäller samma rekommendationer för komplexitet som för lösenordskomplexitet, dvs saltvärdet bör ha bra entropi och längd [2] .

Ett exempel på att skapa en hash med ett statiskt salt i PHP baserat på principen om sammanlänkning (anslutning) med indata:

$password1 = '12345' ; $password2 = '67890' ; $salt = 'sflpr9fhi2' ; // Salt $password1_saltedHash = md5 ( $password1 . $salt ); // Sammanfoga inmatningssträngen med saltet och skicka den genom hashfunktionen md5() $password2_saltedHash = md5 ( $password2 . $salt );

I det här exemplet är saltet en deterministisk sträng, vilket betyder att saltets värde är konstant över alla ingångar.

Dynamiskt salt

Det finns dynamiska saltbildningsscheman, där saltvärden genereras för varje ingångsvärde individuellt, vilket gör det svårt att kompilera brute-force-ordböcker, och även döljer faktumet att lagra samma lösenord som används av olika användare. Dessutom ökar effektiviteten hos schemat om icke-trivial blandning enligt någon algoritm används. Till exempel kan salt inte bara läggas till i slutet av lösenordet, utan "blandas in" med vissa intervall av lösenordet. Dessutom kan hashen beräknas cykliskt, blanda saltet i delar med vissa förändringar [3] , beroende på hashing iterationsnumret .

En av de välkända standarderna PBKDF2 beskriver blandning av salt i flera iterationer.

Ett exempel på lagring av samma lösenord från olika användare, med förbehåll för ett personligt genererat (dynamiskt) salt
Användarnamn Lösenord md5 (lösenord) salt- lösenord+salt md5 (lösenord+salt)
användare1 qwerty123 3fc0a7acf087f549ac2b266baf94b8b1 5h8Uh32Hr qwerty1235hr8Uh32Hr 1dfa98fc519fc0022e86014445d8b158
användare2 qwerty123 3fc0a7acf087f549ac2b266baf94b8b1 Ju5yFy35Jk qwerty123Ju5yFy35Jk 269777fd3b1c37ef1cfc1e238213324f

Tabellen ovan visar att samma användarlösenord med olika dynamiska salter så småningom kommer att ge olika hashvärden.

Problem med salt och lösenordsstyrka

Med obehörig åtkomst till auktoriseringssystemets databas kan en angripare få den information som krävs för att skicka auktorisering på uppdrag av användare från denna databas. Om lösenord lagras i sin ursprungliga (tydliga) form kan en angripare använda dem för att komma åt andra resurser, eftersom användare ofta använder samma lösenord för olika webbtjänster [4] . Genom att använda ett dynamiskt salt kan du undvika att kompromissa med användarkonton på flera webbtjänster samtidigt.

Med ett dåligt genomtänkt system för att använda salt går dess fördelar förlorade:

Liten saltlängd och låg entropi

Om saltet är kort blir det lätt för en angripare att skapa en regnbågstabell som består av alla möjliga salter av en viss längd, läggs till varje möjligt lösenord. Att använda ett salt med låg entropi ökar också chansen att framgångsrikt hitta saltet i ordboken, så saltets värde bör helst genereras med en RNG [5] . Att använda ett långt salt med bra entropi säkerställer att regnbågstabellen för databasen blir för stor och kräver betydande angriparresurser för att generera och lagra [6] .

Återanvändning av salt för olika prototyper

Även om användning av ett statiskt salt för samma förbilder kommer att göra vissa befintliga regnbågstabeller värdelösa, bör det noteras att om saltet statiskt skrivs in i källkoden för en populär produkt, så kan det förr eller senare extraheras, varefter en ny regnbågsbord kan skapas från detta salt. Om saltet genereras dynamiskt för varje förbild individuellt, med hjälp av några unika parametrar för varje användare, ökar systemets stabilitet.

Att använda ett fast salt innebär också att varje användare som anger samma lösenord kommer att ha samma hash. Detta gör det lättare att attackera flera användare genom att bara knäcka en av de upprepade hasharna [7] .

Fördelar med att använda salt i auktoriseringssystem

För att förstå skillnaden mellan att knäcka ett enda lösenord och att skriva dem, överväg en lösenordsfil som innehåller hundratals användarnamn och hashade lösenord. Utan ett salt kan en angripare beräkna en hash av något värde (till exempel från en ordbok) och sedan kontrollera om den hashen förekommer någonstans i filen. Sannolikheten för en matchning, det vill säga att knäcka ett av lösenorden, ökar självklart med antalet lösenord i filen. Om ett salt används, och dessutom är det dynamiskt, det vill säga det har åtminstone flera möjliga värden för en hash, måste angriparen beräkna hashen för varje möjligt par salt och lösenordet som söks, vilket dramatiskt ökar sökningens komplexitet.

Saltet låter dig också motverka användningen av hashtabeller för att knäcka lösenord. När det gäller användarlösenord är en hash-tabell en samling förberäknade hash för ofta använda lösenord. För en osaltad lösenordsfil kan en angripare gå igenom varje post och hitta motsvarande hashade lösenord i hashtabellen. Eftersom uppslagningen är mycket snabbare än hashberäkningen, kommer detta att avsevärt påskynda processen att knäcka lösenord. Men om lösenordsfilen är bildad med ett salt, måste hashtabellen innehålla förhaschade värden med saltet. Om saltet är tillräckligt långt och har en hög entropi (det är slumpmässigt), minskar sannolikheten för att det går sönder drastiskt. Osaltade lösenord som väljs av människor är i allmänhet sårbara för ordboksattacker eftersom de vanligtvis väljs för att vara korta och lätta att komma ihåg. Även en liten ordbok (eller dess hashade motsvarighet, en hashtabell) är till stor hjälp för att knäcka de vanligaste lösenorden.

Ur teknisk synvinkel skyddar salt mot hashtabeller och regnbågstabeller eftersom det väsentligen förlänger längden och potentiellt komplexiteten hos lösenordet . Om det inte finns några lösenord i regnbågstabeller som matchar längden (t.ex. 8 byte lösenord och 12 byte salt, vilket i huvudsak är ett 20 byte lösenord) och komplexiteten (komplext salt med hög entropi ökar komplexiteten hos enkla starka alfanumeriska lösenord) för de saltade lösenord, kommer lösenordet inte att hittas.

Det moderna skugglösenordssystemet , där lösenordshashar och annan säkerhetsdata lagras i en icke-offentlig fil, löser delvis problemet med obehörig åtkomst till hashfilen. Samtidigt förblir de relevanta i installationer med flera servrar som använder centraliserade lösenordshanteringssystem för att överföra lösenord eller lösenordshaschar till flera system [8] .

Salt gör också ordboksattacker och brute-force-attacker för att knäcka ett stort antal lösenord extremt långsamma (men inte i fallet med att knäcka bara ett lösenord). Utan ett salt tvingas en angripare som knäcker en stor uppsättning lösenord att jämföra varje gång med alla kandidater. Med tanke på att saltet kan vara dynamiskt, bör varje saltalternativ försöka tillämpas på varje lösenord från listan.

En annan fördel med ett salt är att två användare kan välja samma sträng som sitt lösenord, eller att samma användare kan använda samma lösenord på två datorer. Utan saltet kommer detta lösenord att lagras som samma hashsträng i lösenordsfilen. Detta skulle avslöja det faktum att de två kontona har samma lösenord, vilket gör att alla som känner till ett av kontots lösenord kan komma åt det andra kontot. När salt blandas in, även om två konton använder samma lösenord, kan ingen upptäcka det genom att bara titta på hash-värdena.

Salt på UNIX-system

De flesta UNIX -system använder systembiblioteket crypt(3) som en enkelriktad funktion . Till en början använde det här biblioteket en hash-funktion baserad på DES-algoritmen . I det här fallet var lösenordet begränsat till 8 tecken (7 bitar per tecken, det vill säga 56 bitar), och ett 12-bitars salt användes [9] .

1994 skapade Poul-Henning Kamp en ny lösenordshasningsalgoritm baserad på MD5 som tillät lösenord av vilken längd som helst och använde tusen iterationer av MD5 [10] [11] . Resultatet av funktionen var en sträng som innehöll etiketten för hashalgoritmen (version), salt och hash.

Vid den tiden var förseningen för att beräkna en sådan hash tillräcklig för att effektivt motstå brute-force lösenordsgissning. Men i takt med att datorkraften har ökat har tiden för att hitta MD5 minskat dramatiskt. Detta har lett till uppkomsten av beräkningsmässigt mer komplexa algoritmer i krypten och kontroll över antalet iterationer [12] .

Biblioteket stöder nu flera hashfunktioner baserade på algoritmer: MD5 , SHA-256 , SHA-512 , Blowfish (i vissa Linux- distributioner , OpenBSD och vissa andra UNIX-liknande system) [13] . Resultatet av funktionen är en sträng som innehåller etiketten för hashalgoritmen, salt, hash och andra data (till exempel antalet omgångar av hashfunktionen).

2012 uppmanade Poul-Henning Kamp att helt överge md5crypt-algoritmen som han skapade, eftersom den inte ger en påtaglig ökning av hashberäkningstiden under moderna förhållanden, och därför inte skyddar mot uttömmande uppräkning [14] .

Se även

Anteckningar

  1. En studie om lösenord . Security-Corp.org - en resurs tillägnad informationssäkerhetsfrågor. Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  2. Vilket lösenord kommer att skydda mot hacking eller entropi i sekretessens tjänst . samag.ru. Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  3. "Saltad" lösenordshasning: gör det rätt . Internet technologies.ru. Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  4. Club.CNews.ru: 52 % av användarna använder samma lösenord på olika webbplatser . Club.CNews.ru. Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  5. Slumptalsgeneratorer i kryptografi . studopedia.net. Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  6. Hastighet för brute force av lösenord på CPU och GPU . bozza.ru Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  7. Miljontals Microsoft-användare använder upprepade lösenord . i2HÅRT. Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  8. Distribuerad lagring av lösenordshashar - "Hacker" . Hämtad 14 december 2019. Arkiverad från originalet 14 december 2019.
  9. OpenNet-projekt: MAN crypt(3) biblioteksanrop (FreeBSD och Linux) . Hämtad 24 juni 2012. Arkiverad från originalet 26 juni 2012.
  10. FreeBSD CVS-logg för src/lib/libcrypt/crypt.c . Hämtad 9 juli 2012. Arkiverad från originalet 12 juli 2013.
  11. Niels Provos, David Mazières. Ett framtida anpassningsbart lösenordsschema . Paper - 1999 USENIX årliga tekniska konferens, 6-11 juni 1999, Monterey, Kalifornien, USA (juni 1999). Hämtad 9 juli 2012. Arkiverad från originalet 9 augusti 2012.
  12. Unix-krypta med SHA-256/512 . Hämtad 24 juni 2012. Arkiverad från originalet 16 juli 2013.
  13. crypt(3) - Linux manualsida . Hämtad 24 juni 2012. Arkiverad från originalet 2 maj 2012.
  14. Md5crypt Password scrambler anses inte längre vara säker av författaren (nedlänk) . Hämtad 9 juli 2012. Arkiverad från originalet 17 mars 2018. 

Litteratur