A só (szintén egy hash függvény bemeneti módosítója ) egy olyan adatkarakterlánc , amelyet a hash függvénynek adunk át a bemeneti adattömbbel ( preimage ) együtt a hash ( kép ) kiszámításához.
Arra használják, hogy megnehezítsék a hash függvény előképének meghatározását a lehetséges bemeneti értékek (előképek) szótárán keresztüli iterációval , beleértve a szivárványtáblázatokat használó támadásokat is . Lehetővé teszi, hogy elrejtse ugyanazokat a prototípusokat, ha különböző sókat használ hozzájuk. Létezik statikus só (minden bemeneti értékhez ugyanaz) és dinamikus só (minden bemeneti értékhez külön-külön generálódik).
Legyen a jelszavak kivonatolása az MD5 algoritmussal , és tárolható hash értékként az adatbázisban . Adatbázis-lopás esetén az eredeti jelszavakat előre elkészített szivárványtáblák segítségével lehet visszaállítani , mivel a felhasználók gyakran használnak megbízhatatlan jelszavakat, amelyeket könnyen kiválaszthatnak a szótárakból [1] . Ha a jelszó „sózott”, azaz a hash értékek kiszámításakor a bemeneti adatokhoz egy több véletlenszerű karakterből álló sztringet fűzzünk hozzá, amely a sóérték lesz, akkor a kapott értékek nem fognak egyezni a közös hash-érték szótárakkal. A só ismerete lehetővé teszi, hogy új szótárakat hozzon létre az ismétléshez, ezért a só értékét titokban kell tartani. A só esetében ugyanazok az összetettségre vonatkozó ajánlások érvényesek, mint a jelszó összetettségére, azaz a só értékének jó entrópiájú és hosszúságúnak kell lennie [2] .
Példa hash létrehozására statikus só használatával PHP - ben a bemeneti adatokkal való összefűzés (összekapcsolás) elve alapján :
$jelszó1 = '12345' ; $ jelszó2 = '67890' ; $só = 'sflpr9fhi2' ; // Só $password1_saltedHash = md5 ( $password1 . $salt ); // Összefűzzük a bemeneti karakterláncot a sóval, és átengedjük az md5() hash függvényen $password2_saltedHash = md5 ( $password2 . $salt );Ebben a példában a só egy determinisztikus karakterlánc, ami azt jelenti, hogy a só értéke minden bemeneten állandó.
Léteznek dinamikus sóképzési sémák, amelyekben minden bemeneti értékhez külön-külön generálnak sóértékeket, ami megnehezíti a brute-force szótárak összeállítását, és elrejti a különböző felhasználók által használt azonos jelszavak tárolásának tényét is. A séma hatékonysága is nő, ha nem triviális keverést alkalmazunk valamilyen algoritmus szerint. Például a só nem csak a jelszó végére adható, hanem a jelszó bizonyos időközönként „bekeverhető”. Ezenkívül a hash ciklikusan is kiszámítható, a sót részenként, némi változtatással [3] keverve, a hash iterációs számától függően .
Az egyik jól ismert PBKDF2 szabvány a só keverését több iterációban írja le.
| Felhasználónév | Jelszó | md5 (jelszó) | só | jelszó+só | md5 (jelszó+só) |
|---|---|---|---|---|---|
| felhasználó1 | qwerty123 | 3fc0a7acf087f549ac2b266baf94b8b1 | 5 óra 8 óra 32 óra | qwerty1235hr8Uh32Hr | 1dfa98fc519fc0022e86014445d8b158 |
| felhasználó2 | qwerty123 | 3fc0a7acf087f549ac2b266baf94b8b1 | Ju5yFy35Jk | qwerty123Ju5yFy35Jk | 269777fd3b1c37ef1cfc1e238213324f |
A fenti táblázat azt mutatja, hogy ugyanazok a felhasználói jelszavak különböző dinamikus sóval végül különböző hash értékeket adnak.
Az engedélyezési rendszer adatbázisához való jogosulatlan hozzáféréssel a támadó az adatbázisból megszerezheti a felhasználók nevében történő engedélyezéshez szükséges információkat. Ha a jelszavakat eredeti (tiszta) formájukban tárolják, a támadó más erőforrásokhoz is hozzáférhet velük, mivel a felhasználók gyakran ugyanazokat a jelszavakat használják különböző webszolgáltatásokhoz [4] . A dinamikus só használata lehetővé teszi, hogy elkerülje a felhasználói fiókok veszélyeztetését egyszerre több webszolgáltatáson.
Egy rosszul átgondolt só felhasználási rendszerrel elvesznek előnyei:
Kis sóhossz és alacsony entrópia
Ha a só rövid, a támadó könnyen létrehozhat egy szivárványtáblát, amely egy bizonyos hosszúságú összes lehetséges sót tartalmaz, minden lehetséges jelszóhoz hozzáadva. Továbbá, ha alacsony entrópiájú sót használunk, megnő annak esélye, hogy sikeresen megtaláljuk a sót a szótárban, ezért a só értékét ideális esetben RNG segítségével kell előállítani [5] . A jó entrópiával rendelkező hosszú só használata biztosítja, hogy az adatbázis szivárványtáblája túl nagy lesz, és jelentős támadói erőforrásokat igényel az előállítás és tárolás [6] .
Só újrafelhasználása különböző prototípusokhoz
Bár a statikus só használata ugyanazokhoz az előképekhez használhatatlanná tesz néhány meglévő szivárványtáblát, meg kell jegyezni, hogy ha a sót statikusan beírják egy népszerű termék forráskódjába, akkor előbb-utóbb kinyerhető, ami után egy új ebből a sóból szivárványasztal készíthető. Ha a sót dinamikusan állítjuk elő minden egyes előképhez egyedileg, egyedi paraméterek felhasználásával minden felhasználó számára, akkor a rendszer stabilitása nő.
Egy rögzített só használata azt is jelenti, hogy minden felhasználónak, aki ugyanazt a jelszót adja meg, ugyanaz a hash lesz. Ez megkönnyíti több felhasználó megtámadását az ismétlődő hashek egyikének feltörésével [7] .
Ahhoz, hogy megértse, mi a különbség egyetlen jelszó feltörése és beírása között, vegyen fontolóra egy jelszófájlt, amely több száz felhasználónevet és kivonatolt jelszót tartalmaz. Só nélkül a támadó kiszámolhat egy bizonyos értékű hash-t (például egy szótárból), majd ellenőrizheti, hogy ez a hash előfordul-e bárhol a fájlban. Az egyezés, azaz az egyik jelszó feltörésének valószínűsége nyilvánvalóan növekszik a fájlban található jelszavak számával. Ha sót használnak, és ráadásul dinamikus, azaz legalább több lehetséges értéke van egy hash-hez, akkor a támadónak ki kell számítania minden lehetséges sópárhoz és a keresett jelszóhoz a hash-t, ami drámaian növeli a keresés bonyolultságát.
A só azt is lehetővé teszi, hogy megakadályozza a hash táblák használatát a jelszavak feltörésére. A felhasználói jelszavak esetében a hash tábla a gyakran használt jelszavak előre kiszámított kivonatainak gyűjteménye. A nem sózott jelszófájl esetén a támadó végigjárhatja az egyes bejegyzéseket, és megtalálhatja a megfelelő kivonatolt jelszót a hash-táblázatban. Mivel a keresés sokkal gyorsabb, mint a hash számítás, ez nagyban felgyorsítja a jelszavak feltörésének folyamatát. De ha a jelszófájl sóval van kialakítva, akkor a hash-táblázatnak tartalmaznia kell a sóval előre kivonatolt értékeket. Ha a só elég hosszú és nagy entrópiájú (véletlenszerű), akkor a feltörés valószínűsége drasztikusan csökken. Az emberek által választott, sótlan jelszavak általában ki vannak téve a szótári támadásoknak, mivel általában úgy választják meg őket, hogy rövidek és könnyen megjegyezhetőek. A leggyakrabban használt jelszavak feltörésében még egy kis szótár (vagy annak kivonatolt megfelelője, egy hash-tábla) is nagy segítséget jelent.
Technikai szempontból a só védelmet nyújt a hash-táblázatokkal és a szivárványtáblákkal szemben, mivel lényegében meghosszabbítja a jelszó hosszát és potenciálisan összetettségét . Ha a szivárványtáblákban nincsenek olyan jelszavak, amelyek megfelelnek a sózott jel hosszának (pl. 8 bájtos jelszó és 12 bájtos só, ami lényegében 20 bájtos jelszó) és összetettségéhez (a nagy entrópiájú összetett só növeli az egyszerű, erős alfanumerikus jelszavak összetettségét) jelszót, a jelszó nem található.
A modern árnyékjelszó -rendszer , amelyben a jelszókivonatokat és egyéb biztonsági adatokat egy nem nyilvános fájlban tárolják, részben megoldja a hash fájlhoz való jogosulatlan hozzáférés problémáját. Ugyanakkor továbbra is relevánsak maradnak a többkiszolgálós telepítésekben, amelyek központi jelszókezelő rendszereket használnak a jelszavak vagy jelszókivonatok átvitelére több rendszerre [8] .
A Salt emellett rendkívül lelassítja a szótári támadásokat és a nagyszámú jelszó feltörésére irányuló brute force támadásokat (de nem abban az esetben, ha csak egy jelszót törnek fel). Só nélkül egy támadó, aki nagy számú jelszót tör fel, minden alkalommal kénytelen összehasonlítani az összes jelölttel. Tekintettel arra, hogy a só lehet dinamikus, akkor minden só opciót meg kell próbálni alkalmazni minden egyes jelszóra a listából.
A só másik előnye, hogy két felhasználó ugyanazt a karakterláncot választhatja jelszavának, vagy ugyanaz a felhasználó használhatja ugyanazt a jelszót két számítógépen. A só nélkül ez a jelszó ugyanazon hash karakterláncként kerül tárolásra a jelszófájlban. Ez feltárná azt a tényt, hogy a két fióknak ugyanaz a jelszava, így bárki, aki ismeri az egyik fiók jelszavát, hozzáférhet a másik fiókhoz. Amikor sót keverünk bele, még ha két fiók ugyanazt a jelszót használja is, senki sem tudja felismerni a hash értékek megtekintésével.
A legtöbb UNIX rendszer a crypt(3) rendszerkönyvtárat egyirányú funkcióként használja . Kezdetben ez a könyvtár a DES algoritmuson alapuló hash függvényt használt . Ebben az esetben a jelszót 8 karakterre korlátozták (karakterenként 7 bit , azaz 56 bit), és 12 bites sót használtak [9] .
1994-ben Poul-Henning Kamp új, MD5 -ön alapuló jelszókivonat-algoritmust hozott létre, amely tetszőleges hosszúságú jelszavakat engedélyezett, és az MD5 ezer iterációját használta [10] [11] . A függvény eredménye egy karakterlánc volt, amely a hash algoritmus (verzió) címkéjét, a sót és a hash-t tartalmazza.
Abban az időben az ilyen hash kiszámításának késleltetése elegendő volt ahhoz, hogy hatékonyan ellenálljon a brute force jelszókitalálásnak. A számítási teljesítmény növekedésével azonban drámaian lecsökkent az MD5 megtalálásának ideje. Ez számítási szempontból bonyolultabb algoritmusok megjelenéséhez vezetett a kriptában és az iterációk számának szabályozásában [12] .
A könyvtár ma már számos algoritmuson alapuló hash függvényt támogat: MD5 , SHA-256 , SHA-512 , Blowfish (egyes Linux disztribúciókban , OpenBSD és néhány más UNIX-szerű rendszer) [13] . A függvény eredménye egy karakterlánc, amely a kivonatolási algoritmus címkéjét, sót, hash-t és egyéb adatokat (például a hash-függvény fordulóinak számát) tartalmazza.
Poul-Henning Kamp 2012-ben az általa megalkotott md5crypt algoritmus teljes elhagyását szorgalmazta, mivel az a modern körülmények között nem biztosít kézzelfogható hash-számítási időnövekedést, ezért nem véd a kimerítő felsorolás ellen [14] .