Existuje běžná mylná představa, že hash a šifrování jsou totéž. Nechtěli. Hash je nevratný. Vezměte si následující příklad:
$ echo-n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb-
Předáme řetězec "Password123" algoritmu MD5 (algo), který provádí matematické operace a vrací generovaný hexadecimálně kódovaný hash. Jediný způsob, jak získat stejnou výstupní hodnotu hash, je vložit algo do původního vstupu. Existují konflikty, ale můžeme o tom mluvit později.
Výstup většiny hash algoritmů je hexadecimálně kódovaný binární řetězec pevné délky. Jiní, jako například tento příklad, používají jako výstup řetězec kódovaný na bázi 64. Všimněte si, že délka je vždy stejná:
{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w =
{SHA} lqdu/Zr6o2dgIER8Up1/7lcUtgw =
{SHA} qYUOwLMlDEuukA5HCT4LR1kQzco =
{SHA} MXZBCpyWJ7TTs1w2kgGJslwNwTg =
{SHA} 2sAPLaUh9Mz0bI + XxKEg7qyABe8=
TL; Dr.
Nechci příliš mluvit o šifrování (protože ty věci jsou pro knihy), ale je důležité umět rozlišovat mezi hash řetězci a šifrovanými řetězci. Šifrování obvykle vyplní řetězec, který splňuje určitou délku před šifrováním. K dešifrování také vyžaduje klíč (nebo heslo). Pokud používáte šifrované heslo, řetězec se mění v závislosti na délce zadaného vstupu. Pokud uvidíte spoustu hesel šifrovaného textu, délka se liší a pravděpodobně pracujete s šifrováním namísto hash. AES-256-CBC Příklad šifrovaného řetězce a přidruženého prostého textu (klíč je "ASDF"):
foobar | U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = foobarfoobar | U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = foobarfoobarfoobar | U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz $ cat šifrované_hesla U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz $ pro i v `cat encrypted_passwords`; do echo $i | openssl enc -base64 -d -aes-256-cbc -pass pass:asdf; Ozvěna; hotovo foobar foobarfoobar foobarfoobarfoobar
Teď si možná myslíte: možná máte pravdu. Nicméně, že klíčový materiál musí být přístupný systému, znamená, že v podstatě hlavní heslo s prostým textem je někde umístěno-ať už jako klíč RSA nebo heslo nebo heslo v souboru, vložené do databáze, pevně zakódované v aplikaci nebo heslo někde v paměti. pfft, nikdo nepoužije asdf jako klíč k šifrování hesel svých uživatelů '
Použijte stejný řetězec pro MD5:
foobar | 3858f62230ac3c915f300c664312c63f foobarfoobar | 59faa421729e846dd800dce59943bfc0 foobarfoobarfoobar | 1352aadab322d1a033c27964be0965db
Hashové heslo není zdaleka dokonalé, ve skutečnosti je to trochu špatné, ale je to horší než šifrování kvůli tomu, co se snaží dosáhnout. Uživatelé vybírají absolutní minimální požadavek častěji než not a mohou jej používat na více stránkách. Mnoho "hacků" není ve skutečnosti nic jiného než útoky na opětovné použití pověření. Pokud je původním kompromisem použití šifrování, pak jediné úsilí, které musí útočník vynaložit, je najít klíč, který dešifruje všechna hesla. U hashů musejí vynaložit alespoň úsilí, aby je prolomili. Při použití s moderními algoritmy, jako je sha512crypt, bcrypt, scrypt nebo argon2, může hashové hodnoty vyžadovat velké úsilí k prolomení.
Přidání soli je přidání řetězce k heslu před hash. Sůl každého hash by měla být jedinečná a obvykle náhodně vybrána, protože je důležité, aby stejný jasný text "heslo" hash hodnota měla pokaždé jinou hodnotu. To ztěžuje život prolomitelům hesel, protože aby mohli kontrolovat slovo "heslo" pro každého z 1000 uživatelů, každý má jedinečnou sůl, musí to dělat tisíckrát-jednou na uživatele/sůl. To také znamená, že nemohou efektivně používat předkompilované slovníky nebo duhové tabulky (obvykle...), protože potřebují vlastní jednotku.
Webové stránky to někdy pokazí a používají univerzální sůl pro všechny uživatele; To je v rozporu s účelem.
Následující je SHA1 hash s přidanou solí:
b353977827f67a4ae0318f3a9447fae1c13d9d90:b8d18ca |___________________________________________| hash | sůl | separátor
Jednoduchý text tohoto hash je "heslo". Jeho hodnota soli je "b8d18ca" a používá SHA1 ($salt.$pass) v API. To znamená, že algoritmus získá prostý text hesla, vygeneruje sůl a přidá ji před prostý text. Když se web nebo aplikace pokusí ověřit vaše heslo v budoucnu, vezme vaše heslo v prostém textu jako vstup, přečte hodnotu salt v uloženém Hash, přidejte ji před zvoleným heslem a porovnejte vygenerovanou hodnotu Hash s uloženou hodnotou Hash. Pokud nevíte, že jeho část je sůl, hash vytvoří následující prostý text:
b8d18capassword
Vzhledem k tomu, že algoritmus zadává prostý text, sůl a generované hodnoty hash mohou zůstat pro uživatele transparentní. Při crackingu, pokud je algoritmus slaný, potřebujeme znát slaný, abychom jej mohli poskytnout při generování kandidátského prostého textu. Pokud se provádí správně, solení může způsobit, že praskání bude časově náročnější. Pomocí náhodné soli přinutíte Cracker ztrácet čas pokusem o rozbití hashů, které sůl neodpovídají. To zhruba dokončuje úsilí potřebné pro device_speed/number_of_salts, protože potřebujeme vygenerovat kandidáta pro každou sůl. Pokud je sůl statická, matematické operace jsou stejné... speed_of_device/1. Jiný způsob, jak vidět toto:
Naše GTX 980 cracks SHA1 ($salt.$pass) na 3576,8 MH/s nebo 3,5 miliardy kandidátů za sekundu Náš hashlist obsahuje 1000 jedinečných solí 3 500 000 000 / 1000 = 3 500 000 kandidátů za sekundu
To je o tři řády pomalejší, ztráta 99,9%. Při použití statické soli to vypadá takto:
Naše GTX 980 cracks SHA1 ($salt.$pass) na 3576,8 MH/s nebo 3,5 miliardy kandidátů za sekundu Náš hashlist obsahuje 1 unikátní sůl 3 500 000 000 / 1 = 3 500 000 000 kandidáti za sekundu
Pokud to nedává smysl, čtěte dál, budeme mít krásný graf později...
Dalším běžným vylepšením oproti jednoduše „hash this plaintext "je, že „hash this plaintext, pak hash ten výsledek, pak hash ten výsledek" se opakuje tisíckrát. Tímto způsobem je možné pokusit se o jedno kandidátské heslo, které musí provést tisíckrát. Toto se nazývá iterace, smyčka nebo variabilní náklady. Některé algoritmy hash hesel používají tvrdě zakódovaná iterační kola; Ostatní Git. Udělejte jej konfigurovatelným v části samotného Hash. Například md5crypt () používá MD5, včetně salt, a cyklizuje přesně 1000 krát. sha512crypt () používá sha512, zahrnuje sůl a cyklí konfigurovatelný počet krát (výchozí nastavení je 5 000).
Iterace ovlivňují především náklady na výpočetní cyklus hashovacího algoritmu, nikoli jeho využití paměti nebo jiné faktory. Tyto jsou také důležité útoky při navrhování optimalizované pro odolnost vůči určitým typům hash typů, ale to je příliš plevel, aby se zde diskutovalo.
Pojďme se podívat na několik příkladů, které demonstrují vliv volby hash algoritmu, ať už je to salted, použití více iterací atd. Předpokládejme, že útočník shromáždil 1000 hash uživatelů z nějakého infikovaného webu a chtěl jen provést jednoduchý útok a otestovat každé heslo hash-143 milionů kandidátských hesel.
Typ hash používaný infikovanými webovými stránkami bude mít obrovský vliv na dobu potřebnou k tomu, aby útočník projel útokem. Tady je (relativní, zhruba) graf, kolik sekund trvá, aby se tento útok dokončil, v závislosti na použitém typu hashu, kde standardní grafická karta:
No, to je zbytečné! Nejsilnější hash typy jsou mnohem pomalejší, ale rychlejší typy jsou prostě rozdrceny na nic. Zkusme stejnou velikost dat znovu pomocí logaritmického času osy X. Když se pruhy pohybují zleva doprava, zvýší se o sílu 10:
Takže některé hlavní body jsou: Jedno kolo je jednodušší než vícenásobné kolo a bez soli než s přidáním soli, když chcete prolomit nějaké hash hesla. Naopak, když některá společnost nebo webová stránka oznámí porušení dat obsahující data uživatele, a) je nejlepší, aby heslo bylo hash, nejen prostý text; b) jsou nejlépe solené, ne jen hash; c) Je lepší, aby měli silné vícenásobné kolo soleného hash, které používají celou dobu, ne jen jedno kolo.
Než se pokusí prolomit daný hash hesla, je na cracker, aby zjistil, jaký hash algoritmus byl použit k jeho implementaci. Identifikace typu hash je obvykle jednoduchá, ale ne vždy. Crackery často dělají informované odhady na základě vodítek, jako je délka hash a formát. V konečném důsledku, jediný způsob, jak si být jisti, že odhad typu hash je správný, je, zda je hash prolomen. Některé vynikající zdroje pro tento úkol jsou k dispozici zde a zde a všechny ukazují, jak vypadají běžné hodnoty hash.
V Kali Linuxu je k dispozici balíček "hash-identifier" (k dispozici zde), který pomáhá identifikovat neznámé typy hash.
Kolize dochází, když dva různé vstupy vedou ke stejnému hash výstupu. Je to špatné (samozřejmě). Pokud jde o heslo, to může znamenat, že jsem pravděpodobně neprolomil vaše skutečné heslo, ale protože jsem našel vstup, který produkuje stejnou hodnotu hash, mohu použít prostou textovou hodnotu, abych oklamal systém, aby si myslel, že heslo je legitimní.
Microsoft Office používá v ochraně dokumentů algoritmus, který byl po léta náchylný ke konfliktům. Není neobvyklé nalézt více konfliktů pro jeden hash, které všechny odemknou dokument. Jakmile je zjištěn konflikt, algoritmus je prakticky narušen. Pokud se to stane jednou, je statisticky pravděpodobné, že se to stane znovu. Jediné, co nám překáží, je čas a schopnost zpracování. Vzhledem k tomu, že se algoritmy stávají robustnějšími, generování kandidátských algoritmů a porovnávání hash výstupů pro jejich vyhledávání vyžaduje více schopností a času. V důsledku toho jsou návrháři stále lepší při vytváření algoritmů, které jsou méně náchylné ke konfliktům.