Vlákno názorů k článku Hash kódy bez tajností, nejen LinkedIn a ti další od Tany - A kvůli podobným myšlenkám je ročně kdovíkolik služeb...

A kvůli podobným myšlenkám je ročně kdovíkolik služeb kompromitováno únikem už. dat. Existuje spousta způsobů, jak útočníky velmi znepříjemnit práci, ale vyžaduje to ve firmách programátory a ne bastlení zakázek pomocí studentů za pár korun. Eshop u kterého po zadání apostrofu do login formuláře vyskočí SQL chyba .. to by mělo být trestné, nakládají totiž nečekaně s osobními údaji.

Vy to řešíte, jak kdyby tím mělo být zabezpečené odpálení atomové bomby... Když si uvědomíte, jak to vypadá u uživatele -- webový formulář, heslo uložené v prohlížeči a odeslané přes nešifrované spojení -- je to vaše zabezpečení na straně serveru mnohonásobně předimenzované. V současné době myslím bohatě stačí, aby na serveru byly hashe osolené klidně konstantním hashem.

Do té doby, než se standardně bude používat aspoň něco na úrovni HTTP DIGEST a než bude součástí webových protokolů způsob, jak takovéto heslo nastavit a změnit (samozřejmě tak, že se na server odešle už serverově specifický hash a ne heslo v otevřeném tvaru), nemá smysl uvažovat o praktickém nasazení něčeho bezpečnějšího. To, že se hesla zadávají do webových formulářů, odesílají se v otevřeném tvaru, odhlašuje se opět webovým formulářem a mezitím je uživatel autentizován pomocí cookie, nejlépe vypovídá o reálném nezájmu o nějakou bezpečnost v prostředí webu.

Jenže on server hesla neukládá, jen jejich hashe.
To si vy myslíte. Ale zdrojáky jste neviděl. Jistý si můžete být jedině tehdy, když serveru heslo v otevřeném tvaru vůbec nikdy nepošlete -- ani při registraci, ani při autentizaci. Jenže o takové zabezpečení na webu nemá skoro nikdo zájem. Jsou důležitější věci na implementaci -- video, kulaté rámečky...

Pokud si uživatel zvolí o 3 znaky delší heslo, prodlouží tím tenhle typ útoku více než 2×10⁵ násobně. Pokud o 4, bude to prodloužení 10⁷ násobek. To to vícenásobné hashování zase není takový zázrak, že? Navíc to vícenásobné hashování musí zvládnout produkční stroj v rozumném čase a pro spoustu souběžných požadavků, když se chce přihlásit víc uživatelů najednou.

sha1(SALT.$lo­gin.$password)
je i pro strlen(SALT)==10 z pohledu reálné bezpečnosti stejně bezpečné jako ten váš příklad. Akorát nebude programátora mást nesmysly a vyvolávat v něm nepravdivý dojem, že něco tak složitého musí být ultrabezpečné a žádné jiné zabezpečení už není potřeba řešit.

a práve tu to viacnásobné hashovanie pomôže
Nepomůže, je tam úplně zbytečné.

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.
Což je v nejlepším možném případě stejně dobré, jako přidání celé soli k jednomu průchodu hashovací funkcí.

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.
To je právě ten problém, že stavíte jen na vašich dojmech a ne z rozboru algoritmu. Bohužel bezpečnostní algoritmy jsou neintuitivní a to, co vyvolává dojem zvýšení bezpečnosti, je v mnoha případech jen bezcenná hra, v mnoha dalších případech je to dokonce snížení bezpečnosti.

"Nabízené komerčně" -- a jsme u toho. Kolik platíš za Gmail, Youtube, LinkedIn, Lupu, Seznam, Novinky... ?

Já si na webu platím jedinou službu (a štve mě a už to neudělám) -- Piano (SK prstenec webů).

Takže kde mi vzniká morální právo požadovat po provozovatelích služeb zdarma, aby "dělali víc, než ostatní"?

Pro přihlášení třeba HTTP DIGEST. Ovšem chtělo by to k tomu ještě standardizovaný způsob, jak z prohlížeče vytvořit účet. Teď je to možné udělat s pomocí JavaScriptu, ale ten asi bude málokdo kontrolovat, zda opravdu heslo na server neodesílá.

10000× opakování útočníka neodstaví o nic víc, než 1 opakování se solí. Navíc pokud to serveru bude trvat čtvrt sekundy a přihlásí se najednou 1000 uživatelů, budou někteří čekat na přihlášení 4 minuty. Ten scénář, kdy opakované hashování s dynamickou solí může systém zachránit, by mne zajímal. Podle mne neexistuje takový scénář, kde by opakované hashování něco zachránilo, ale jednoduché ne.

Sůl uložená mimo databázi samozřejmě pomůže v případě napadení databáze, když se útočník nikam jinam nedostane. Jenže obrana proti SQL injection je triviální a navíc už je dost velký průšvih i jen to, že se uživatel dostane ke všem ostatním údajům z databáze.

Důležité je ale hlavně to, že když jsou unikátně osolena jednotlivá hesla, musí útočník útočit hrubou silou na každé heslo zvlášť. V takovém případě nejspíš využije jiné údaje z databáze, a nebo pokud chce zaútočit na konkrétní účty, nebude se pokoušet lámat je hrubou silou, ale spíš se pokusí uživateli něco podstrčit, donutit jej ke změně hesla apod.

Jinak pokud má být uložení hesla opravdu důvěryhodné, musí uživatel sůl vidět -- aby si mohl ověřit, že se server nepokouší solit stejnou solí, jako jiný server. Tím pádem padá jakékoli zabezpečení postavené na tom, že sůl je tajná. Z toho je taky vidět, že nejdůležitější je hlavně to, aby měl uživatel silné heslo. Slabé heslo nezachrání seberafinovanější opatření na straně serveru.

Záleží na tom, čemu říkáte „jako amatéři“. Třeba Seznam nebo Google nejspíš hesla ukládají v otevřeném tvaru, protože poskytují mnoho služeb a další přidávají – POP3, IMAP, Jabber… A tyto služby používají různé způsoby autentizace. Takže by provozovatel musel se spuštěním každé nové služby vyžadovat od uživatele znova zadání hesla, aby si mohl uložit ten správný hash. A nebo si prostě hesla od začátku ukládá v otevřeném tvaru.

Jinak je hezké, jak pořád píšete, co by provozovatel měl a že doufáte, že se podle toho chová. To jsou pořád ale jen řeči, úplně stejné, jako když provozovatel tvrdí, že má databázi zabezpečenou a neosolený hash tak není žádný problém. Pokud by šlo skutečně o bezpečnost, nebudeme předpokládat a doufat, ale začneme používat řešení, ve kterých provozovatel heslo v otevřeném tvaru nikdy nedostane.

Problém uhádnutí hesla lze zcela jednoduše vyřešit jednou provždy. Stačí heslo se seedem zahešovat mnohokrát po sobě (např. 1000x). Server to příliš nezatíží (zas tolik lidí heslo v jeden okamžik neověřuje), ale útočníkovi se hádání neúnosně protáhne protože musí provádět základní hashovací operaci 1000xN kde N je počet opakování vedoucí k uhodnutí hesla. Společně se zmíněným seedem, který se nesmí útočník dozvědět, a dobrou hashovací funkcí je to podle mého názoru dosti bezpečné.

Asi reagujete na jiný komentář. Zabezpečení má smysl jedině tehdy, když je konzistentní, tj. nemá smysl řešit šifrování hashů hesel osolených kryptograficky bezpečnou náhodnou solí a vedle mít bezpečnostní díru jak vrata, která útočníkovi vydá všechny osobní údaje (e-maily, telefony atd.), jenom ta hesla nedokáže rozluštit. Lepší je mít hesla obyčejně osolená konstantou, a další energii věnovat tomu, aby se útočník k databázi vůbec nedostal.

Pokud uživatelé používají stejná hesla, nebudou mít problém jenom v případě napadení nějaké služby. Kde má uživatel zaručeno, že se nepokusí jeho heslo zneužít i provozovatel nějaké služby, že nebude hesla do bankovnictví zkoušet třeba majitel nějakého chatu? Kdyby heslo nikdy neopustilo prohlížeč a při jeho vytváření a ověřování se na cílový web posílal jenom hash, měl by uživatel mnohem větší jistotu. Vždyť co nám teď vadí? Že víme, že LinkedIn ukládat neosolený hash. Když nějaký web ukládá hesla v otevřeném tvaru a nikdo to neví, jsou všichni spokojení a užívají si (iluzi) bezpečí.

Jinak právě proto, že server neukládá jen hesla, ale také osobní údaje, bych hesla ukládal hlavně osolená, a další energii bych nevěnoval šifrování, ale zabezpečení toho, aby se k datům pokud možno nikdo nepovolaný nedostal. Únik e-mailových adres a případných dalších osobních údajů bych vnímal jako horší problém, než to, že budou všechna hesla na serveru osolená stejnou solí.

Uvědomte si, co hash dělá. Mapuje libovolný vstup do omezené množiny výstupu. Když stejnou hashovací funkci zopakujete na tento výstup, aplikujete hash na omezenou množinu vstupu, výstup bude množina maximálně stejně velká, jako vstupní množina. Při opakovaném aplikování stejné hashovací funkce tedy počet hashů na výstupu bude konvergovat k nějakému omezenému počtu prvků, teoreticky až k jednomu hashi. Pokud byste takhle dokonvergoval k jednomu hashi, vyhoví mu jakékoli heslo, pokud by jich na výstupu bylo třeba 50, můžete heslo náhodně tipovat a v průměru vám každé 50 náhodně zvolené heslo projde. To asi nebude nejlepší způsob zabezpečení.

I kdybyste použil špatně navrženou hashovací funkci, která by pro hashování vlastních hashů generovala minimum kolizí, opakované hashování přináší málo užitku. Vžijte se do role útočníka, který zná heslo v otevřeném tvaru a hash, a předpokládá, že jste použil sůl a/nebo opakované hashování. Pokud použijete dvouznakovou sůl složenou z velkých a malých písmen a číslic, bude muset útočník vyzkoušet přes tři a půl tisíce kombinací, než sůl odhalí. Když použijete opakované hashování 1000×, odhalí to po 1001 pokusech. Nebo-li stačí prodloužit sůl o dva znaky a hashovat jednou, a získáte tak lepší bezpečnost, než při tisícinásobném hashování.

Takže naivní je vícenásobné hashování, naivní je také prodlužování soli na desítky znaků. Jinak podstatná nevýhoda neosolených hashů je to, že pro ně existují už hotové duhové tabulky. Když použijete sůl a i když ji útočník bude znát, musí si tabulky generovat znovu, takže reálně získá jen ta nejjednodušší hesla, pro která bude moci tabulky vygenerovat.

Pokud tedy použijete desetiznakovou proměnlivou sůl a jednonásobné hashování, je to pro zabezpečení hesel hashování dostatečné a prodlužování soli nebo opakované hashování neznamená žádné reálné zvýšení bezpečnosti. Ušetřený čas a peníze pak můžete věnovat třeba nahrazení dávno zastaralého přístupu k SQL databázi novějším (starým jenom asi 15 let), který je proti SQL injection odolný.