Sůl (kryptografie) - Salt (cryptography)

V kryptografii , je sůl je náhodná data, která se používá jako další vstup do funkce jednosměrné , že hodnoty hash dat , což je heslo nebo heslo . Soli se používají k ochraně hesel v úložišti. Historicky byla v systému uložena pouze kryptografická hashovací funkce hesla, ale postupem času byly vyvinuty další záruky na ochranu před identifikací duplicitních nebo běžných hesel (protože jejich hash jsou identické). Jednou takovou ochranou je solení.

Pro každé heslo je náhodně generována nová sůl. Obvykle jsou sůl a heslo (nebo jeho verze po natažení klíče ) zřetězeny a přivedeny do kryptografické hashovací funkce a výstupní hodnota hash (ale ne původní heslo) je uložena se solí v databázi. Hašování umožňuje pozdější autentizaci bez uchování, a tedy riziko vystavení hesla prostého textu, pokud je ohroženo úložiště dat autentizace. Všimněte si toho, že kvůli tomu nemusí být soli šifrovány ani ukládány odděleně od samotného hašovaného hesla, protože i když má útočník přístup k databázi s hodnotami hash a solemi, správné použití uvedených solí bude bránit běžnému útoky.

Soli se brání útokům, které používají předpočítané tabulky (např. Duhové tabulky ), protože mohou velikost tabulky potřebné pro úspěšný útok neúměrně zvětšit, aniž by zatěžovaly uživatele. Protože se soli navzájem liší, chrání také nadbytečná (např. Běžně používaná, opakovaně používaná) hesla, protože pro různé instance stejného hesla jsou vytvářeny různé solené hashe.

Kryptografické soli jsou široce používány v mnoha moderních počítačových systémech, od pověření systému Unix po zabezpečení internetu .

Soli úzce souvisí s konceptem kryptografické nonce .

Příklad použití

Zde je neúplný příklad hodnoty soli pro ukládání hesel. Tato první tabulka obsahuje dvě kombinace uživatelského jména a hesla. Heslo není uloženo.

Uživatelské jméno Heslo
uživatel 1 heslo123
uživatel2 heslo123

Hodnota soli je generována náhodně a může mít libovolnou délku; v tomto případě je hodnota soli dlouhá 8 bytů . Hodnota soli je připojena k heslu ve formátu prostého textu a poté je výsledek hašován, což se označuje jako hodnota hash. Uloží se jak hodnota soli, tak hodnota hash.

Uživatelské jméno Hodnota soli Řetězec k hašování Hašovaná hodnota = SHA256 (heslo + hodnota soli)
uživatel 1 E1F53135E559C253 password123 E1F53135E559C253 72AE25495A7981C40622D49F9A52E4F1565C90F048F59027BD9C8C8900D5C3D8
uživatel2 84B03D034B409D4E password123 84B03D034B409D4E B4B6603ABC670967E99C7E7F1389E40CD16E78AD38EB1468EC2AA1E62B8BED3A

Jak ukazuje výše uvedená tabulka, různé hodnoty soli vytvoří zcela odlišné hodnoty hash, i když jsou hesla pro prostý text úplně stejná. Navíc, slovníkové útoky jsou zmírněny do té míry, jako útočník nemůže prakticky precompute hodnoty hash . Sůl však nemůže chránit běžná nebo snadno uhádnutá hesla.

Bez soli je hodnota hash pro všechny uživatele, kteří mají dané heslo, stejná, což hackerům usnadní uhádnutí hesla z hodnoty hash:

Uživatelské jméno Řetězec k hašování Hašovaná hodnota = SHA256
uživatel 1 heslo123 57DB1253B68B6802B59A969F750FA32B60CB5CC8A3CB19B87DAC28F541DC4E2A
uživatel2 heslo123 57DB1253B68B6802B59A969F750FA32B60CB5CC8A3CB19B87DAC28F541DC4E2A

Obyčejné chyby

Opětovné použití soli

Použití stejné soli pro všechna hesla je nebezpečné, protože předpočítaná tabulka, která jednoduše odpovídá soli, učiní sůl zbytečnou.

Generování předpočtených tabulek pro databáze s jedinečnými solemi pro každé heslo není životaschopné z důvodu výpočetních nákladů. Pokud se však pro všechny položky použije společná sůl, vytvoření takové tabulky (která sůl představuje) se pak stane životaschopným a možná i úspěšným útokem.

Protože opětovné použití soli může způsobit, že uživatelé se stejným heslem budou mít stejný hash, prolomení jednoho hash může mít za následek kompromitaci dalších hesel.

Krátká sůl

Pokud je sůl příliš krátká, může útočník předběžně vypočítat tabulku všech možných solí připojenou ke každému pravděpodobnému heslu. Použití dlouhé soli zajistí, že taková tabulka bude neúměrně velká.

Výhody

Abyste porozuměli rozdílu mezi prolomením jednoho hesla a jejich sady, zvažte soubor s uživateli a jejich hašovaná hesla. Řekněme, že soubor je neslaný. Poté by útočník mohl vybrat řetězec, nazvat jej pokusem [0] a poté vypočítat hash (pokus [0]). Uživatel, jehož hash uložený v souboru je hash (pokus [0]), může, ale nemusí mít pokus o heslo [0]. I když však pokus [0] není skutečným heslem uživatele, bude přijat, jako by byl, protože systém může hesla kontrolovat pouze tak, že vypočítá hash zadaného hesla a porovná jej s hashem uloženým v souboru. Každý zápas tedy prolomí uživatelské heslo a šance na shodu stoupá s počtem hesel v souboru. Naproti tomu, pokud jsou použity soli, útočník by musel vypočítat hash (pokus [0] || sůl [a]), porovnat s položkou A, pak hash (pokus [0] || sůl [b]), porovnat s vstup B atd. To zabrání jakémukoli pokusu o prolomení více hesel (pouze pokud je zabráněno opakovanému použití soli).

Soli také bojují s používáním předpočítaných tabulek k prolomení hesel. Taková tabulka může jednoduše mapovat běžná hesla do jejich hashů, nebo může dělat něco složitějšího, jako je uložení počátečního a koncového bodu sady předpočítaných hashovacích řetězců . V obou případech se solení může bránit proti použití předpočtených tabulek prodloužením hashů a jejich čerpáním z větších znakových sad, takže je méně pravděpodobné, že tabulka pokrývá výsledné hashe. Předpočítaná tabulka by zejména potřebovala pokrýt řetězec [sůl + hash], nikoli pouze [hash].

Moderní stínový systém hesel , ve kterém jsou hash hesel a další bezpečnostní data uložena v neveřejném souboru, tyto obavy poněkud zmírňuje. Zůstávají však relevantní v instalacích na více serverech, které používají centralizované systémy pro správu hesel k zasílání hesel nebo hash hesel do více systémů. V takových instalacích může být kořenový účet v každém jednotlivém systému považován za méně důvěryhodný než administrátoři centralizovaného systému hesel, takže je užitečné zajistit, aby bezpečnost algoritmu pro hash hesla, včetně generování jedinečných hodnot soli, byla adekvátní.

Další (menší) výhoda soli je následující: dva uživatelé si mohou vybrat stejný řetězec jako heslo nebo stejný uživatel může použít stejné heslo na dvou počítačích. Bez soli by bylo toto heslo uloženo jako stejný řetězec hash v souboru hesel. To by odhalilo skutečnost, že dva účty mají stejné heslo, což umožňuje každému, kdo zná jedno z hesel účtu, přístup k druhému účtu. Nasolením hesel dvěma náhodnými znaky, i když dva účty používají stejné heslo, to nikdo nemůže zjistit pouhým čtením hashů.

Implementace Unixu

70. – 80

Dřívější verze Unixu používaly soubor hesel /etc/passwd k ukládání hashů zasolených hesel (hesla s předponou dvouznakových náhodných solí). V těchto starších verzích Unixu byla sůl také uložena v souboru passwd (jako čistý text) společně s hashem soleného hesla. Soubor hesel byl veřejně čitelný pro všechny uživatele systému. To bylo nutné, aby softwarové nástroje privilegované uživateli mohly najít jména uživatelů a další informace. Zabezpečení hesel je proto chráněno pouze jednosměrnými funkcemi (šifrováním nebo hashováním) používanými k tomuto účelu. Rané implementace Unixu omezovaly hesla na osm znaků a používaly 12bitovou sůl, což umožňovalo 4096 možných hodnot soli. To byla přiměřená rovnováha pro výpočetní a skladovací náklady sedmdesátých let.

Osmdesátá léta -

Viz také: Soubor Passwd § Shadow

Systém stínových hesel slouží k omezení přístupu k hashům a soli. Sůl má osm znaků, hodnota hash je 86 znaků a délka hesla je neomezená.

Implementace webových aplikací

Je běžné, že webová aplikace ukládá do databáze hodnotu hash hesla uživatele. Bez soli může úspěšný útok s injekcí SQL poskytnout snadno prolomitelná hesla. Protože mnoho uživatelů znovu používá hesla pro více webů, je použití soli důležitou součástí celkového zabezpečení webových aplikací . Některé další odkazy na používání soli k zabezpečení hash hesel v konkrétních jazycích nebo knihovnách (PHP, knihovny .NET atd.) Lze nalézt v sekci externích odkazů níže.

Viz také

Reference

externí odkazy