Změna hashování existujících hesel

Používáte pro ukládání uživatelských hesel funkce jako MD5 nebo SHA-1 a chtěli byste to změnit na třeba bcrypt? A chcete to udělat pořádně, aby byla chráněna všechna hesla ve vaší databázi? Michal Špaček v článku Změna hashování existujících hesel na svých stránkách ukazuje, jak to udělat.

6.9.2017 10:22 | Ladislav Hagara | Zajímavý článek

Komentáře

[Filip Jirsák]

Trochu bych to upravil – Michal Špaček uvádí tři příklady, jak to lze udělat, a následně podrobněji probírá ten třetí, nejhorší způsob, kterým by se to rozhodně dělat nemělo.

[saly]

nejhorší způsob, kterým by se to rozhodně dělat nemělo.

Čím to můžete podložit?

[Filip Jirsák]

Je tam (potenciálně navěky) zafixovaná ta slabá hashovací funkce, které jsme se chtěli zbavit.

[chrono]

Nemá tento problém tá druhá verzia zo zoznamu?

[chrono]

S tým stĺpcom pre aktuálny typ kontrolného súčtu je to v podstate stále tá 2. možnosť. Navyše typ použitého kontrolného súčtu môže prezradiť napr. aj dátum posledného prihlásenia. Každopádne si stále nemyslím, že je 3. možnosť najhoršia (oproti 2. verzii ale asi nemá žiadnu výhodu).

[Filip Jirsák]

Ta třetí možnost vyvolává dojem, že se používá novější hashovací algoritmus, přitom se stále používá ten starý, který byl označen za slabý. Ale fakticky je to opravdu totéž, rozdíl je jenom v tom, že ta třetí varianta dělá dojem něčeho lepšího. Je pravda, že ještě mohla být zmíněna čtvrtá varianta, která by byla ještě horší než 2 nebo 3 – nepamatovat si použitý algoritmus a vše hashovat nejprve slabou funkcí a pak silnou, a tím tu slabou funkci zakonzervovat v aplikaci opravdu na věky. Toomu se naštěstí zápisek vyhnul.

[Michal Špaček]

Rozdíl mezi způsobem 2) a 3) je popsán v článku.

Řečí čísel, pokud unikne databáze "upravená" metodou

• 2), tak hesla "neaktivních" uživatelů půjde crackovat rychlostí starého hashe (pro MD5 je to 30 miliard pokusů/s na GTX 1080 Ti)
• 3), tak hesla "neaktivních" uživatelů půjde crackovat rychlostí nového hashe (pro bcrypt cost=10 je to 650 pokusů/s na GTX 1080 Ti)

Rozdíl tedy je 8 řádů v rychlosti crackování hesel uživatelů, kteří se od vylepšení hashování nepřihlásili.

[Michal Špaček]

Nový hash ze starého se po přihlášení nahradí jen tím novým, čistým, v článku je to popsáno o trochu dále. Doplním to ještě k bodu tři, aby to bylo jasné i bez přečtení celého článku, evidentně to tam chybí. Jak byste to bez otravování uživatelů udělal lépe, prosím?

[Filip Jirsák]

Ano, to je ta lepší varianta, z hlediska bezpečnosti je to pak zhruba stejné, jako druhá varianta. V článku by to mělo být opravdu napsané hned při první zmínce o této variantě, protože jsou experti, kteří zcela vážně navrhují tam tu slabou hashovací funkci nechat navěky a používat ji i u nových hesel (aby se nemuseli v databázi pamatovat, která hashovací funkce je použitá).

Jak bych to udělal lépe? Předně bych tomu požadavku „bez otravování uživatelů“ snížil důležitost, protože bezpečnost někdy bez otravování uživatelů nejde (pro ostatní dodávám, že to ale neznamená, že čím otravnější, tím bezpečnější – jak si bohužel spousta lidí myslí).

Nejprve je potřeba si říct, proč tu výměnu za silnější hashovací funkci vůbec dělám. Napadají mne dvě možnosti – jedna je, že daná hashovací funkce už je zastaralá a má známé slabiny (které ji ale nemusí oslabovat při použití pro hashování hesel), takže se postupně obecně opouští a dá se předpokládat, že postupně bude její implementace mizet z knihoven, nebude jí věnována taková pozornost a mohou v ní být slabiny, o kterých se ani nedozvím. V takovém stavu je dnes MD5 a na začátku takového stavu i SHA-1. V tomhle případě ale není kam spěchat, opouštění té funkce bude trvat léta, takže ničemu nevadí mít jí ještě léta zahashované málo používané nebo nepoužívané účty. Pokud se někdo nepřihlásí několik let, heslo bych mu pak klidně resetoval – nejpravděpodobnější je, že je to nějaký zapomenutý účet a dotyčný se už nepřihlásí nikdy. A pokud by si náhodou někdo po letech vzpomněl, že nějaký takový účet zná, je dost pravděpodobné, že už si stejně nepamatuje heslo. Pokud ten reset udělám tak, že nebudu zasílat žádné e-maily, ale až v okamžiku přihlášení ověřím, zda heslo nebylo resetováno, a pokud ano, informuji o tom uživatele a rovnou pošlu e-mail ke změně, je to podle mne minimální otravování minima uživatelů a je to snesitelné.

Druhý závažnější důvod pro změnu hashovací funkce je ten, že chci lépe chránit uživatele, kteří používají stejná hesla na více místech (chránit by je před tím měl prohlížeč, případně to může dělat uživatel sám použitím správce hesel, ale vím, že se to neděje, tak se pokusím udělat alespoň co je v mých možnostech). V tomto případě se tedy snažím bránit útoku hrubou silou na hashe. Problémem jsou tedy hesla hashovaná bez soli, která lze hromadně „lámat“ pomocí duhových tabulek, další problém je případ, kdy je hash sice osolený, ale sůl je útočníkovi známá (i pokud je náhodná pro každé heslo, umožní to případnému útočníkovi lámat alespoň hesla nějakých zajímavých účtů). V obou případech moc nezáleží na hashovací funkci. Zároveň je spousta úniků hesel, kdy dojde jenom k úniku dat z databáze (např. útočník získá nějakou starší zálohu), takže má smysl řešit i tenhle speciální případ, kdy útočník nezíská přístup i k aplikaci. Řešením je samozřejmě osolit (nebo chcete-li opepřit) heslo před hashováním ještě něčím, co je uložené zcela mimo databázi, např. někde v konfiguraci aplikace.

V tomhle druhém případě má smysl to řešit hned, protože pokud mám v databázi nesolené hashe hesel, v případě úniku dat útočník pravděpodobně prolomí spoustu hesel. A pokud za dva roky unikne dnešní záloha databáze, bude mi houby platné, že za rok hesla přehashuju nebo resetuju. Když ale dělám tohle opatření proti útoku hrubou silou na uniklé hashe, začnu tím nejdůležitějším, což je právě použití pepře (nechápu, proč od toho naopak odrazujete – z kryptografického hlediska je použití pepře mnohem bezpečnější, než hashování hashů, kam spadá i opakované hashování).

Takže pokud mám v databázi nesolené hashe a chci se pro případný únik dat pojistit pořádně, bral bych dočasné zahashování hashů jako použitelné řešení, ale s tím, že udělám opravdu maximum pro minimalizaci případných škod, takže použiju i pepř. A samozřejmě bych si stanovil nějaký časový horizont, do kdy mají uživatelé „šanci“ se přihlásit a přejít tak na novou hashovací funkci, a po tomto termínu se hesla zresetují.

A taky bych si měl uvědomit, že když teď mám problém s přechodem na novou hashovací funkci, budu nejspíš za pár let řešit to samé. Takže by se hodilo mít za těch pár let k dispozici hesla uživatelů v otevřeném tvaru (když už mi je uživatelé tak rádi posílají). Takže když už mi uživatel pošle své heslo a já si ho do databáze ukládám zahashované novým hashem pro ověřování, uložil bych si ho také zašifrované asymetrickou šifrou pro budoucí přehashování (privátní klíč od té šifry může být uložen bezpečně offline klidně rozdělený na několik částí).

[.]

Prostě zase nevíš, o čem je řeč. :D

[Michal Špaček]

Filipe, díky za komentář, jen škoda, že jste neodpověděl na mou otázku. Ale máte naprostou pravdu, zmínka o hashování do čistého "heslového" hashe by měla v článku být dříve, napravím. Nějak jsem nepočítal s tím, že by se k textu vyjadřoval někdo, kdo ho nepřečetl, omlouvám se a děkuji.

Jinak obor hashování a ukládání hesel i jejich crackování udělal za posledních cca 10 let docela pokrok: GPGPU, CUDA, scrypt, Argon2 a další. Prostudujte si prosím například tyto materiály, najdete v nich potvrzení resp. vyvrácení snad všech Vašich domněnek:

• konference Passwords, záznamy přednášek najdete na YouTube u pořadatele Pera Thorsheima
• track Ground1234! z BSides Las Vegas 2017, opět na YouTube a také na Redditu (tam naleznete i odkaz na předchozí ročník)
• seznam "paperů" věnujících se autentizaci, tedy i heslům, sestavuje ho Bruce Marshall, autor předchozího postu

Po prostudování zcela jistě pochopíte, proč se věci dělají jinak než píšete. Do té doby prosím nenavrhujte úložiště hesel, které bude moci používat i široká veřejnost. Děkuji.

[Filip Jirsák]

Filipe, díky za komentář, jen škoda, že jste neodpověděl na mou otázku

Jestli se nemýlím, otázka zněla: „Jak byste to bez otravování uživatelů udělal lépe, prosím?“ Moje odpověď měla několik částí:

1. „Bez otravování uživatelů“ reprezentuje váš názor, se kterým nesouhlasím, proto odpovím na obecnější otázku „Jak bych to udělal lépe“.
2. Použil bych „pepř“, který zvyšuje bezpečnost zásadně, na rozdíl od „pomalých“ hashovacích funkcí nebo rychlých paralelních výpočtů, které mění výpočetní složitost pouze o několik málo řádů.
3. Při přehashování přes starou funkci bych si stanovil termín, po kterém se staré hashe resetují.
4. Uvědomil bych si, že to, co řeším teď, budu za pár let řešit znova, takže bych se na to připravil.

[Michal Špaček]

Děkuji za dovysvětlení, dovolte mi jen pár poznámek:

„Bez otravování uživatelů“ reprezentuje váš názor, se kterým nesouhlasím, proto odpovím na obecnější otázku „Jak bych to udělal lépe“.

"Bez otravování uživatelů" není můj názor, je to požadavek. Bezpečnost jde ruku v ruce s použitelností, slovy Aviho Douglena: Bezpečnost na úkor použitelnosti jde na úkor bezpečnosti. Nelze zbytečně zatěžovat uživatele pokud to není vysloveně nutné. A při změně hashování to potřeba opravdu není.

Použil bych „pepř“, který zvyšuje bezpečnost zásadně,

Můžete mě prosím odkázat na nějaký reálný výzkum, který by Vaši domněnku potvrdil? Všimněte si prosím, že žádné funkce na hashování hesel "pepř" nepodporují. Pokud "pepř", tedy nějaký globální statický řetězec, přimícháte před hashováním, tak můžete poškodit původní algoritmus, protože ho změníte. Jako příklad snad postačí použití "pepře" v PrestaShopu, ve kterém díky tomu byla všechna hesla uměle zkrácena na 16 znaků.

Také by bylo dobré zmínit, že "pepř" nepoužívá ani třeba Facebook, ani Dropbox, ačkoliv ten tvrdí že ano, ale jen "pepřem" nazývá šifrovací klíč, což skutečně není "pepř".

Navíc v realistickém modelu hrozeb by měla být možnost použití útoku SQL Injection k získání obsahu např. konfiguračních souborů, tedy i onoho "pepře". Tím se sníží bezpečnost takového řešení jena na "hash a případná sůl" a závisí tedy opět na použitém hashi. Bylo by tedy nutné použít nějaké HSM, nicméně pořád zůstává problém změněného algoritmu. V článku píšu, že pro dosažení podobného efektu se dá použít šifrování hashů, používají se tedy pouze algoritmy, které k daným účelům byly navržené.

na rozdíl od „pomalých“ hashovacích funkcí nebo rychlých paralelních výpočtů, které mění výpočetní složitost pouze o několik málo řádů.

Mezi použitím nevhodných hashů (např. MD5) a hashů pro ukládání hesel (např. bcrypt s cost=10) je rozdíl 8 řádů, při použití vyššího costu i více. Může se to zdát málo, ale převedeno na čísla to znamená, že jde o generování kandidátů rychlostí 30 miliard pokusů za vteřinu vs. 650 pokusů za vteřinu. V praxi to znamená, že z dat Ashley Madison (bcrypt cost=12) šlo za 5 dní cracknout jen 4000 velmi předvídatelných hesel. Po objevení dalších hashů, což bylo několik různých variant MD5, které by se daly zjednodušeně popsat jako "MD5 se solí" a "MD5 se solí a pepřem" bylo cracknuto 2,6 milionu hesel za pár hodin a 11,2 milionu hesel za 10 dní.

Při přehashování přes starou funkci bych si stanovil termín, po kterém se staré hashe resetují.

Je to samozřejmě možnost, je lepší hesla nemít než mít Ale v realistickém modelu hrozeb to není potřeba dělat.

Uvědomil bych si, že to, co řeším teď, budu za pár let řešit znova, takže bych se na to připravil.

Velmi pravděpodobně to za pár let dělat nebudete. Problémem je, pokud vývojáři používají hashovací funkce, které nejsou určené k ukládání hesel, tedy např. SHA-1 a MD5, pak je potřeba takováhle spartakiáda s přehashováváním. Když se používají doporučené funkce, tak stačí transparentně po přihlášení přehashovávat, hesla jsou stále dobře chráněna i při použití třeba onoho bcryptu s costem 10. Pokud byste přidal asymetrické šifrování hesel, tak do systému přidáte nutnost bezpečného úložiště, správy klíčů a přidáte proces na správu hesel v čitelné podobě, čímž velmi pravděpodobně bezpečnost hesel ve finále snížíte. Toto by bylo možné provést maximálně ve velkých organizacích, které tyto procesy dokáží zaručit, ale ve ani ty nemají důvod k uchovávání hesel v zašifrované podobě.

Tohle jsou důvody, proč jste nejenže neodpověděl na mou otázku "Jak byste to bez otravování uživatelů udělal lépe, prosím?", ale neodpověděl jste ani na otázku "Jak byste to udělal lépe". Vaše odpověď je pouze na otázku "jak byste to udělal", ale přesto Vám za odpovědi děkuji.

[Petr Tomášek]

Pokud "pepř", tedy nějaký globální statický řetězec, přimícháte před hashováním, tak můžete poškodit původní algoritmus, protože ho změníte

Popravdě, to se mi zdá krajně nepravděpodobného, protože: a) to by byl opravdu velmi debilní hash, který by se nechal rozhodit "prodloužením" hesla, b) přidání pepře je z hlediska hashe to samé jako přidání (delší) soli.

Po objevení dalších hashů, což bylo několik různých variant MD5, které by se daly zjednodušeně popsat jako "MD5 se solí" a "MD5 se solí a pepřem" bylo cracknuto 2,6 milionu hesel za pár hodin a 11,2 milionu hesel za 10 dní.

1) ano, MD5 není považováno za bezpečné už pěkně dlouho, takže tohle není moc fér argumentace. 2) jediná funkce soli/pepře je ochrana proti předpočítanými nebo částečně předpočítanými hashi, proti hrubé síle pochopitelně nefunguje, ale to neznamená, že by to bylo k ničemu.

[Michal Špaček]

Díky za reakci

Popravdě, to se mi zdá krajně nepravděpodobného, protože: a) to by byl opravdu velmi debilní hash, který by se nechal rozhodit "prodloužením" hesla

Jakkoliv nepravděpodobné se to může zdát, tak je to bohužel reálné. Viz mnou odkazovaný bug v PrestaShopu, ve kterém použití "pepře" s bcryptem ořezalo hesla na 16 znaků.

b) přidání pepře je z hlediska hashe to samé jako přidání (delší) soli.

Není, podívejte se prosím jak se solí pracují algoritmy, které ji podporují, např. bcrypt. Ten sůl jenom nepřipojuje, ale postupně přimíchává. Algoritmy jako MD5 a SHA-1 salt nepodporují, proto se sůl často jen "simuluje" připojením k heslu.

MD5 není považováno za bezpečné už pěkně dlouho, takže tohle není moc fér argumentace.

Hesla jsou tak trochu jiný sport. Náhodně vygenerovaná a unikátní hesla dlouhá cca 16 a více znaků jsou bezpečně uložená i když se použije nesolená MD5. Nicméně to bylo jen doplnění kontextu a čísel k domněnce "pepř je lepší než pomalé hashování".

2) jediná funkce soli/pepře je ochrana proti předpočítanými nebo částečně předpočítanými hashi, proti hrubé síle pochopitelně nefunguje, ale to neznamená, že by to bylo k ničemu.

To je pravda. Jen teda funkcí "pepře" není ochrana proti předpočítaným hashům, to je funkce "soli" (která má tedy ještě chránit proti tzv. narozeninovým útokům, které by se s přimhouřením jednoho oka daly také považovat předpočítané hashe). Pepř má sloužit k tomu, aby bez jeho znalosti nešlo hesla crackovat a vzhledem k tomu, že se neukládá do databáze, tak nelze získat únikem databáze. Nedovolil bych si tvrdit, že salt je k ničemu, diskuze byla o důležitosti "pepře" pro znemožnění crackování.

[Petr Tomášek]

Jakkoliv nepravděpodobné se to může zdát, tak je to bohužel reálné. Viz mnou odkazovaný bug v PrestaShopu, ve kterém použití "pepře" s bcryptem ořezalo hesla na 16 znaků.

Aha, bcrypt hešuje z hesla jenom prvních 72 znaků. Takže jednoznačně debilní heš. Omezování hesla je jen koledování si o průser a 72 znaků je teda sakryš málo. Jen si představte, co se stane, když nějaká aplikace bcryptu nedopatřením předá heslo kódované jako UCS-4...

Ale díky, že jste mě na to upozornil, bcrypt mi od této chvíle "do domu" nesmí. Zlaté MD5...

[Petr Tomášek]

s/Omezování hesla/Omezování délky hesla/

[Filip Jirsák]

"Bez otravování uživatelů" není můj názor, je to požadavek. Bezpečnost jde ruku v ruce s použitelností, slovy Aviho Douglena: Bezpečnost na úkor použitelnosti jde na úkor bezpečnosti. Nelze zbytečně zatěžovat uživatele pokud to není vysloveně nutné. A při změně hashování to potřeba opravdu není.

Bezpečnost závisí na použitelnosti, ve svém komentáři jsem to jen naznačil, nepředpokládal jsem, že je nutné to explicitně popisovat. Co jsem naopak výslovně napsal, je to, že v případě pouhé výměny hashovací funkce za silnější bych hesla resetoval až po několika letech (pokud se uživatel mezitím nepřihlásil). Reálné otravování uživatelů by tedy bylo minimální, pokud vůbec nějaké – a nesrovnatelně menší třeba v porovnání s tím, že uživatele vůbec nutím vytvářet nějaký účet, místo aby se mohl přihlásit nějakým externím účtem (OpenID, Facebook, Google apod.).

Můžete mě prosím odkázat na nějaký reálný výzkum, který by Vaši domněnku potvrdil?

Ta domněnka mi připadá natolik samozřejmá, že jsem po nějakém výzkumu nikdy nepátral. Máte vy nějaký reálný výzkum, který by ji vyvracel?

Všimněte si prosím, že žádné funkce na hashování hesel "pepř" nepodporují.

A taky ty funkce pro hashování hesel očekávají na vstupu heslo v otevřeném tvaru. Což ovšem vůbec neznamená, že poskytování hesla serveru v otevřeném tvaru je dobrý nápad. Připomněl bych, že se tady celou dobu bavíme o workaroundu pro vážnou bezpečnostní chybu webových prohlížečů (nepodporují pořádně přihlašování metodou challenge–response) a bezpečnostní nedostatek protokolu HTTP (který neřeší vytváření a změnu hesel, a HTTP Digest s MD5 taky není úplně moderní) – takže argument, že se něco běžně používá, rozhodně neberu jako důkaz, že je to bezpečné.

Pokud "pepř", tedy nějaký globální statický řetězec, přimícháte před hashováním, tak můžete poškodit původní algoritmus, protože ho změníte.

Stejně jako ten algoritmus změníte, pokud před hashováním heslo zahashujete stejným nebo jiným algoritmem. Rozdíl je v tom, že to „předhashování“ prokazatelně snižuje kryptografickou bezpečnost celé operace, zatímco přimíchání pepře (pokud se neudělá špatně) by mělo být z kryptografického hlediska neutrální (samozřejmě pokud se nenajde slabina té hashovací funkce, která by zrovna to přimíchání uměla zneužít).

Jako příklad snad postačí použití "pepře" v PrestaShopu, ve kterém díky tomu byla všechna hesla uměle zkrácena na 16 znaků.

Tohle není žádný argument, zkazit lze cokoli. Pokud někde jako vstup do „heslovací“ funkce bcrypt použili omylem délku hesla místo samotného hesla, odepíšete jako nepoužitelnou i funkci bcrypt?

Navíc v realistickém modelu hrozeb by měla být možnost použití útoku SQL Injection k získání obsahu např. konfiguračních souborů, tedy i onoho "pepře".

To asi záleží na tom, jak kde – já se nepohybuju ve světě PHP aplikací, takže SQL Injection je pro mne něco, o co se musí programátor dost snažit, aby to vyrobil. A napsat tu aplikaci tak, aby šlo přes SQL injection získat konfigurační soubor, to už by byla opravdu výzva. Navíc pokud má někdo v aplikaci SQL Injection, je únik hesel ten nejmenší problém. Dále, jestli se nepletu, medializované úniky v poslední době nebyly získané útokem přes aplikaci, ale útočník získal samotná data – buď nějaké zálohy nebo jiného dumpu databáze. Proti takovým únikům chrání pepř velmi dobře. Ostatně, představte si ten současný únik Mall.cz – kdyby byl použit bcrypt, nějaká hesla by se podařilo stejně získat. Kdyby byl použit pepř (rozumně), počet získaných hesel by byl přesně 0.

Tím se sníží bezpečnost takového řešení jena na "hash a případná sůl" a závisí tedy opět na použitém hashi.

Ano, pokud útočník zná pepř, dostáváme se na původní úroveň bezpečnosti „hash soleného hesla“. Jenže s tím už se nedá nic dělat, protože heslo potřebujeme ověřit v okamžiku, kdy se uživatel přihlašuje, takže to nemůže trvat moc dlouho („Bezpečnost na úkor použitelnosti jde na úkor bezpečnosti.“). A útočník má možnost heslo louskat o několik řádů rychleji a ještě na to má na dost času. Navíc úspěšnost louskání hrubou silou závisí především na kvalitě hesla samotného. Takže zpomalování hashování je dobré leda tak pro dobrý pocit, při zabezpečení hesel je mnoho důležitějších kroků.

Mezi použitím nevhodných hashů (např. MD5) a hashů pro ukládání hesel (např. bcrypt s cost=10) je rozdíl 8 řádů, při použití vyššího costu i více. Může se to zdát málo, ale převedeno na čísla to znamená, že jde o generování kandidátů rychlostí 30 miliard pokusů za vteřinu vs. 650 pokusů za vteřinu.

Ono se to nezdá málo, ono to je málo. Šest řádů smažete použitím botnetu místo jediného počítače. Pět řádů smažete tím, že na výsledek nebudete čekat jednu vteřinu, ale počkáte si „celý“ den. Více než 8 řádů umažu použitím pouhého 32bitového pepře (snad nikdo nebude takový šílenec, aby použil něco tak krátkého). Osm řádů vymaže uživatel tím, že přidá k heslu další čtyři znaky. Nějaké řády se umažou rozvojem techniky mezi dobou, kdy byl zprovozněn daný způsob ukládání hesel, a dobou, kdy je útočník začne louskat – jenom tohle (rozvoj techniky) a nic jiného stojí za tím, proč je dnes MD5 pro hesla slabá. Nejpozději za dvacet let budou bcrypt nebo Argon2 stejně slabé, jako dnes MD5 – ale pravděpodobně mnohem dřív (i kdyby to byly dobré hashovací funkce).

Mimochodem, můžete odkázat na nějaký reálný výzkum, který by zkoumal kryptografickou bezpečnost bcrypt nebo Argon2? Protože přijít na to, že špatné použití pepře zkracuje hesla na 16 znaků, to je triviální. Přijít na to, že je něco špatně v kryptografické hashovací funkci, to je úplně jiná liga. A mně jímá hrůza pokaždé, když se někdo rozhodne, že nějakou ověřenou kryptografickou funkci „vylepší“.

Velmi pravděpodobně to za pár let dělat nebudete.

Budu. Celou dobu řešíte, kolik zbyde hesel, u kterých nikdy k přehashování nedojde, protože se uživatel znovu nepřihlásí. A já fakt nemíním mít ještě za deset let v databázi hesla, která budou závislá na síle MD5 – protože mi nikdo nezaručí, že se za těch deset let neobjeví ještě nějaká pořádná díra v MD5.

Problémem je, pokud vývojáři používají hashovací funkce, které nejsou určené k ukládání hesel, tedy např. SHA-1 a MD5, pak je potřeba takováhle spartakiáda s přehashováváním. Když se používají doporučené funkce, tak stačí transparentně po přihlášení přehashovávat, hesla jsou stále dobře chráněna i při použití třeba onoho bcryptu s costem 10.

Pro mne je důležité, že ty hashovací funkce, které nejsou primárně určené k ukládání hesel (dnes aspoň SHA-2), jsou experty prověřené kryptografické hashovací funkce. Za spartakiádu naopak považuju bcrypt a podobné.

Toto by bylo možné provést maximálně ve velkých organizacích, které tyto procesy dokáží zaručit, ale ve ani ty nemají důvod k uchovávání hesel v zašifrované podobě.

Důvod je je velmi jednoduchý – předpoklad, že v budoucnosti bude potřeba použít jiný hashovací algoritmus, například vynucený protokolem. Třeba když někdo provozuje webmail a rozhodne se přidat podporu pro SMTP+IMAP, jsou mu jeho bcryptem zahashovaná hesla k ničemu, protože SMTP a IMAP používají jiné hashe.

Tohle jsou důvody, proč jste nejenže neodpověděl na mou otázku "Jak byste to bez otravování uživatelů udělal lépe, prosím?", ale neodpověděl jste ani na otázku "Jak byste to udělal lépe". Vaše odpověď je pouze na otázku "jak byste to udělal", ale přesto Vám za odpovědi děkuji.

To, že vy si myslíte, že to není „lépe“, neznamená, že to není odpověď na uvedenou otázku. I kdyby to byla špatná odpověď, pořád to může být „odpovídající“ odpověď.

[Michal Špaček]

Prosím, začněte sledovat obor ukládání hesel a jejich lámání, zdroje jsem již odkazoval. Omlouvám se, že neodpovím na Vaše otázky, spolu s některými obraty již velmi nápadně připomínají argumentační fauly a to je ta správná chvíle se rozloučit. Díky za diskuzi!

[Filip Jirsák]

Obraty nápadně připomínající argumentační fauly jsou od začátku na obou stranách. Ale k odpovědím na otázky vás samozřejmě nikdo nenutí. Také já děkuji za diskusi.

[trekker.dk]

Šest řádů smažete použitím botnetu místo jediného počítače.

Botnet s milionem počítačů, v každém z nich nevyužitá "lámací" grafická karta? Tady bych řekl, že máte velmi optimistický odhad.

[Filip Jirsák]

Lámací grafická karta asi nebude běžnou součástí webového nebo aplikačního serveru, takže to porovnávám s běžným CPU. Uvádí se, že botnet Coreflood měl cca 2,3 milionu zařízení, Citadel cca 5 milionů. Jasně, tyhle botnety patřily k těm největším, navíc to nemusela být zařízení s výkonem PC, mohou to být nějaké mobily, RPi apod. (i když zrovna uvedené botnety byly myslím PC).

Podstatné je to, že při útoku hrubou silou je několik málo řádů strašně malý odstup – bezpečnost nemůže záviset na tom, jestli dneska může existovat botnet s pěti řády nebo už se šesti.

[Petr Tomášek]

daly zjednodušeně popsat jako "MD5 se solí" a "MD5 se solí a pepřem"

Jeminkote! S předem známým pepřem!

[Petr Tomášek]

IMHO existuje ještě možnost skombinovat 2+3. Tj. přehašovat hash hesla novější hešovací funkcí a při nejbližším přihlášení touto novější funkci zahešovat plain heslo. Jenom je nutné v databázi mít nějaký příznak, jak je které heslo zahešované...

[chrono]

Presne to tá 3. verzia robí. :)

[Josef Kufner]

Ještě je další možnost: Přehašovat při přihlášení a starým hashům nastavit expiraci a třeba po roce je smazat (uživatel se přihlásí mailem jako kdyby heslo zapoměl).

Staré hashovací algoritmy se nestávají nebezpečnými hned, ale až postupem času než se teoretický útok stane praktickým a i pak je obvykle potřeba počkat, než výkon počítačů dožene kvalitu algoritmu. Takže průběžné včasné aktualizování databáze je naprosto v pohodě.

[Michal Špaček]

Pokud starými algoritmy myslíme algoritmy nevhodné na ukládání hesel jako např. MD5, SHA-1, SHA-2, SHA-3 (fun fact: bcrypt je starší než SHA-2), tak ty nebyly pro ukládání hesel kvůli jejich rychlost bezpečné nikdy. Ostatně proto jsou také nevhodné na hesla a je potřeba je z databáze vymést co nejdříve, ideálně včera. V případě Mallu nejspíš tak před 3 roky.

[Josef Kufner]

Mimochodem, v PHP je skupina funkcí pro práci s hesly, která přehashování implementuje i s kontrolou, zda je potřeba. Generovaný osolený hash má prefix obsahující použitý algoritmus a s aktualizacemi PHP se aktualizují použité algoritmy, takže vývojář aplikace se nemusí starat.

[Michal Špaček]

Díky za doplnění, tyto funkce v článku využívám.

[Petr]

Dobry tip, diky za clanek. Takhle mi to prijde delat nejlepe.