Názory k článku Hash kódy bez tajností, nejen LinkedIn a ti další
-
Ondřej Bouda (neregistrovaný)
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šší...
-
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.
-
"Tomu se dá snadno zabránit takzvaným solením, při němž se otisky počítají z hesel doplněných o nějakou další hodnotu (sůl), takže i když dva uživatelé budou mít stejné heslo, odpovídající otisky budou odlišné."
Ano, ale jen v případě nekonstantní soli, jinak samozřejmě heslo1 == heslo2 => hash(heslo1.salt) == hash(heslo2.salt).
"Zbývá ještě zmínit bezkoliznost, která zajišťuje, že pro různé vstupy budou vypočítány různé otisky (i drobné změně vstupu by měly odpovídat velké změny výsledného otisku)."
A tady jste smíchal bezkoliznost s jednosměrností.
Nechci být drzý, ale od odborníka na počítačovou bezpečnost bych čekal přesnější vyjadřování.
-
Třeba v případě přihlašování HTTP DIGEST je sůl konstantní, protože je jí identifikace serveru.
Výhoda rainbow tables je v tom, že už jsou předpočítané. Když je bude muset útočník počítat znova i pro konstantní sůl, reálně je může spočítat jen pro malou množinu hesel, tedy pro slabá a často se opakující hesla.
-
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.
-
Waseihou (neregistrovaný)
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...
-
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... -
NN (neregistrovaný)
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).
-
Waseihou (neregistrovaný)
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 hesloZ 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á!
-
Waseihou (neregistrovaný)
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ýší.
-
NN (neregistrovaný)
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.
-
NN (neregistrovaný)
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ť.
-
Pokud si uživatel zvolí o 3 znaky delší heslo, prodlouží tím tenhle typ útoku více než 2×105 násobně. Pokud o 4, bude to prodloužení 107 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.$login.$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. -
NN (neregistrovaný)
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.
-
NN (neregistrovaný)
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.$login.$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. :-)
-
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.
-
"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í"?
-
Waseihou (neregistrovaný)
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.
-
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.
-
NN (neregistrovaný)
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.
-
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.
-
Justas (neregistrovaný)
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. -
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é.
-
_pepak (neregistrovaný)
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...
-
_pepak (neregistrovaný)
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á.
-
Waseihou (neregistrovaný)
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...
-
Waseihou (neregistrovaný)
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+password), 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...
-
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í.
-
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.
-
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ý.
-
Waseihou (neregistrovaný)
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
ČLÁNKY DO MAILU