A kriptográfia kezdője vagyok, és nagyon egyszerűen meg akarom érteni, mi az a kriptográfiai ” só ” az, amikor esetleg használnom kell, és miért kell vagy nem kell használnom.
Kaphatok egy nagyon egyszerű és világos (kezdő szintű) magyarázat?
Ha tudsz valamilyen utalást a témáról, azok is hasznosak lehetnek.
Válasz
A sók használatának oka az, hogy az emberek hajlamosak ugyanazokat a jelszavakat választani, és egyáltalán nem véletlenszerűen. Sokan használt jelszavak vannak rövid, valódi szavakkal, hogy könnyen megjegyezhetők legyenek, de ez is lehetővé teszi a támadást.
Mint azt Ön is tudja, a jelszavakat általában nem tiszta szövegben tárolják, hanem inkább kivonatolják. Ha nem biztos abban, hogy mi a hash-funkció, akkor olvassa el először ezt.
A támadók most annyit tehetnek, hogy egyszerűen létrehozzák a közös jelszavak és a hozzájuk tartozó hashek listáját. A webhely által a táblával együtt tárolt kivonatok, ha általános jelszavakat használnak, felfedik a jelszavakat a támadó számára.
A salt egyszerűen hozzáadódik a fájlhoz, hogy a jelszó kivonat kimenete egyedivé váljon még a felhasználók számára is közös jelszavak elfogadása t. Célja, hogy az előzetes számításon alapuló támadások haszontalanná váljanak. Ha a jelszavát egyedi sóval tárolják, akkor minden előre kiszámított, sózatlan jelszó-hash-t célzó jelszó-hash tábla vagy egy másik sóval rendelkező fiók megcélzása nem segít a fiók jelszavának feltörésében. Hosszú, véletlenszerűen generált só (/dev/urandom) várhatóan globálisan egyedi . Így a sók felhasználhatók előkészítésre -számítási támadások teljesen hatástalanok.
A só és a jelszó kombinálásának legegyszerűbb módja az egyszerű összefűzés, vagyis a tárolt hash érték Hash(salt||password). A jelszó password1 most varázsütésre válik pl. 6$dK,3gCA%Jpassword1, amely valószínűleg nem található meg a jelszó feltörő táblájában.
A só teljesen tárolható az adatbázis tiszta részén, a kivonatolt érték mellett. Miután a támadónak megvan az adatbázisa, és meg akarja találni a jelszavakat, elő kell állítania az egyes sókra előre kiszámolt táblázatot, ami költséges művelet.
Az offline jelszó-feltörés elleni védekezés másik módja a végrehajtás jelszó nyújtás, azaz. a jelszó kivonatának elkészítése lassabban kiszámítható bármely személy számára, beleértve a bejelentkezési szolgáltatást és a jelszó-feltörőket. A jelszavak nyújtására szolgáló egyik módszert a hash-függvény sokszorosításával, azaz a Hash(Hash(Hash(Hash…(Hash(salt||password)))…) tárolásával érjük el.
A sózással kapcsolatos másik gyakori ötlet bors . Vagyis egy másik, a jelszóhoz összefűzött véletlenszerű érték úgy, hogy a tárolt érték Hash(pepper||salt||password). A paprikát ezután egyáltalán nem tárolja . Mind a bejelentkezési kiszolgálónak, mind a jelszó-feltörőnek el kell kényszerítenie az ismeretlen paprikaértéket, lassítva a jelszó-kivonatok összehasonlítását mindkét fél számára.
2013-tól 2015-ig a jelszó-hash versenyt rendeztek a jobb jelszó-nyújtó algoritmus keresésére. A nyertes az Argon2 algoritmus lett. A programozóknak az Argon2 használatát javasoljuk saját algoritmusuk megvalósítása helyett .
Megjegyzések
- Tehát lényegében, ha csak egy vagy 2 jelszó van tárolva az adatbázisban, akkor a só használata gyakorlatilag haszontalan? Megértem, hogy ez csak akkor hasznos, ha az adatbázisban tárolt jelszavak száma nem csekély.
- @AbhinavChoudhury: Nem, véd a szivárványos táblázatokkal szemben – vagyis egy adott hash előre kiszámított táblázatai ellen. Példa: Vegyen jelszót ” jelszó1 “. Ha nem ‘ sót nem tartalmaz, akkor ‘ d tárolja a HASH (” jelszó1 “) az adatbázisban. Most, ha a támadó megkapja az iratokat, és előre kiszámította a HASH-t (*) az összes 9 karakteres jelszóhoz, helyreállíthatja a jelszót. Ha ehelyett sózta a jelszót, HASH (‘ somesaltforyou ‘ || ‘ jelszó1 ‘) NEM szerepel a támadók szivárványos táblájában (mivel ‘ több, mint 9 karakter).
- ” A só teljesen tárolható az adatbázis tiszta részében, a kivonatolt érték mellett ” – – ez a rész soha nem volt igazán értelmes számomra; Arra gondoltam, hogy kibővítheti-e ezt
- A só lényege, hogy megbizonyosodjon arról, hogy a kivonat nem található-e egy előre kiszámolt táblázatban. A jelszó ellenőrzéséhez tárolni kell (különben ‘ sa ” bors “). A só nem állítólag ” titkos “, csak a jelszó egyedivé tétele. Ez természetesen azt jelenti, hogy minden tárolt jelszónak saját, egyedi (és véletlenszerű) sóval kell rendelkeznie.
Válasz
Tudna segíteni abban, hogy megértsem, mi a kriptográfiai „só”?
A jelszóval összefüggésben létrehozásakor a “só” olyan adat (véletlenszerű vagy más), amely hozzáadódik egy hash függvényhez annak érdekében, hogy a jelszó kivonatolt kimenetét nehezebb feltörni.
Mikor kell használnom?
Mindig.
Miért használjam vagy ne használjam?
Az alábbiakban ismertetett okokból mindig használjon sóértéket a hash függvényekkel együtt.
Általában igaz, hogy az emberek gyenge jelszavakat választanak, és minden bizonnyal igaz, hogy vannak gigabájt nyilvánosan elérhető szivárványos táblák , amelyek tele vannak hasított értékekkel. Tehát, amikor valaki létrehoz egy fiókot a szolgáltatásán, és jelszavát választja személyazonosságának biztosításához, akkor általában fogadhat, hogy az általa választott jelszó 1) általános, 2) nem biztonságos és 3) elérhető lesz a kereszthivatkozásokhoz a keresési táblákban.
Például a jelszó Nowayin1 az MD5-n keresztül kivonatolva 6f367d65bc74b88e21fb9959487ffa3a és nyilvánvalóan nem jó választás. Még akkor is, ha jól néz ki (és nem “t”), az a tény, hogy a jelszó MD5 hashja megjelenik a nyitott adatbázisokban, értéktelenné teszi azt.
De ez csak 128 bites MD5. Mi a helyzet valamivel erősebb, mint az SHA1 (160 bites) vagy akár a Whirlpool (512 bites)?
Ugyanez a probléma.
Például: Az P @ $$ szó az SHA1-tel 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 és
1qazXSW @ kivonatolt a örvény 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .
Ezen jelszavak – és még több milliárd hasonló jelszó – gyökérproblémája az a tény, hogy általánosan használt hashjeik közismertté váltak.
A jelszó só ezen változtat.
Ha véletlenszerű értéket (a sót) adunk a felhasználó kiválasztott jelszavához, akkor az SHA1 hash 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 már nem fedné fel a iv id = “703de9e2ce” $ $ wordd a felhasználó jelszavaként, mert a szivárványtáblán található hash érték már nem egyezik meg vele.
És nem is kellene sok. Egy kis, 16 bites véletlenszerű érték például 65 536 változatot eredményezne a keresési táblákban szereplő egyes hash értékekből. Tehát egy 15 milliárd bejegyzésből álló adatbázishoz több mint 983 milliárd hashra van szükség a só elszámolásához. “Ne akaszd fel a kalapodat egy sózott hashra, mert a hackerek nem fognak sok időt pazarolni a szivárványos táblázatokkal a jelszavak kitalálásához.
” öt kiszolgálós, 25 GPU-os fürtrendszer , amely Hashcat programot futtat, és másodpercenként 350 milliárd találgatást képes felírni, minden egyes elképzelhető nyolc karakteres, nagy- és kisbetűket, számokat és speciális karaktereket tartalmazó jelszó alatt, alig. hat óra. (És ez még 2012-ben volt.)
Az olyan hardverek sebességének ellensúlyozására használhatók olyan technikák, mint a kulcsfeszítés, amely lassabban futtatja a kivonatokat, így a szótár és a durva erővel járó támadások túl lassúak ahhoz, hogy megérjék , de a hardver csak egyre gyorsabbá válik.
UPDATE 2018:
A jelenlegi bevált módszerek közé tartozik a jelszavak biztonságos megosztása az Argon2i használatával (a scrypt helyett előnyben részesítve), amely egy memória-nehéz funkció, amely nagyon rugalmas az FPGA-k, a multiplecore GPU-k és a dedikált ASIC-modulok számára, amelyek a nem kifeszített jelszavak könnyű feltörésére szolgálnak. Az Argon2 PHP7 megvalósításában a sót belsőleg kezelik az Ön számára.
Válasz
Megpróbálom megválaszolni kérdésének egy részét, amelyet eddig elhanyagoltak:
mikor kell használnom, és miért kell / nem kellene használnom.
A rövid válasz az, hogy amatőrként nem szabad olyan szinten használni a kriptográfiát, amely megköveteli a sók közvetlen kezelését.
Például a bcrypt a jelszó-elosztó algoritmus belsőleg használja a sókat. De ezt a tényt nem tárja fel az azt használó fejlesztők – egyszerűen át kell adnia a jelszót a bcrypt címre (és opcionálisan egy paraméterre, amely beállítja a “szintet” CPU-erőfeszítés “szükséges a kivonat előállításához), és visszaadja a kivonatot. Ha ellenőriznie kell, hogy egy jelszó helyes-e, akkor át kell adnia a bcrypt jelszót és a korábban létrehozott kivonatot is. Ez jelzi, hogy a kivonat előállításához használt-e a jelszót.
Ne ne vegye figyelembe az itt megadott tanácsokat, és próbálja meg só segítségével kivonatolni saját jelszavát. Alacsony szintű megvalósítási részlet, és ha olyan szinten dolgozik, ahol ilyen jellegű dolgokra van szükség, túl alacsony szintű absztrakcióval dolgozik. A kriptográfiát nagyon nehéz helyesen elvégezni, és az internet abszolút tele van jó szándékú fejlesztőkkel, “teljesen bizonytalanok a saját fejlesztésű jelszó-elosztási sémákkal.
Válasz
Idézve „ Vizsga hivatkozás 70-486 ASP.NET MVC 4 webalkalmazások (MCSD) fejlesztése: ASP.NET MVC 4 webalkalmazások fejlesztése ” írta William Penberthy, Pearson Education, 2013. szeptember 15 .:
A sózás olyan folyamat, amely erősíti a fájlok titkosítását és kivonatolását, és megnehezíti a megtörésüket. véletlenszerű karakterlánc a beviteli szöveg elejére vagy végére az érték hasítása vagy titkosítása előtt. Ha például megpróbálják feltörni a jelszavak listáját, a hackereknek el kell számolniuk a sóval, valamint a lehetséges jelszóval kapcsolatos információkkal, mielőtt meg tudnák szakítani Ha minden egyes sózandó értékhez más sóérték van rendelve, akkor lehetősége van létrehozni egy táblázat lehetséges jelszóértékeit egy Az ssword-feltörő program nehézkessé válik.
Válasz
A só véletlenszerű szám, amely a titkosított adatok eléréséhez szükséges, a jelszóval együtt.
Ha a támadó nem ismeri a jelszót, és durva erővel próbálja kitalálni, akkor minden jelszót megpróbál minden sóértéknél meg kell próbálni.
Tehát egy bites só (0 vagy 1) esetén ez kétszer olyan nehézzé teszi a titkosítást. A két bites só négyszer keményebbé teszi, a három bites só nyolcszor keményebbé, stb. El tudja képzelni, milyen nehéz 32 bites sót használó titkosítással feltörni a jelszavakat!
Hozzászólások
- Nem. Feltételezzük, hogy a támadó ismeri a sót. Ebben az esetben valamilyen alacsony küszöbérték felett a só nem javítja a biztonságot.
- ” Feltételezzük, hogy a só ismeretes a támadó számára “>
– > Ki feltételezi ezt?