Salt (kryptering)
I kryptografi er et salt en tilfeldig sekvens av biter som brukes i forbindelse med et passord som input til en enveisfunksjon , vanligvis en hash-funksjon, hvis utdata lagres i stedet for passordet alene, og kan brukes til å autentisere brukere.
Saltet brukes til å beskytte passord som er lagret i minnet. Historisk sett ble passord lagret i en tekstfil på systemet, men over tid har teknikker blitt tatt i bruk som bedre beskytter deres sikkerhet for å forhindre at de blir lest av en hypotetisk ondsinnet bruker. Salt er en av disse teknikkene.
Saltet genereres tilfeldig hver gang et passord genereres.
Ved å bruke saltdata er ordbokangrep kompliserte , den klassen av angrep som utnytter en tidligere kryptering av oppføringene til en liste over sannsynlige nøkkelord for å sammenligne dem med originalen: hver saltbit som brukes dobler faktisk mengden lagring og beregning som kreves for å angrep.
Vanligvis lagres saltet sammen med antall iterasjoner ( key stretching ) og utgangen av enveisfunksjonen, men for å øke sikkerheten er det vanlig å holde saltverdien hemmelig og holde den adskilt fra passorddatabasen . Dette gir en fordel når databasen med passord blir stjålet, men ikke saltet. For å oppdage et passord fra en stjålet hash, kan en angriper faktisk ikke begrense seg til å prøve vanlige passord (for eksempel ordene eller navnene på det italienske språket ), men blir tvunget til å beregne hashen av tilfeldige tegn (i hvert fall for den delen) av input antas å være salt), som er mye tregere.
Saltet er nært beslektet med konseptet en nonce , et tilfeldig tall som bare skal brukes én gang i en kryptert kommunikasjon : for eksempel brukes nonces i HTTP -protokollen i enkelte passordsammendragsberegningsoperasjoner.
Eksempel
Anta at en brukers hemmelige nøkkel blir stjålet fra en database i form av en hash, og at det opprinnelige passordet er kjent for å være et av de 200 000 ordene i det italienske språket. Når du vet at systemet bruker en 32-bit lang saltverdi, er angriperens forhåndsberegnet hash ikke lenger til noen nytte: i dette tilfellet må en angriper hash hvert ord med hver av de 2 32 (4 294 967 296) mulige saltverdier, inntil en match er funnet. Det totale antallet mulige forsøk kan oppnås ved å multiplisere antall ord i ordboken med antall mulige saltverdier:
For å fullføre et brute force-angrep, måtte angriperen beregne rundt 800 billioner hashes, i stedet for bare 200 000. Selv å vite at selve passordet er enkelt, gjør verdien av saltet det mye vanskeligere å finne passordet.
Brukseksempel
Nedenfor er et eksempel på hvordan salt brukes til å lagre et passord.
| Brukernavn | Passord |
| user1 | password123 |
| user2 | password123 |
Den første tabellen inneholder brukernavn med relative passord (som for eksempelet er frivillig identiske) til to hypotetiske distinkte brukere.
Saltverdien genereres tilfeldig og legges til passordteksten. Hash-funksjonen til denne strengen beregnes deretter. Sistnevnte vil da lagres sammen med saltverdien.
| Brukernavn | Saltverdi | Passord + Salt | Hashed verdi = SHA256 (Passord + Salt) |
| user1 | E1F53135E559C253 | password123E1F53135E559C253 | 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8 |
| user2 | 84B03D034B409D4E | password12384B03D034B409D4E | B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A |
Som du kan se, skapte forskjellige saltverdier to helt forskjellige hash-strenger, til tross for at passordene er de samme.
I alle fall kan salteteknikker ikke garantere robust beskyttelse ved svært vanlige eller lett utledelige passord.
Vanlige feil
Gjenbruk av det samme saltet
Å bruke samme salt for hver inngang betyr at alle de samme passordene vil ha samme hash-verdi. Dette gjør det enkelt å angripe flere brukere ved å dekryptere en enkelt hash.
Salt for kort
Hvis saltverdien er for liten, vil det være enkelt for en angriper å lage en regnbuetabell som inneholder alle mulige kombinasjoner av passord og salt. Bruk av et salt av passende lengde garanterer større beskyttelse mot denne typen angrep.
Fordeler
For å forstå forskjellen mellom å knekke et enkelt passord og et sett med passord, bør du vurdere en enkelt fil som inneholder hundrevis av hashed brukernavn og passord.
Uten salt kan en angriper beregne hash-funksjonen (forsøk [0]) og deretter sjekke om denne hashen vises hvor som helst i filen. Sannsynligheten for en kamp – å knekke ett av passordene med det forsøket – øker med antall passord i filen.
Hvis saltet er tilstede, må angriperen beregne hash-funksjonen (salt [a], forsøk [0]) og sammenligne den med inngangen A; den vil da beregne hasj (salt [b], forsøk [0]) og sammenligne den med inngang B. Og så videre. Dette beseirer "gjenbruk" av hashes i forsøk på å knekke flere passord.
Bruk av salt bekjemper også bruken av hashtabeller og regnbuetabeller for å knekke passord. En hash-tabell er en stor liste over tidligere beregnede hash-koder for vanlige og kjente passord. For en saltfri passordfil kan en angriper undersøke hver oppføring og se etter det hash-kodede passordet i hash-tabellen eller regnbuetabellen . Hvis søket går betydelig raskere enn å beregne hash-funksjonen (som det ofte er), vil dette fremskynde oppsprekkingen av filen betraktelig. Imidlertid, hvis filen inneholder saltpassord, må hashtabellen eller regnbuetabellen inneholde passordet + saltfeltet for å hashes. Hvis saltet er langt nok og tilfeldig nok, er sannsynligheten for suksess for denne teknikken bemerkelsesverdig lav. Passord valgt av mennesker har en tendens til å være sårbare for ordbokangrep siden de må være både korte og meningsfulle nok til å bli husket. Selv en liten ordbok (eller hasj-ekvivalent) er en betydelig hjelp til å knekke de mest brukte passordene. Siden salter ikke trenger å lagres av brukere, kan de gjøre størrelsen på regnbuebord uoverkommelig for et slikt angrep.
Moderne passordlagringssystemer, der passordhasher og andre sikkerhetsdata lagres i en ikke-offentlig fil, reduserer disse problemene noe. Imidlertid forblir de relevante i multi-server kontekster som bruker sentraliserte passordbehandlingssystemer for å sende eller hash passord til flere systemer. I slike situasjoner kan root-kontoen på hvert enkelt system behandles som mindre pålitelig enn sentraliserte passordsystemadministratorer, så det er verdt å sørge for at passordhashingalgoritmen er sikker, inkludert generering av passordverdier.
Unix-implementeringer
Tidlige versjoner av Unix brukte passwd -filen (/ etc / passwd) for å lagre passordhasher med salt (passord prefikset med to tilfeldige salttegn). Merk at i disse gamle Unix-versjonene ble saltet også lagret i klartekst i passwd-filen, sammen med passordhashen med salt, og at alle brukere av systemet kunne lese det: lesetillatelsen var nødvendig for at noen applikasjoner skulle få tilgang til brukernavn og annen informasjon. På denne måten ble sikkerheten til passordet kun beskyttet av hashing-funksjonene som ble brukt.
Implementeringer i webapplikasjoner
Mange nettapplikasjoner lagrer brukerpassord som en hash i en database. Uten saltverdi vil et vellykket SQL-injeksjonsangrep sannsynligvis føre til passordkompromittering. Siden mange brukere gjenbruker passordene sine på forskjellige nettsteder, er saltverdien en viktig komponent for sikkerheten til en nettapplikasjon. [1]
Merknader
- ^ ISC Diary - Hashing Passwords , på DShield.org . Hentet 17. februar 2021 .