Vždyť by to byla jen zbytečná komplikace. Museli by pořád udržovat tu starou hashovací funkci, navíc při vrstvení hashovacích funkcí na sebe nikdo neví, jak se to bude chovat z hlediska kryptografické bezpečnosti. Hlavně to, jak byla hashovaná hesla, je prkotina v porovnání s tím, že jim unikly další údaje – jména, e-maily, telefonní čísla.
okamžitě zabezpečit všechna hesla. To nikdy potřeba nebylo a nebude. ... ničemu nevadí, když to bude trvat měsíce nebo roky.
Jasný, v klidu počkáme, až nám to někdo hackne.
Provozovatel hesla nijak hashovat nemusí
Jop. A nejlepčí bude, když bude zapomenuté heslo posílat emailem, aby nemusel otravovat uživatele s nějakým resetem, že.
Pro poučené (a ne líné) uživatele je únik hesel ten nejmenší problém z celého úniku, protože náhodných hesel vygeneruju útočníkovi na počkání, kolik bude chtít.
Tak samozřejmě. To, že se s tím heslem přihlásím a vidím adresu, telefonní číslo, objednávky, faktury... přinejhorším taky uloženou platební kartu - to je takový detail. Hlavně proboha nespěchat.
Woe tebe bych si najal na zabezpečení, až budu potřebovat něco vykrást.
Jasný, v klidu počkáme, až nám to někdo hackne.
Hashování hesel nijak hacku nebrání.
Jop. A nejlepčí bude, když bude zapomenuté heslo posílat emailem, aby nemusel otravovat uživatele s nějakým resetem, že.
Doporučuji zjistit si rozdíl mezi tím, když provozovatel něco musí (např. je to vynucené technicky nebo alespoň zákonem), a když je dobré, když něco dělá.
To, že se s tím heslem přihlásím a vidím adresu, telefonní číslo, objednávky, faktury...
Telefonní čísla byla součástí toho úniku (i když údajně ne u všech uniklých účtů). Poučený a ne líný uživatel si heslo změní, jakmile se o úniku dozví. Zároveň tam měl unikátní heslo, takže okamžikem jeho změny důsledky úniku hesla eliminoval. Jenže součástí toho úniku byla také jména, e-maily, část telefonních čísel – ty ten uživatel nezmění.
Hlavně proboha nespěchat.
Demagogu. V textu, který citujete, jsem o rychlosti nepsal nic. Ale když jste takový expert, jistě nám prozradíte, k čemu je vám dobrá informace, že jsem na Mall.cz měl heslo WVLxzxt+!A6pJ6x
.
Teď už jenom zbývá vyřešit otázku, kde v textu, který jste citoval, tedy „Pro poučené (a ne líné) uživatele je únik hesel ten nejmenší problém z celého úniku, protože náhodných hesel vygeneruju útočníkovi na počkání, kolik bude chtít.“, se nachází text „ničemu nevadí, když to bude trvat měsíce nebo roky“.
Víte, já jsem psal o dvou různých událostech – první z nich je přechod aplikace na novou hashovací funkci. O tom je první odstavec. Druhou událostí je únik hesel – o tom je druhý odstavec. Pokud jste tohle nezaznamenal, pak jste ten komentář nejspíš vůbec nepochopil a nemá smysl, abyste na něj reagoval.
>To ještě neznamená, že se ty informace mají rovnou vystavit na webu. Měly by být zabezpečené tak, aby se crackerovi nevyplatilo se tam dostávat.
Zamykáš/te si kolo do trezoru? Žádná ochrana není stoprocentní, a nakonec se někdo rozhodne ten trezor vyloupit, kdyby třeba jenom proto, aby mohl říct "tak zaplať, nebo se všichni dozví, že to senzační zabezpečení...". Ty informace se nemají vystavit na webu. A informace o hesle ideálně není ani v té databázi, tam je informace jen o hashi hesla (která je teoreticky bez jakékoliv hodnoty, reálně aspoň méně hodnotná).
>Mně na tom úniku netrápí heslo, náhodných hesel si vygeneruju, kolik budu chtít. Vadí mi ty ostatní údaje.
Tohle podepíšu a hádat se nebudu.
>Tohle prostě není pravda. O stoprocentní ochraně jsem nepsal, naopak jsem výslovně napsal, že zabezpečení musí být lepší, než je motivace útočníka se k tomu dostat.
O tom právě mluvím, jednoho dne se najde maník, pro kterého bude motivací právě "neprůstřelné" zabezpečení. Nikdy jsem taky netvrdil že se na zabezpečení má rovnou rezignovat, ale specializovaný obchod s pár stovkami prodejů měsíčně nebude do zabezpečení dat investovat stovky milionů korun.
>Jenže to je právě ten problém, kdy se naivní očekávání míjejí s realitou. Ideálně v databázi není o hesle (ani klíči) vůbec nic, jenže to by se pak nikdo nepřihlásil. Jenže my nepotřebujeme teoreticky ideální aplikace, my potřebujeme aplikace použitelné a bezpečné.
Čehož se dá dosáhnout například použitím hlavy a bezpečné hashovací funkce. Ať už se nad ten hash postaví sůl, pepř, kari, tabasko - to už je ta "hlava". Ale "Hashování hesel nijak hacku nebrání." (jistý Filip Jirsák, 28. 8. 2017 11:53, komentáře pod tímhle článkem). Nezabrání. Ale to není důvod heslo nehashovat. Použitelné a bezpečné je heslo v plaintextu nemít. Útoku to nezabrání. Ale zmírní to následky případného útoku.
Mimochodem, cituješ/te část "A informace o hesle ideálně není ani v té databázi, (...)", v prvním odstavci to označuješ/te jako problém a ve druhém odstavci hashování hájíš/te (byť souhlasím s tím, že prostý hash snižuje informaci o hesle jen málo).
O tom právě mluvím, jednoho dne se najde maník, pro kterého bude motivací právě "neprůstřelné" zabezpečení.
To ještě neznamená, že to bude dostatečnou motivací.
Nikdy jsem taky netvrdil že se na zabezpečení má rovnou rezignovat
V tom případě nechápu ty poznámky o tom, že nic není 100% bezpečné.To přece všichni vědí. Jde o to, aby to bylo bezpečné dost bezpečné v porovnání s tím, jaké je riziko úniku dat.
Čehož se dá dosáhnout například použitím hlavy a bezpečné hashovací funkce. Ať už se nad ten hash postaví sůl, pepř, kari, tabasko - to už je ta "hlava".
Uvádíte to v prapodivném pořadí. Jak už jsem tu několikrát vysvětloval, na konkrétní hashovací funkci záleží mnohem méně, než na použití soli nebo pepře.
Ale to není důvod heslo nehashovat.
Hashování není jediný způsob zabezpečení hesel. A důvody, proč hesla nehashovat, také existují – třeba když využíváte protokol, který vyžaduje znalost hesla na serveru (třeba některé challenge-response protokoly).
Použitelné a bezpečné je heslo v plaintextu nemít.
Já jsem ale nikdy nepsal o uchování hesla v plaintextu (i když i pro to někdy existují důvody). Psal jsem o uchování hesla šifrovaného asymetrickým klíčem – což je mimochodem z hlediska bezpečnosti ještě bezpečnější, než hash.
Mimochodem, cituješ/te část "A informace o hesle ideálně není ani v té databázi, (...)", v prvním odstavci to označuješ/te jako problém a ve druhém odstavci hashování hájíš/te (byť souhlasím s tím, že prostý hash snižuje informaci o hesle jen málo).
Nevím, co se vám na tom nezdá. V ideálním případě by nikde nebyla uložená žádná informace o hesle. Jenže to je ideální případ, kterého nejde v praxi dosáhnout. Takže dál se bavíme o tom, co je reálné – a jeden ze způsobů, jak se hesly zacházet docela bezpečně je jejich hashování se solí.
Máte pravdu ve všem až na výchozí předpoklad – že je potřeba okamžitě zabezpečit všechna hesla. To nikdy potřeba nebylo a nebude. Když si někdo uvědomil, že nesolené hashe je možné napadnout vyhledáváním v duhových tabulkách, bylo rozumné přejít na solený hash – ale není nutné to udělat okamžitě, ničemu nevadí, když to bude trvat měsíce nebo roky. Ještě méně to vadí při změně hashovací funkce, protože i útok na MD5, který by bylo možné použít proti heslům, je zatím jen teoretický – a při ukládání hashů hesel se na nové hashovací funkce přechází především z důvodu kompatibility, protože je jasné, že postupně přestanou být v softwaru podporovány a jejich používání by byla jen komplikace.
Také je důležité, že hashování hesel jenom trochu chrání uživatele před jejich vlastní neznalostí. Provozovatel hesla nijak hashovat nemusí – a měl by se starat hlavně o to, aby databáze neunikla ven vůbec. Pro poučené (a ne líné) uživatele je únik hesel ten nejmenší problém z celého úniku, protože náhodných hesel vygeneruju útočníkovi na počkání, kolik bude chtít.
Vrstvení hashovacích funkcí na sebe z kryptografického hlediska nijak prozkoumané není. „Dobře prozkoumané tyto postupy“ znamená akorát to, že to tak naprogramoval někdo, kdo o kryptografii nic neví. Klidně to může být něco podobného, jako když kdysi jeden správce balíčku v Debianu „vylepšil“ generátor náhodných čísel. Jediné, čím se tohle liší od různých samo-domo superbezpečných šifer a hashů, které každou chvíli někdo objeví, je to, že ideální hashovací funkce by měla dávat naprosto náhodný výstup, takže by mělo být jedno, že je ten výstup vstupem do další hashovací funkce. Problém je v tom podmiňovacím způsobu – používané hashovací funkce nejsou ideální a jejich řetězení nikdo z kryptografického hlediska nezkoumal.
No, snad pořád platí, že co nevím, to nepovím. Když se cracker bude snažit, tak se pravděpodobně dovnitř dřív nebo později vláme...
To ještě neznamená, že se ty informace mají rovnou vystavit na webu. Měly by být zabezpečené tak, aby se crackerovi nevyplatilo se tam dostávat.
Mně na tom úniku netrápí heslo, náhodných hesel si vygeneruju, kolik budu chtít. Vadí mi ty ostatní údaje.
Žádná ochrana není stoprocentní, a nakonec se někdo rozhodne ten trezor vyloupit, kdyby třeba jenom proto, aby mohl říct "tak zaplať, nebo se všichni dozví, že to senzační zabezpečení...".
Tohle prostě není pravda. O stoprocentní ochraně jsem nepsal, naopak jsem výslovně napsal, že zabezpečení musí být lepší, než je motivace útočníka se k tomu dostat. Je potřeba uvažovat, jak jsou ta data důležitá a jak je co nejlépe zabezpečit – ne na zabezpečení rezignovat s tím, že to stejně nejde udělat na 100 %. E-shop má minimálně kontaktní údaje včetně adresy, historii objednávek, některé e-shopy mohou mít uložené i číslo platební karty. Z historie objednávek si můžete vyfiltrovat, kdo nedávno nakoupil drahé zboží (bílé zboží, televize, počítače) a máte k tomu i adresu. Je štěstí, že Mall.cz unikly jenom jména, e-maily, část telefonů a nějaké hloupé hashe – mohlo to být podstatně horší. Pro mne to znamená, že Mall.cz bere zabezpečení zodpovědně, protože ta data, která unikla, byla pravděpodobně oddělená od ostatních dat.
A informace o hesle ideálně není ani v té databázi, tam je informace jen o hashi hesla (která je teoreticky bez jakékoliv hodnoty, reálně aspoň méně hodnotná).
Jenže to je právě ten problém, kdy se naivní očekávání míjejí s realitou. Ideálně v databázi není o hesle (ani klíči) vůbec nic, jenže to by se pak nikdo nepřihlásil. Jenže my nepotřebujeme teoreticky ideální aplikace, my potřebujeme aplikace použitelné a bezpečné.
Z hashování hesel se v poslední době stala móda, o které mluví každý, byť o bezpečnosti neví nic. A podle toho to vypadá. Data mají být především uložena a zpracovávána tak, aby se k nim nikdo nepovolaný nedostal. Dále tak, aby když se k nim dostane, napáchalo to co nejméně škody, protože tam nebudou zbytečná data navíc, která nejsou pro provoz potřeba. Což se zrovna vztahuje na hesla, protože u mnoha protokolů (včetně všech používaných webových) není k ověření uživatele potřeba na serveru uchovávat heslo v otevřeném tvaru. Hashování hesel je ale jen jeden z prostředků, jak tohohle dosáhnout, ale neznamená to, že jenom stačí použít hash. Proti útokům pomocí duhových tabulek je bezpodmínečně nutné použít nějaký proměnný údaj, ideálně sůl – lepší je, když je specifický pro každé heslo, ne jeden globální. Proti úniku dat z databáze zároveň velmi pomůže použití (globální) soli uložené mimo databázi (prý se tomu říká pepř) – útočník, který získá jen data z databáze, ale nemá pepř, je pak nahraný. Na volbě hashovací funkce pak skoro nezáleží (ideální je použít nějakou aktuální, ale to je hlavně z důvodu snadné údržby kódu a proto, že vás nečekají žádná nečekaná překvapení) – mírně to ovlivňuje akorát útoky hrubou silou na vybrané záznamy (nějakých VIP uživatelů), a tam nesrovnatelně lepší práci odvede kvalitní heslo – slabé heslo nezachrání sebelepší hashovací funkce, protože tu entropii prostě nevyrobí.