Salt (også en indgangsmodifikator for hashfunktion ) er en datastreng , der sendes til hashfunktionen sammen med inputdataarrayet ( preimage ) for at beregne hashen ( billede ).
Bruges til at gøre det sværere at bestemme preimage af en hash-funktion ved at iterere gennem en ordbog over mulige inputværdier (preimages), inklusive angreb ved hjælp af regnbuetabeller . Giver dig mulighed for at skjule det faktum, at du bruger de samme prototyper, når du bruger forskellige salte til dem. Der er statisk salt (det samme for alle inputværdier) og dynamisk salt (genereret for hver inputværdi individuelt).
Lad adgangskoderne blive hash ved hjælp af MD5- algoritmen og gemt som hash-værdier i databasen . I tilfælde af tyveri af databasen kan de originale adgangskoder gendannes ved hjælp af præ-forberedte regnbuetabeller , da brugere ofte bruger upålidelige adgangskoder, der nemt kan vælges fra ordbøger [1] . Hvis adgangskoden er "saltet", det vil sige, når du beregner hashværdier, føj til inputdataene en streng med flere tilfældige tegn, der vil være saltværdien, så vil de resulterende værdier ikke matche almindelige hashværdiordbøger. At kende saltet giver dig mulighed for at generere nye ordbøger til at iterere over, så værdien af saltet skal holdes hemmelig. For salt gælder de samme anbefalinger for kompleksitet som for kodeordskompleksitet, dvs. saltværdien skal have god entropi og længde [2] .
Et eksempel på oprettelse af en hash ved hjælp af et statisk salt i PHP baseret på princippet om sammenkædning (forbindelse) med inputdata:
$password1 = '12345' ; $password2 = '67890' ; $salt = 'sflpr9fhi2' ; // Salt $password1_saltedHash = md5 ( $password1 . $salt ); // Sammenkæd inputstrengen med saltet og giv den gennem hashfunktionen md5() $password2_saltedHash = md5 ( $password2 . $salt );I dette eksempel er saltet en deterministisk streng, hvilket betyder, at værdien af saltet er konstant på tværs af alle input.
Der er dynamiske saltdannelsesskemaer, hvor saltværdier genereres for hver inputværdi individuelt, hvilket gør det vanskeligt at kompilere brute-force-ordbøger, og også skjuler det faktum at gemme de samme adgangskoder, der bruges af forskellige brugere. Effektiviteten af ordningen øges også, hvis ikke-triviel blanding i henhold til en eller anden algoritme anvendes. For eksempel kan salt ikke kun tilføjes i slutningen af adgangskoden, men "blandes ind" med visse intervaller af adgangskoden. Derudover kan hashen beregnes cyklisk, idet saltet blandes i dele med nogle ændringer [3] , afhængigt af hashing- iterationstallet .
En af de velkendte standarder PBKDF2 beskriver blanding af salt i flere iterationer.
| Brugernavn | adgangskode | md5 (adgangskode) | salt | adgangskode+salt | md5 (adgangskode+salt) |
|---|---|---|---|---|---|
| bruger 1 | qwerty123 | 3fc0a7acf087f549ac2b266baf94b8b1 | 5t8Uh32T | qwerty1235hr8Uh32T | 1dfa98fc519fc0022e86014445d8b158 |
| bruger2 | qwerty123 | 3fc0a7acf087f549ac2b266baf94b8b1 | Ju5yFy35Jk | qwerty123Ju5yFy35Jk | 269777fd3b1c37ef1cfc1e238213324f |
Tabellen ovenfor viser, at de samme brugeradgangskoder med forskellige dynamiske salte til sidst vil give forskellige hash-værdier.
Med uautoriseret adgang til databasen i autorisationssystemet kan en hacker få de nødvendige oplysninger til at videregive godkendelse på vegne af brugere fra denne database. Hvis adgangskoder gemmes i deres originale (klare) form, kan en angriber bruge dem til at få adgang til andre ressourcer, da brugere ofte bruger de samme adgangskoder til forskellige webtjenester [4] . Ved at bruge et dynamisk salt kan du undgå at kompromittere brugerkonti på flere webtjenester på én gang.
Med et dårligt gennemtænkt system til brug af salt går dets fordele tabt:
Lille saltlængde og lav entropi
Hvis saltet er kort, vil det være nemt for en angriber at lave et regnbuebord bestående af alle mulige salte af en vis længde, tilføjet til hver mulig adgangskode. Brug af et salt med lav entropi vil også øge chancen for at finde saltet i ordbogen, så værdien af saltet bør ideelt set genereres ved hjælp af en RNG [5] . Brug af et langt salt med god entropi sikrer, at regnbuetabellen til databasen bliver for stor og kræver betydelige angriberressourcer at generere og lagre [6] .
Genbrug af salt til forskellige prototyper
Selvom brug af et statisk salt til de samme forbilleder vil gøre nogle eksisterende regnbuetabeller ubrugelige, skal det bemærkes, at hvis saltet statisk skrives ind i kildekoden til et populært produkt, så kan det før eller siden udtrækkes, hvorefter en ny regnbuebord kan laves ud fra dette salt. Hvis saltet genereres dynamisk for hvert præbillede individuelt ved at bruge nogle unikke parametre for hver bruger, så øges systemets stabilitet.
Brug af et fast salt betyder også, at hver bruger, der indtaster den samme adgangskode, vil have den samme hash. Dette gør det nemmere at angribe flere brugere ved kun at knække én af de gentagne hashs [7] .
For at forstå forskellen mellem at knække en enkelt adgangskode og skrive den, skal du overveje en adgangskodefil, der indeholder hundredvis af brugernavne og hash-kodede kodeord. Uden et salt kan en angriber beregne en hash af en eller anden værdi (for eksempel fra en ordbog) og derefter kontrollere, om denne hash forekommer nogen steder i filen. Sandsynligheden for et match, det vil sige at knække et af kodeordene, stiger naturligvis med antallet af kodeord i filen. Hvis der bruges et salt, og det desuden er dynamisk, det vil sige, at det har mindst flere mulige værdier for én hash, så skal angriberen beregne hashen for hvert muligt par salt og den adgangskode, der søges, hvilket dramatisk øger kompleksiteten af søgningen.
Saltet giver dig også mulighed for at imødegå brugen af hash-tabeller til at knække adgangskoder. I tilfælde af brugeradgangskoder er en hash-tabel en samling af forudberegnet hashes til ofte brugte adgangskoder. For en usaltet adgangskodefil kunne en angriber gå gennem hver indgang og finde den tilsvarende hash-kodeord i hash-tabellen. Da opslag er meget hurtigere end hash-beregningen, vil dette i høj grad fremskynde processen med at knække adgangskoder. Men hvis adgangskodefilen er dannet med et salt, skal hash-tabellen indeholde præ-hashed værdier med saltet. Hvis saltet er langt nok og har en høj entropi (det er tilfældigt), så er sandsynligheden for brud drastisk reduceret. Usaltede adgangskoder valgt af mennesker er generelt sårbare over for ordbogsangreb, fordi de normalt vælges til at være korte og nemme nok at huske. Selv en lille ordbog (eller dens hash-ækvivalent, en hash-tabel) er en stor hjælp til at knække de mest almindeligt anvendte adgangskoder.
Fra et teknisk synspunkt beskytter salt mod hash-tabeller og regnbuetabeller, fordi det i det væsentlige forlænger længden og potentielt kompleksiteten af adgangskoden . Hvis der ikke er adgangskoder i regnbuetabeller, der matcher længden (f.eks. 8 byte adgangskode og 12 byte salt, som i det væsentlige er en 20 byte adgangskode) og kompleksiteten (komplekst salt med høj entropi øger kompleksiteten af simple stærke alfanumeriske adgangskoder) af den saltede password , vil adgangskoden ikke blive fundet.
Det moderne skyggeadgangskodesystem , hvor adgangskode-hash og andre sikkerhedsdata gemmes i en ikke-offentlig fil, løser til dels problemet med uautoriseret adgang til hash-filen. Samtidig forbliver de relevante i multi-server-installationer, der bruger centraliserede adgangskodestyringssystemer til at overføre adgangskoder eller kodeords-hash til flere systemer [8] .
Salt gør også ordbogsangreb og brute-force-angreb til at knække et stort antal passwords ekstremt langsomme (men ikke i tilfælde af kun at knække et password). Uden et salt er en angriber, der knækker et stort sæt kodeord, tvunget til at sammenligne hver gang med alle kandidater. I betragtning af at saltet kan være dynamisk, bør hver salt-indstilling forsøges at anvende på hver adgangskode fra listen.
En anden fordel ved et salt er, at to brugere kan vælge den samme streng som deres adgangskode, eller den samme bruger kan bruge den samme adgangskode på to computere. Uden saltet vil denne adgangskode blive gemt som den samme hash-streng i adgangskodefilen. Dette ville afsløre det faktum, at de to konti har den samme adgangskode, hvilket giver alle, der kender en af kontoens adgangskoder, adgang til den anden konto. Når salt er blandet i, selvom to konti bruger den samme adgangskode, kan ingen opdage det ved blot at se på hash-værdierne.
De fleste UNIX -systemer bruger crypt(3) systembiblioteket som en envejsfunktion . Til at begynde med brugte dette bibliotek en hash-funktion baseret på DES-algoritmen . I dette tilfælde var adgangskoden begrænset til 8 tegn (7 bits pr. tegn, det vil sige 56 bits), og der blev brugt et 12-bit salt [9] .
I 1994 skabte Poul-Henning Kamp en ny password-hashing-algoritme baseret på MD5 , der tillod adgangskoder af enhver længde og brugte tusinde iterationer af MD5 [10] [11] . Resultatet af funktionen var en streng, der indeholdt etiketten for hashing-algoritmen (version), salt og hash.
På det tidspunkt var forsinkelsen til at beregne en sådan hash tilstrækkelig til effektivt at modstå brute-force password-gætning. Men efterhånden som computerkraften er vokset, er tiden til at finde MD5 faldet dramatisk. Dette har ført til fremkomsten af beregningsmæssigt mere komplekse algoritmer i krypten og kontrol over antallet af iterationer [12] .
Biblioteket understøtter nu flere hash-funktioner baseret på algoritmer: MD5 , SHA-256 , SHA-512 , Blowfish (i nogle Linux - distributioner , OpenBSD og nogle andre UNIX-lignende systemer) [13] . Resultatet af funktionen er en streng, der indeholder etiketten for hash-algoritmen, salt, hash og andre data (f.eks. antallet af runder af hash-funktionen).
I 2012 opfordrede Poul-Henning Kamp til fuldstændig opgivelse af den md5crypt-algoritme, han lavede, da den ikke giver en håndgribelig forøgelse af hash-beregningstiden under moderne forhold, og derfor ikke beskytter mod udtømmende opregning [14] .