Salt (také vstupní modifikátor hashovací funkce ) je datový řetězec , který je předán hashovací funkci spolu s polem vstupních dat ( preimage ) za účelem výpočtu hash ( image ).
Používá se ke ztížení určení předobrazu hašovací funkce iterací přes slovník možných vstupních hodnot (předobrazy), včetně útoků pomocí duhových tabulek . Umožňuje skrýt skutečnost použití stejných prototypů při použití různých solí. Existují statická sůl (stejná pro všechny vstupní hodnoty) a dynamická sůl (generovaná pro každou vstupní hodnotu samostatně).
Nechte hesla zahašovat pomocí algoritmu MD5 a uložit jako hodnoty hash do databáze . V případě krádeže databáze lze původní hesla obnovit pomocí předem připravených duhových tabulek , protože uživatelé často používají nespolehlivá hesla, která lze snadno vybrat ze slovníků [1] . Pokud je heslo „solené“, to znamená, že při výpočtu hodnot hash připojte ke vstupním datům řetězec několika náhodných znaků, které budou hodnotou salt, pak výsledné hodnoty nebudou odpovídat běžným slovníkům hodnot hash. Znalost soli vám umožňuje generovat nové slovníky k opakování, takže hodnota soli musí být udržována v tajnosti. Pro salt platí stejná doporučení pro složitost jako pro složitost hesla, tedy hodnota salt by měla mít dobrou entropii a délku [2] .
Příklad vytvoření hashe pomocí statické soli v PHP na principu zřetězení (spojení) se vstupními daty:
$heslo1 = '12345' ; $ heslo2 = '67890' ; $salt = 'sflpr9fhi2' ; // Salt $password1_saltedHash = md5 ( $password1 . $salt ); // Zřetězit vstupní řetězec se solí a předat jej přes hashovací funkci md5() $password2_saltedHash = md5 ( $password2 . $salt );V tomto příkladu je salt deterministický řetězec, což znamená, že hodnota salt je konstantní napříč všemi vstupy.
Existují dynamická schémata tvorby soli, ve kterých jsou hodnoty soli generovány pro každou vstupní hodnotu jednotlivě, což ztěžuje kompilaci slovníků hrubou silou a také skrývá skutečnost, že ukládají stejná hesla, která používají různí uživatelé. Také účinnost schématu se zvyšuje, pokud je použito netriviální míchání podle nějakého algoritmu. Například sůl lze nejen přidat na konec hesla, ale v určitých intervalech hesla ji „přimíchat“. Kromě toho lze hash vypočítat cyklicky, přičemž se sůl míchá po částech s určitými změnami [3] , v závislosti na iteračním čísle hašování .
Jeden ze známých standardů PBKDF2 popisuje míchání soli v několika iteracích.
| Uživatelské jméno | Heslo | md5 (heslo) | sůl | heslo + sůl | md5 (heslo+sůl) |
|---|---|---|---|---|---|
| uživatel1 | qwerty123 | 3fc0a7acf087f549ac2b266baf94b8b1 | 5h8Uh32Hhr | qwerty1235hr8Uh32Hr | 1dfa98fc519fc0022e86014445d8b158 |
| uživatel2 | qwerty123 | 3fc0a7acf087f549ac2b266baf94b8b1 | Ju5yFy35Jk | qwerty123Ju5yFy35Jk | 269777fd3b1c37ef1cfc1e238213324f |
Výše uvedená tabulka ukazuje, že stejná uživatelská hesla s různými dynamickými solemi nakonec poskytnou různé hodnoty hash.
Při neoprávněném přístupu k databázi autorizačního systému může útočník z této databáze získat informace potřebné k předání autorizace jménem uživatelů. Pokud jsou hesla uložena v původní (srozumitelné) podobě, může je útočník použít k přístupu k jiným zdrojům, protože uživatelé často používají stejná hesla pro různé webové služby [4] . Použití dynamické soli vám umožní vyhnout se ohrožení uživatelských účtů na několika webových službách najednou.
Se špatně promyšleným systémem používání soli se její výhody ztrácejí:
Malá délka soli a nízká entropie
Pokud je sůl krátká, bude pro útočníka snadné vytvořit duhovou tabulku sestávající ze všech možných solí určité délky, přidaných ke každému možnému heslu. Použití soli s nízkou entropií také zvýší šanci na úspěšné nalezení soli ve slovníku, takže hodnota soli by měla být v ideálním případě generována pomocí RNG [5] . Použití dlouhé soli s dobrou entropií zajistí, že tabulka rainbow pro databázi bude příliš velká a bude vyžadovat značné zdroje útočníka pro generování a ukládání [6] .
Opětovné použití soli pro různé prototypy
I když použití statické soli pro stejné předobrazy učiní některé existující duhové tabulky k ničemu, je třeba poznamenat, že pokud je sůl staticky zapsána do zdrojového kódu oblíbeného produktu, může být dříve nebo později extrahována, načež se vytvoří nový Z této soli lze vytvořit duhový stůl. Pokud je sůl generována dynamicky pro každý předobraz jednotlivě, pomocí některých jedinečných parametrů pro každého uživatele, pak se stabilita systému zvyšuje.
Použití jedné pevné soli také znamená, že každý uživatel, který zadá stejné heslo, bude mít stejný hash. To usnadňuje útok na více uživatelů prolomením pouze jednoho z opakovaných hashů [7] .
Abyste pochopili rozdíl mezi prolomením jediného hesla a jeho zadáním, zvažte soubor hesel obsahující stovky uživatelských jmen a hash hesel. Bez soli může útočník vypočítat hash určité hodnoty (například ze slovníku) a poté zkontrolovat, zda se tento hash vyskytuje někde v souboru. Pravděpodobnost shody, tedy prolomení jednoho z hesel, se samozřejmě zvyšuje s počtem hesel v souboru. Pokud je použita sůl a navíc je dynamická, to znamená, že má alespoň několik možných hodnot pro jeden hash, pak musí útočník vypočítat hash pro každou možnou dvojici salt a hledané heslo, což dramaticky zvyšuje složitost vyhledávání.
Sůl vám také umožňuje čelit používání hashovacích tabulek k prolomení hesel. V případě uživatelských hesel je hashovací tabulka sbírkou předem vypočítaných hashů pro často používaná hesla. V případě souboru neslaných hesel by útočník mohl projít každou položku a najít odpovídající hashované heslo v tabulce hash. Vzhledem k tomu, že vyhledávání je mnohem rychlejší než výpočet hash, značně to urychlí proces prolamování hesel. Pokud je však soubor s hesly vytvořen se solí, pak hashovací tabulka musí obsahovat předem hašované hodnoty se solí. Pokud je sůl dostatečně dlouhá a má vysokou entropii (je náhodná), pak se pravděpodobnost rozbití drasticky sníží. Neslaná hesla zvolená lidmi jsou obecně zranitelná vůči slovníkovým útokům, protože jsou obvykle volena tak, aby byla krátká a dostatečně snadno zapamatovatelná. I malý slovník (nebo jeho hashovaný ekvivalent, hash tabulka) je skvělým pomocníkem při prolamování nejčastěji používaných hesel.
Z technického hlediska sůl chrání před hashovacími tabulkami a duhovými tabulkami, protože v podstatě prodlužuje délku a potenciálně složitost hesla . Pokud v duhových tabulkách nejsou žádná hesla, která by odpovídala délce (např. 8bajtové heslo a 12bajtové salt, což je v podstatě 20bajtové heslo) a složitosti (složitá sůl s vysokou entropií zvyšuje složitost jednoduchých silných alfanumerických hesel) solených heslo , heslo nebude nalezeno.
Moderní systém stínových hesel , ve kterém jsou hash hesel a další bezpečnostní data uložena v neveřejném souboru, částečně řeší problém neoprávněného přístupu k souboru hash. Zároveň zůstávají relevantní v instalacích na více serverech, které používají centralizované systémy správy hesel k přenosu hesel nebo hash hesel do více systémů [8] .
Salt také extrémně zpomaluje slovníkové útoky a útoky hrubou silou pro prolomení velkého počtu hesel (ale ne v případě prolomení pouze jednoho hesla). Bez soli je útočník, který prolomí velkou sadu hesel, nucen pokaždé porovnávat se všemi kandidáty. Vzhledem k tomu, že sůl může být dynamická, pak by se každá možnost soli měla pokusit aplikovat na každé heslo ze seznamu.
Další výhodou salt je, že dva uživatelé si mohou zvolit stejný řetězec jako své heslo nebo stejný uživatel může používat stejné heslo na dvou počítačích. Bez soli bude toto heslo uloženo jako stejný hash řetězec v souboru s hesly. To by odhalilo skutečnost, že oba účty mají stejné heslo, což umožňuje každému, kdo zná jedno z hesel účtu, přístup k druhému účtu. Když je sůl přimíchána, i když dva účty používají stejné heslo, nikdo to nemůže zjistit pouhým pohledem na hodnoty hash.
Většina systémů UNIX používá systémovou knihovnu crypt(3) jako jednosměrnou funkci . Zpočátku tato knihovna používala hashovací funkci založenou na algoritmu DES . V tomto případě bylo heslo omezeno na 8 znaků (7 bitů na znak, tedy 56 bitů) a byla použita 12bitová sůl [9] .
V roce 1994 Poul-Henning Kamp vytvořil nový algoritmus hašování hesel založený na MD5 , který umožňoval hesla libovolné délky a používal tisíc iterací MD5 [10] [11] . Výsledkem funkce byl řetězec obsahující označení hashovacího algoritmu (verze), salt a hash.
V té době byla prodleva při výpočtu takového hashe dostatečná k tomu, aby účinně odolala hádání hesla hrubou silou. S rostoucím výpočetním výkonem se však dramaticky zkrátil čas na nalezení MD5. To vedlo ke vzniku výpočetně složitějších algoritmů v kryptě a kontrole nad počtem iterací [12] .
Knihovna nyní podporuje několik hashovacích funkcí založených na algoritmech: MD5 , SHA-256 , SHA-512 , Blowfish (v některých distribucích Linuxu , OpenBSD a některých dalších systémech podobných UNIXu) [13] . Výsledkem funkce je řetězec obsahující označení hashovacího algoritmu, salt, hash a další data (například počet kol hashovací funkce).
V roce 2012 Poul-Henning Kamp vyzval k úplnému opuštění jím vytvořeného algoritmu md5crypt, protože v moderních podmínkách neposkytuje hmatatelné prodloužení doby výpočtu hash, a proto nechrání před vyčerpávajícím výčtem [14] .