Názory k článku Hash kódy bez tajností, nejen LinkedIn a ti další

Vtip je v tom, že když hledám někoho, kdo má narozeniny ve stejný den jako já, tak mám jasně dané datum. Pravděpodobnost, že někdo narodil v konkrétně daném dni, je 1:365.

V tom druhém případě ale nemám datum fixnuté, a proto je pravděpodobnost úspěchu mnohem vyšší. Je to stejný rozdíl, jako když budete snažit hodit kostkou dvakrát za sebou šestku (fixní výsledek) versus hodit dvakrát za sebou "stejné číslo".

Ty situace má smysl rozlišovat např. proto, že hash se často používá k ověření pravosti dokumentů (elektronický podpis). Když mi někdo pošle podepsaný dokument a já ho potom chci pozměnit/zfalšovat, jsem v té "fixní" situaci: jedna verze dokumentu (a její hash) je pevně daná.

Na druhou stranu, když dokument vytvářím a chci někoho podvést, jsem v té příznivější situaci: snažím se vytvořit dva dokumenty, které se obsahem budou lišit (v můj prospěch) a přitom budou mít stejný otisk (jiného otisku dosáhnou změnou nevýznamotvorných prvků: vkládáním mezer, změnou formátování apod.). Příklad: vytvářím smlouvu o půjčce, od dlužníka si nechám elektronicky podepsat verzi s úrokem 5%, ale současně si vygeneruju verzi s úrokem 20% a obrovským penále (se stejným hashem - a tu pak předložím soudu). Oproti "fixní" variantě mám výhodu v tom, že můžu podle potřeby měnit obsah *obou* verzí.

Takže v té první (fixní) situaci vygeneruju 200 různě změněných dokumentů, ale šance, že se trefím do potřebného hashe, je velmi malá.

V té druhé situaci vygeneruju 100 verzí od každého ze znění (tedy taky celkem 200 dokumentů) a přitom šance, že dva z těch dokumentů budou mít stejný otisk, je řádově vyšší...

Je to tak, pavděpodobnost že vyhrajete ve sportce je malá, ale pravděpodobnost že někdo vyhraje ve sportce je docela velká.

Bohužel s vámi nemůžu souhlasit. I když data jsou posílány nezabezpečeně, je zde jeden zásadní rozdíl - server uchovává hesla a osobní údaje velkého množství uživatelů, takže pokud se k nim někdo dostane tak je to daleko větší problém než když někdo odposlechne jednoho konrétního uživatele. Předpokládejme že velká část uživatelů používá stejné heslo do více služeb, třeba i internetového bankovnictví, takže pokud k úniku dojde tak je to fakt průser. Navíc když už pak k úniku opravdu dojde a je to takto zabezpečené, tak to není taková ostuda...

Tak prosím vysvetli naivnému programátorovi, v čom je tento algoritmus http://pastebin.com/WiS9VvGA nebezpečnejší ako tupé ukladanie hashu a soli do jednej tabuľky.

IMHO: ak útočník získa hash napríklad cez SQL injection, získa z DB rovno aj SALT a nie je nič jednoduchšie ako sha1($pass.$hash). Ak uložím konštantný SALT do súboru, zabránim veľkému percentu útokov vyplývajúcich zo zneužitia SQL injection. Za naivné skôr považujem riešenie typu hash = sha1($pass.$hash).

Miesto sha1($pass.$hash) má byť samozrejme sha1($pass.$salt).

Jenže on server hesla neukládá, jen jejich hashe.

Přihlášení (uživatel zadal svůj login a heslo):

1. podle loginu najdi sůl
2. pomocí soli a hesla vypočítej hash stejným způsobem jako při registraci
3. porovnej vypočtený hash s tím uloženým v databázi (to může dělat třeba oddělený proces a nebo jiná třeba virtuální mašina, v nejhorším skript který který má jako jediný právo číst AES klíč na disku a který vrátí ANO nebo NE)
4. pokud se shodují, autentizace uživatele proběhla úspěšně a je přihlášen, jinak uživatel zadal neplatné jméno nebo heslo

Z toho také vyplývá, že provozovatel internetové služby je ve stejné pozici jako případný hacker - ani pro něj samotného není možné pomocí hashe heslo uživatele získat. Slušný web hesla vůbec neukládá!

Ale samozřejmě že server má možnost hesla ukládat, ale to je potom chyba rovozovatele oné "darebácké" služby. Zákazník by ale měl mít právo očekávat, že internetové služby nabízené komerčně budou mít jistou kvalitu zabezpečení, a obvykle tedy neexistuje důvod aby hesla byla uchovávána, protože ani její provozovatel to nutně nepotřebuje. U některých služeb bych pak očekával že si nechají udělat bezpečnostní audit aby zvýšili svojí důvěryhodnost u zákazníka. Ale obyčejných služeb není nutné aby hesla byla jakkoliv uchovávána a implementace toho co popisuje by neměla mít výrazný dopad na dobu implementace, přitom míra zabezpečení se rapidně zvýší.

Videli ste odkazovaný kód? Idea je v tom, že SALT útočník nepozná, pretože typicky cez SQL injection získa len to, čo je v databáze, t.j. login, hash a dynamický salt, ktorý je v tomto konkrétnom prípade login. Ďalej je idea v tom, že aj keď útočník pozná algoritmus, nepozná konštantný salt definovaný v súbore, ktorý je pre každú inštaláciu rôzny – a práve tu to viacnásobné hashovanie pomôže, pretože útočníkovi znemožní brute force v rozumnom čase a generovanie dúhových tabuliek pre konktérny algoritmus v rozumnom čase.

Myšlienka je tiež v tom, že nejde o jednoduché viacnásobné hashovanie, ale o pridávanie rôznej časti saltu pre každý jednotlivý prechod cyklom. Solí sa teda zakaždým inou časťou soli.

Práveže sa snažím uvažovať z pozície útočníka a myslím si, že toto sa bude lámať ťažšie ako prípad, kedy je síce použitý silný hasnovací algoritmus (napr. bcypt), ale nie je pužitá konštatná soľ ale len soľ v databázovej tabuľke uložená spolu s loginom a výsledným hashom.

Niekde píšem ako dement, pardon, opravujem:

Mám za to, že práve tomto v konkrétnom prípade desaťtisícnásobne predĺži čas, potrebný na prelomenie hrubou silou alebo na vygenerovanie
rainbow tabuliek. A to nie je zanedbateľné.

Prihadzovanie časti saltu alebo použitie celého saltu môže byť rovnaké, s tým súhlasím. Ale aj keď nedokážem spočítať vplyv na výskyt CYKLOV, intuitívne predpokladám, že VÝSKYT CYKLOV bude menší, ak sa bude množina použitých znakov v reťazci pre jednotlivé prechody cyklom meniť.

strlen(SALT)==10 z pohledu reálné bezpečnosti stejně bezpečné jako ten váš příklad

Aha, už mi začína svitať ako to myslíte. :)

Mohli by ste zdôvodniť, v čom je to viacnásobné hashovanie zbytočné, ak ide o lámanie hashov hrubou silou? Mám za to, že práve toto v konkrétnom desaťtisícnásobne prípade predĺži čas, potrebný na prelomenie, prípadne hrubou silou alebo na vygenerovanie
rainbow tabuliek. A to nie je zanedbateľné.

Prihadzovanie časti saltu alebo použitie celého saltu môýe byť rovnaké, s týmsúhlasím. Ale aj keď nedokážem spočítať vplyv na výskyt kolízií, intuitívne predpokladám, že kolízií bude menej ak sa bude množina použitých snakov v reťazci pre jednotlivé prechody cyklom meniť.

To, že útočník musí poznať spoločný SALT, ktorý je uložený v súbore nie je zvýšenie bezpečnosti oproti príkladu, ak je použitý len salt v databáze? Nepresvedčili ste ma a silne pochybujem o Vašich argumentoch. Je rozdiel hacknúť web len cez SQL injection a hacknúť web cez SQL injection a SÚČASNE cez obsah súboru na disku, kde je definovaný spoločný salt pre výpočet hashu.

Konkrétny príklad, kedy viacnásobné hashovanie pomôže:

útočník získa hashe z databázy, získa algoritmus ich tvorby a získa aj spoločný SALT definovaný v súbore. V tomto momente potrebuje útočník prelomiť získanú sadu hashov, aby sa dostal k účtom užívateľov. Može skúsiť slovníkový útok, čo neprelomí slovníkovým útokom, skúsi prelomiť hrubou silou. A práve tu vniká rozdiel v čase, potrebnom na tento úkon. Rozdiel medzi algoritomom sha1(SALT.$lo­gin.$password) a desaťticícnásobným hashovaním bude výrazne lepší v prospech opakovaného hashovania uvedeným algoritmom. To totiž spôsobí desaťtisícnásobné navýšenie času, potrebného na vykonanie útoku hrubou silou, čo môže daný informačný systém prakticky zachrániť.

Ak sa to dá vôbec povedať o systéme, kde je možný vykonať SQL injection a dump zdojového kódu. :-)

Když už vícenásobně hashovat, tak aspoň takhle.

Pod pojmem komerčně jsem měl namysli třeba internetové bankovnictví, tam opravdu očekávám kvalitní zabezpečení celého systému. Co se free služeb týče, u některých z těch uvedených by byla ostuda kdyby to měli zabezpečené jako amatéři, u jiných by mě to bohužel nepřekvapilo. Na druhou stranu nejde o něco extra složitého co by nešlo naimplementovat, myslím že více času se strávilo nad tím kam umístit reklamu místo na zabezpečení, které je jednorázová investice.

Dobře, a jaké je to řešení ať se poučím? Pravděpodobně něco s certifikáty a podobně?

To je síce pekné, ale chcieť od úžívateľa nejakej webovej služby 15 znakové heslo je z pohľadu BFU drzosť. 10k opakovaného hashovania zvládne server za štvrť sekundy. Kde je problém? Nikde. Server to nezrujnuje, no útočníka to odstaví. Navyše ak bude útok vedený na admin heslo nejakej služby, je počet účtov nepodstatný, môže tam byť kludne jeden alebo rádovo jednotky.

Ja si ten hash v db radšej poriadne osolím a opakovane zahashujem s dynamickou soľou meniacou sa pre každý prechod. Pretože existuje scenár, kedy to môže systém zachrániť. Nemusí to byť SQL injection alebo iná diera, ale kľudne únik db a zdrojákov aplikácie z hostingu.

Nesouhlasím. Vzhledem k tomu, že žádná hash funkce není bezkolizní (už ze svého principu), nehledá útočník správné heslo, ale jakékoli heslo dávající pro danou sůl správný hash. S délkou hesla to pak příliš nesouvisí - je-li délka osoleného hesla alespoň stejná jako délka hashe, další prodlužování bezpečnost nezvýší, protože s prodloužením hesla se zvyšuje počet kolizí.
Pak se jako důležitý parametr objevuje čas, za který lze provést jeden pokus.
Z tohoto hlediska přináší delší salt jen větší počet kolizí (pokud je připojen pouhým concatem, lepší je xorování podle principu Vigenerovy šifry) a prodloužení času na jeden pokus, protože tím se prodlužuje čas potřebný pro vytvoření rainbow tabulek.
Souhlasím s tím, že i pro větší počet konkurenčních požadavků musí dát server odpověď v rozumném čase; ale na druhou stranu to lze předpokládat; pokud se budu domnívat, že na můj web se může během jedné minuty přihlásit tisíc lidí, asi budu mít hardware dimenzovaný úměrně tomu, že se tam bude tolik lidí pohybovat. Čili to asi nebude vyřazený notebook.

Ano, tohle je jedna z klasických elementárních chyb naivního programátora. Pomocí Google najdete snadno vysvětlení, proč je tohle nebezpečné...

Ten na konci zmíněný narozeninový paradox je zajímavý, to jsem vůbec netušil. Opravdu to tak funguje?

Ano. V Crypto Class se to v rámci jednoho cvičení demonstruje na úloze, najít kolize pro 50bitový hash - naivně hrubou silou by to bylo pro jednotlivého uživatele poměrně obtížné, pomocí narozeninového paradoxu to je práce na maximálně 10 sekund...

Ovšem, pravděpodobnostně. Pamatujte, mám jen 50% pravděpodobnost. Ale když nenajdu po těch 10 sekundách, tak pokus stopnu a spustím úplně nový, který potrvá zase 10 sekund a zase bude mít 50% pravděpodobnost. Pravděpodobnost, že ani po minutě nebudu mít kolizi, už je dost malá, a po hodině zanedbatelná.

Ale to je přeci známý fakt, že každý uživatel má jinou sůl, takže to ani není nutné zmiňovat ;) Nebo když už se tedy vůbec solí že by se to fakt implementovalo tak že sůl je konstantní a nejlépe v databázi aby si to útočník mohl předpočítat rainbow tables? No minimálně ho to o nějakou dobu pozdrží. A nezapomínejme že žijeme v době SSD a GPU, a taky pozor na SQL injection a některá exotičtější kódování UTF...

Na to je lepší použí PBKDF2 neby bcrypt, nikoliv takovouto prasečinu. A jako minimální řešení pro trochu bezpečnosti je třeba mít pro každého usera jeho vlastní dokonale náhodnou sůl vygenerovanou kryptograficky bezpečným generátorem, třeba blum blum shub. Sůl by měla být alespoň stejně dlouhá jako je výstup hashovací funkce, takže pro SHA-1 160 bitů neboli 20 znaků nebo více. V databázi pak ukládáma hash(salt+pas­sword), salt pro každého usera. Tohle se dá ale stále lámat slovníkovým útokem a burte forcem, dnes se používá i výhod GPU při testování všech možností. Právě proto se má správně použít key stretching, ale ona primitviní metoda ne - musí se použít PBKDF2 nebo brcypt, a důvodem je aby to měl hacker při slovníkovém/brute force útoku složitější. Pravdou je že málokdo to dneska takto implementuje, oni často ani nesolí, natož aby implementovali nějaké standardy...

Jisteze to funguje, ale statisticky! Stejne tak je mozne, ze na pracovisti bude 365 lidi a kazdy bude mit narozeniny v jiny den (pravdepodobnost vyskytu tohoto jevu ovsem bude velmi mala).

Takže účelem key stretchingu je aby tento typ útoku trval tak dlouho, že bude prakticky neproveditelný. Jo a další zlepšovák který jsem opoměl je zašifrovat hashe v databázi pomocí AES, klíč ale nesmí uniknout a rozhodně nesmí být v databázi. Tady se asi hodí TPM modul či jiný dedikovaný hardware. Když není nic lepšího, tak klíč alespoň uložit na disk jako soubor a doufat že se k tomu útočník nedostane, obrana před SQL Injection. Ale i když se toto všechno implementuje správně, stejně to neznamená že se nenajdou nějaká jiná zadní vrátka, třeba v důsledku chyby administrátora :D