Názory k článku
Mall.cz resetuje hesla, k části databáze se mohli dostat hackeři [AKTUALIZOVÁNO]

Já jsem rád, že o bezpečnosti vím alespoň něco málo, abych poznal ty nejkřiklavější případy, když amatér začne vylepšovat bezpečnostní funkce – a držel se od takových hodně daleko.

Jsem rád, že já jako absolutní neználek nejsem závislý na tobě jako bezpečnostním expertu.

Nebo jinak ... pokud souhlasíš, že bcrypt(salt . plainheslo) je dostatečně bezpečné, tak musí být dostatečně bezpečné i bcrypt(salt.md5(hes­lo)).
Už v komentáři, na který reagujete, jsem vám vysvětlil, proč to není pravda.

Prostě si v hlavě proveď md5 = plaintext.
To jste ovšem učinil ničím neodůvodněný silný předpoklad. Jak jsem psal výše, zkuste si do té vaší rovnice dosadit třeba md5 = const 'a'. Nebo, aby to nebylo tak průhledné, třeba md5 = substring(pla­inheslo, 0, 1).

Tímto jsem ti podal důkaz a končím diskusi.
Podal jste důkaz, který jsem vyvrátil dřív, než jste ho podal. Diskusi nemusíte ukončovat, stačí ji přerušit do doby, než pochopíte to, co už jsem vám v komentářích napsal.

Prostě nemáš pravdu. Bezpečnost je daná tou poslední (tedy nejsilnější) částí.
Někdo používá matematiku a argumenty, někdo pověry a dokazuje slůvkem „prostě“. Já jsem vám uvedl konkrétní příklad, jak může jedna slabá hashovací funkce rozbít celý řetězec – bez ohledu na to, kde se v tom řetězci nachází. Tím vaším „prostě“ jste to nevyvrátil.

A prodloužení doby louskání je opravdu výhodou. Dost to vadí brute-force útokům.
Nepatrné prodloužení doby louskání je nepatrnou výhodou. Nepatrně to vadí brute-force útokům.

A dokonce je i fajn, že útočník nezná správnou kombinaci těch hashů, vidí jen ten nejsilnější.
Vy si stále představujete, že útočník něco „odhashuje“ a něco se mu objeví. Tak to ale funguje možná tak v CSI. „Útočník vidí jen ten nejsilnější hash“ jen dokazuje, že vůbec netušíte, o čem píšete – protože útočník žádný hash nevidí.

Útočník vidí to, co je v databázi – může tam být jen výstup hashovací funkce, může tam být nějaké označení hashovací funkce plus její výstup. Když bude v databázi 16 bajtů, může si tipnout, že je to MD5, když tam bude 20 bajtů, může si tipnout, že je to SHA-1. Ale stejně tak to první může být 16 bajtů useknutých z SHA-1, nebo to druhé MD5 doplněná o 4 náhodné bajty. Pokud útočník algoritmus hashe nezná, může zkusit, zda to není jednoduché použití hashe s danou délkou výstupu. Pokud útočník algoritmus hashování nezná, má smůlu, a zastaví ho i tak primitivní algoritmus, jako přidat na začátek každého hesla malé „a“ a pak to zahashovat MD4 (sic!). Jenže zabezpečení dat se dělá s předpokladem, že útočník hashovací algoritmus zná.

Kdyby byla bezpečnost daná tou nejslabší částí, tak hashe nebudou fungovat vůbec. Protože tou nejslabší částí je právě ten plaintext.
Jenomže tak to ve skutečnosti je. Když budete mít čtyřznakový číselný PIN, útočníkovi stačí nejvýš 10 000 pokusů na jeho zjištění. A můžete k tomu požít třeba SHA-3 tisíckrát iterovanou, a stejně vám to nepomůže, protože to je jenom deset tisíc možností. Hashovací funkce nedokáže entropii vyrobit, bez ohledu na to, jakou krkolomnost si vymyslíte.

Běžné desetiznakové heslo bude složitost cca 26^10. Kdežto MD5 2^128 pro jakoukoliv délku.
No jo no, jak už jsem několikrát psal, bezpečnost není intuitivní. Vaše představa, jak se louská MD5 a postupně na obrazovce nabíhají jednotlivé znaky hesla, jak to vídáte v televizi, neodpovídá realitě. Hashe hesel se „louskají“ tak, že zkoušíte jedno heslo za druhým, pokaždé pro něj spočítáte příslušný hash, a porovnáte jej s tím hashem, který máte v databázi. Případně to nemusíte počítat, pokud už ty hashe někdo spočítal před vámi a vytvořil z nich databázi, ve které je jenom hledáte. Takže když budete vědět, že heslo má 10 malých písmen, je to složitost pořád 26¹⁰, protože budete generovat jednotlivá hesla. Délka hashe počet zkoušených variant nijak neovlivní – pořád musíte vyzkoušet maximálně 26¹⁰ hesel, ať jsou zahashovaná MD5, SHA-1 nebo čímkoli jiným.

Ty jsi prostě popsal brute-force…
Jistě, co bych měl popisovat jiného? Metoda hrubé síly je jediná metoda, kterou je možné získat heslo „z“ hashovacích funkcí MD5 nebo SHA-1. Ani u jedné z těch funkcí není znám útok, který by uměl hledat kolize 2. řádu (což by byla možnost, jak ten útok urychlit). Resp. u MD5 myslím nějaký teoretický koncept existuje, ale nebylo to ověřeno v praxi, protože je to zatím příliš nákladné.

tím dokážeš napadnout libovolný způsob. Dokonce i ty tvoje asymetrické šifry v trezoru.
Jo. Když budete mít v databázi uložené svoje heslo, které bude zašifrované jenom kilovým klíčem, vytvoříte si první klíč a zkusíte jím své zašifrované heslo dešifrovat – když dostanete to vaše heslo, máte klíč, když nějaké náhodné smetí, máte špatný klíč a zvolíte si další. S pravděpodobností 50 % najdete správný klíč už po vyzkoušení 2¹⁰²³ klíčů.

Souhlasí se mnou i pan Vrána, Dokonce i wikipedie
Tomu se říká Dunningův-Krugerův efekt. Na to, abyste dokázal porovnat vaše výroky s těmi odkazovanými texty, byste potřeboval nějaké minimum znalostí. Kdybyste ty znalosti měl, nepsal byste „útočník vidí nejsilnější hash“.

já říkám, že heslo browser neopustí, ty tvrdíš to samé - a přitom mi odporuješ
Podstatné je, jak je to z pohledu uživatele. Uživatel zadá heslo do webové stránky – tedy ve vašem případě musí počítat s nejhorším případem, a to takovým, že heslo prohlížeč opustí. Uživatel těžko bude pokaždé kontrolovat vaše skripty, aby si mohl být jistý, že fungují správně a že se heslo z prohlížeče skutečně nikam ven nedostane.

Nebo jinak ... pokud souhlasíš, že bcrypt(salt . plainheslo) je dostatečně bezpečné, tak musí být dostatečně bezpečné i bcrypt(salt.md5(hes­lo)). Prostě si v hlavě proveď md5 = plaintext. Nebo klidně sha1(md5(heslo)) = plaintext. To je naprosto fuk. Tímto jsem ti podal důkaz a končím diskusi.

Prostě nemáš pravdu. Bezpečnost je daná tou poslední (tedy nejsilnější) částí. A prodloužení doby louskání je opravdu výhodou. Dost to vadí brute-force útokům.
A dokonce je i fajn, že útočník nezná správnou kombinaci těch hashů, vidí jen ten nejsilnější. Sice security by obscurity, ale i tak je to prostě zesložištění útoku.

Kdyby byla bezpečnost daná tou nejslabší částí, tak hashe nebudou fungovat vůbec. Protože tou nejslabší částí je právě ten plaintext. Běžné desetiznakové heslo bude složitost cca 26^10. Kdežto MD5 2^128 pro jakoukoliv délku. Možnost kolizí nebo možnost brute force je tedy už naprosto jedno - důležitá je ta první, prozatím bezpečná část. Kolizí v rámci toho plaintextu bude podstatně více (v rámci nějaké větší db).
Ty jsi prostě popsal brute-force ... tím dokážeš napadnout libovolný způsob. Dokonce i ty tvoje asymetrické šifry v trezoru.

Souhlasí se mnou i pan Vrána: https://php.vrana.cz/ukladani-hesel-bezpecne.php
Dokonce i wikipedie: https://cs.wikipedia.org/wiki/Message-Digest_algorithm

---

Ten poslední odstavec nechápu ... já říkám, že heslo browser neopustí, ty tvrdíš to samé - a přitom mi odporuješ.

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í.

Implementaci to sice nepatrně zesložišťuje, ale ono je to spíš k plusu ...
V žádném případě. Složitější implementace znamená náklady navíc, větší pravděpodobnost chyby, komplikovanější testování, což často vede k tomu, že to testované není. Výhoda složitější implementace není žádná.

Překvapení znamená, že vím jak to funguje.
Dobře, napíšu to konkrétně:
Spíš se mi líbí překvapení hackera, až po bcryptu bude louskat sha1. Až tam objeví md5, tak mu hrábne ...
Tohle je nesmysl. Hacker nebude objevovat SHA-1 a po té MD5, hacker musí předem vědět, jak ta hashovací funkce vypadá (např. že je to nejprve MD-5, pak SHA-1 se solí – a kde je ta sůl uložená). Vy to popisujete, jako by nešlo o hashování, ale o šifrování, a útočník by odšifroval jednu vrstvu a dostal se k další.

Proč bych musel mít u každého hesla uložené? Proč bych musel vědět, jak je to zahashované? Vždyť všechny budou stejně ...
Takže byste tam měl navěky staré hashovací funkce, které mohou mít vážnou díru která znehodnotí vše za tím. To je opravdu vylepšení… Představte si, že na začátku použijete hashovací funkci, u které se později ukáže, že její prostor hodnot je ve skutečnosti jen 10 – nebo-li že stačí mít 10 různých univerzálních hesel, a ke každému účtu bude jedno z těch hesel platit. Vy na to pak navršíte SHA-1 a bcrypt a SHA-3 a spoustu dalších hashovacích funkcí – a útočník pak přijde, vyzkouší těch deset hesel a jedno z nich bude fungovat. Jak už jsem psal, počítačová bezpečnost není intuitivní – tohle je jeden z příkladů, vy jste měl pocit, jak vrstvením hashů na sebe bezpečnost zvyšujete, přitom vám jí hned ten první hash rozboural a nic nad ním už to nespraví.

Mít každé jinak byla blbost i u Mall, jak se ukázalo. Nic takového se neukázalo. V tom, že jsou použité různé hashovací funkce, nebyl žádný problém, problém nebyl dokonce ani v tom, které konkrétní funkce jsou použité. V případě Mall.cz by pomohly tyhle tři věci v tomto pořadí:

1. Mít data zabezpečená tak, aby k úniku vůbec nedošlo.
2. Když už se nepodařilo to první, u hesel by pomohlo, kdyby se pro hashování použila sůl uložená mimo databázi (někdo to nazývá pepř). Útočník, který získal jen tu databázi, pepř znát nebude, a když bude dostatečně náhodný, nemá šanci ho uhodnout.
3. Když už nebylo ani to, pomohlo by, kdyby každé heslo mělo unikátní sůl – to nebylo splněné u starších hesel.

Když se na ten seznam podíváte, skutečný průšvih s hesly vznikl až tím, že ta stará hesla nebyla nijak osolená. To, že to bylo MD5, je prkotina – kdyby ta hesla byla osolená, dostali bychom se maximálně k pár heslům nějakých VIP účtů, pro které by se někdo rozhodl, že na ně spustí útok hrubou silou. Rozdíl mezi MD5 a SHA-1 je v tom, jestli těch VIP hesel rozlouskneme 5 nebo 10. Rozdíl mezi nesolenými a solenými hesly je v tom, jestli se rozlouskne pár hesel k vybraným účtům, nebo jestli se rozlousknou všechna jednoduchá hesla. Ano, zase to není intuitivní, kryptografické hashovací funkce jsou tak komplikované, tak by se zdálo, že budou to nejdůležitější, a ona je přitom mnohem důležitější sůl – a hlavně silná hesla.

Heslo přístupné v plaintextu posílat serveru nemusím. Alespoň od té doby, co existuje javascript ... Posílám-li, jsem blbej programátor. Používám to i já v systému, který využívá pouhých deset lidí v intranetu.
Z hlediska uživatele je to to samé – heslo předá vašemu skriptu, a co s ním ten skript udělá, to uživatel neovlivní. Taky samozřejmě záleží na tom, jestli je to v tom JavaScriptu vůbec naprogramované správně. Přístup k tomu heslu mají všechny skripty na stránce, mají k němu doplňky prohlížeče.

Správné řešení pro tyhle případy je takové, že heslo vůbec neopustí prohlížeč jako takový – tj. už v okamžiku, kdy prohlížeč předává údaje webové stránce, skriptu nebo ho posílá přes síť, musí už to heslo být „zakódované“ – např. zahashované se solí.

Implementaci to sice nepatrně zesložišťuje, ale ono je to spíš k plusu ...

Překvapení znamená, že vím jak to funguje. Proč bych musel mít u každého hesla uložené? Proč bych musel vědět, jak je to zahashované? Vždyť všechny budou stejně ... Mít každé jinak byla blbost i u Mall, jak se ukázalo.

Heslo přístupné v plaintextu posílat serveru nemusím. Alespoň od té doby, co existuje javascript ... Posílám-li, jsem blbej programátor. Používám to i já v systému, který využívá pouhých deset lidí v intranetu.

X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "Date"
X-Spam-Flag: YES
X-Spam-Score: 5.311
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.311 tagged_above=-10 required=5
tests=[DCC_CHEC­K=2.8, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1­.105,
MISSING_DATE=1.396, SPF_PASS=-0.001, T_KAM_HTML_FON­T_INVALID=0.01]
autolearn=disabled

Žá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í.

Ta MD5 je tam úplně zbytečná, jenom to zbytečně komplikuje implementaci.

To vaše „překvapení“ akorát vypovídá o tom, že nevíte, jak to funguje. U toho hesla by muselo být uložené, že to bylo hashované nejprve MD5, pak SHA-1 a pak bcryptem. Při přihlášení uživatele by se to samozřejmě muselo hashovat ve stejném pořadí.

Heslo přístupné v plaintextu serveru posíláte, tak se nedivte, že ho server má. To zašifrované heslo s klíčem v trezoru je velice bezpečné řešení, dokonce výrazně bezpečnější, než osolený a opepřený hash (a ty jsou bezpečné dost).

Ona kryptografie není zrovna intuitivní, v diskusích najdete spoustu nesmyslů – hlášky jako „hesla v plaintextu je svinstvo“ nebo „MD5 je pro hesla slabá“ jsou sice efektní, ale s realitou nemají nic společného.

A čemu to MD5 vadí? Že by za deset let nebyla dostupná implementace? Tak si ji napíšu ...
Spíš se mi líbí překvapení hackera, až po bcryptu bude louskat sha1. Až tam objeví md5, tak mu hrábne ...

Hesla přístupná v plaintextu je svinstvo. Ten privátní klíč v trezoru mě rozhodně neuklidňuje.

A pak musíte mít v kódu na věky implementaci MD5. Když už chci hesla přehashovávat bez účasti uživatele, uložím si je do databáze i zašifrovaná asymetrickou šifrou, k níž je privátní klíč uložen offline někde bezpečně v trezoru. Až je budu chtít přehashovat, vyndám klíč z trezoru, hesla rozšifruju a zahashuju novým hashem.

Lze to samozřejmě přehashovat i bez účasti uživatele. Prostě není v db něco jako bcrypt(heslo), ale bcrypt(md5(heslo)). A tak do kolečka, kdykoliv je potřeba to změnit.

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.

Ano, jediná opravdu problematická a podezřelá věc je ten přímý odkaz na password recovery. To by podobný mail, je-li pravý, nikdy obsahovat neměl.
Proč by ho obsahovat neměl? Uživatel si má samozřejmě zkontrolovat, že odkaz vede na správnou doménu. Problém by byl, pokud by e-mail uživatele nabádal k tomu, aby zadali heslo do nějakého nestandardního formuláře – ale to ten e-mail nedělá, naopak začíná tím, že staré heslo je neplatné.

V patičce Mall.cz:
"Bezpečný nákup, Vaše data v bezpečí"
:-D

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.

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.

Mohl by Mall prosím místo "vlastní" aplikace ta data předat na https://haveibeenpwned.com/? Nebo alespoň současně s tím?

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.

"na zaklade osobni zkusenosti"
Vy ta hesla ve svých aplikacích asi nehashujete vůbec, nebo odkud máte ty osobní zkušenosti? :-)

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.

Když ty e-maily čtete nepozorně, jste na nejlepší cestě na nějaký naletět. V tomhle e-mailu nebylo nic o tom, že máte někam zadávat své přihlašovací údaje, naopak je tam napsáno, že vám heslo zrušili. Kdybyste nic neřešil, taky se nic nestane, akorát byste si to heslo musel nastavit až při příštím přihlášení.

Pokud unikla databáze s hashi, je potřeba změnit všechna hesla, která v té databázi byla, nejen ta se slabým hashem bez soli. To, že útočník pomocí duhových tabulek získá hesla uživatelů je jen jeden z problémů. Další problém je i to, že útočník může znát jiná hesla uživatelů (z jiných úniků), a i při použití silné hashovací funkce nebo soli si může ověřit, že i zde použil uživatel stejné heslo. A pak se samozřejmě může útočník zaměřit na nějaké VIP uživatele a pokoušet se zjistit jejich heslo hrubou silou.

No, podle mně měli takhle průběžně ty hashovací metody měnit za lepší - a teď případně zablokovat účty jen těm, kteří se opravdu nepřihlásily třeba ty 3 roky a víc. Těch by mohlo být řádově třeba 10 %. A určitě by to bylo lepší, než teď s resetem hesla otravovat úplně všechny zákazníky...

I když je taky docela dobře možné, že jim opravdu utekla spíš nějaká starší záloha - a pak je tu ještě to riziko, že i kdyby třeba konkrétní zákazník měl nyní heslo už hashované bezpečně, tak by to bylo to samé heslo, co měl před třeba 6-7 lety a tudíž by ho útočník z té staré zálohy měl také. Takže když teď donutí ke změně všechny, tak to k bezpečnosti určitě spíš přispěje, než aby jí to zhoršilo. :-)

No možností je víc. Buď je neřešíte vůbec (a prostě mají heslo hashované méně bezpečnou funkcí - ale takových uživatelů bude asi obecně méně - a u eshopů navíc někdo, kdo třeba delší dobu od nich nic nenakoupil je asi také méně zajímavý), nebo jim to heslo zneplatníte - a díky tomu, že máte jejich mailovou adresu, tak si můžou nastavit heslo nové (buď je o tom informujete mailem, nebo při pokusu o další přihlášení). Taky můžete účty, na které se nikdo nepřihlásil třeba 3 roky rovnou smazat...

Na to není potřeba mít plaintext heslo uložené, ale můžete tuhle operaci (převod hesla ze starší hashovací funkce na novou) udělat při nejbližším dalším přihlášení daného uživatele - protože tehdy on to heslo stejně zadává a máte ho tedy dočasně v nehashované podobě.

Takto to i dělají některé frameworky, když postupně přecházejí na čím dál tím bezpečnější hashovací algoritmy. A dokonce kvůli tomu v databázi ani nemusí mít víc sloupečků - v tom jednom, kde je hash hesla, tak před vlastním hashem hesla je třeba string: "md5:", "sha1:", "sha256:", "bcrypt:"...

Ano. (Hm, to jsou mi novinky…)

Máte pravdu, že tam ta hlavička byla přidána až po cestě. Zmátlo mne, že ostatní hlavičky jsou přidané normálně nahoru, ale Date je přidaná naopak až na konci hlaviček.

Ve FAQ přiznávají, že mají více databází s uživatelskými účty podle toho, kdy byl účet založen
Nikoli, to je jen vaše interpretace.

Mít více oddělených databází účtů by bylo velmi krkolomné a muselo by to mít nějaký velmi vážný důvod. Který by se teď najednou těžko vyřešil, navíc v době, kdy řeší únik hesel a nějaká migrace databáze by bylo to poslední, co by teď chtěli řešit.

Já bych si spíš tipnul, že „starší databáze“ znamená, že jim utekla nějaká starší záloha – jak je v těchhle případech obvyklé. No a pokud si u hesla neukládají, kdy bylo změněno (což není moc časté), nezbývá jim než změnit hesla všem účtům, které existovaly v době, kdy byla pořízena ta záloha. Neresetovat heslo jenom proto, že bylo hashováno silnějším algoritmem, by bylo dost riskantní riskantní. Útočník nemusí jenom těžit nová hesla, může také použít hesla z jiných útoků, a jenom si ověří, že má dotyčný stejné heslo i u Mall.cz – tomu nezabrání sebenovější hashovací algoritmus (zabránilo by tomu, pokud by do hashování vstupovala i sůl uložená mimo databázi, pokud by ji útočník nezískal).

Nyní to neřeší žádný zákon, ale nové GDPR v případě úniku osobních dat již jasně stanovuje že se to musí oznámit a řešit. No a úřad má i možnost dát pokutu.
Myslím ale, že samotný únik bude dost velký postih značky Mall. Já už tam dlouho nenakupoval a už ani o tom nebudu uvažovat.

Pokud antispam strhává body za chybějící hlavičku, která v e-mailu je, je to chyba toho antispamu, nemyslíte?

Mně přišlo tohle (předcházejí tomu další hlavičky doplněné poštovními servery po cestě):

Received: from [127.0.0.1] (localhost [127.0.0.1]) by smtp3.mall.cz (Postfix)
 with ESMTP id A6081858798 for <xxx@xxx>; Sun, 27 Aug 2017 12:33:22
 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 smtp3.mall.cz A6081858798
From: "MALL.cz" <bezpecnost@mall.cz>
Reply-To: bezpecnost@mall.cz
To: xxx@xxx
Message-ID: <468260030.73887.1503830002686@d4519.masterinter.net>
Subject: =?UTF-8?Q?D=C5=AFle=C5=BEit=C3=A9_bezpe=C4=8Dnos?=
 =?UTF-8?Q?tn=C3=AD_upozorn=C4=9Bn=C3=AD:_Zv?=
 =?UTF-8?Q?olte_si_pros=C3=ADm_nov=C3=A9_heslo_do_Mall.cz.?=
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Date: Sun, 27 Aug 2017 13:39:05 +0300 (EEST)

V těle e-mailu jsou pak vedle toho uváděného odkazu ještě odkazy na Mall.cz (přes logo), Váš účet a MALL.CZ Plus (oba vedou na doménu mall.cz), dále je v textu odkaz na https://www.mall.cz/user/password-recovery/recovery (takhle rozepsaný) a odkaz „u nás na blogu“, který vede na zápisek zmíněný i dvakrát ve zprávičce.

No já v mailu hlavičku date mám:
"Date: Sun, 27 Aug 2017 04:14:57 -0700 (PDT)"

Nicméně antispamům se to nelíbí -mail dostává docela vysoké score (i za chybějící date)
X-Spam-Flag: NO
X-Spam-Score: 3.112
X-Spam-Level: ***
X-Spam-Status: No, score=3.112 tagged_above=-1000 required=5
tests=[HTML_MES­SAGE=0.001, MIME_HTML_ONLY=1­.105, MISSING_DATE=1.396,
RCVD_IN_DNSWL_MED=-1.5, RP_MATCHES_RCVD=-0.6, SO_NIC=0.6,
SO_PUB_URIBL_NS_40=1­.001, SPF_PASS=-0.001,
T_KAM_HTML_FON­T_INVALID=0.01, _AUTOMATED_LIN­K=0.1,
_EXTERNAL_CON­TENT=0.5, _EXTERNAL_IMG=0.4, _HASH_LINK=0.1]

Email přišel z:
From: "MALL.cz" <bezpecnost@ma­ll.cz>
Received: from smtp4.mall.cz (smtp4.mall.cz. [92.43.56.177])
Received-SPF: pass (google.com: domain of bezpecnost@mall.cz designates 92.43.56.177 as permitted sender) client-ip=92.43.56.177;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bezpecnost@mall.cz designates 92.43.56.177 as permitted sender) smtp.mailfrom=bez­pecnost@mall.cz

SPF je tedy v pořádku
Zpráva nemá DKIM...

na yottly vede odkaz z emailu "Je-li tento email nečitelný, zobrazte si jej":
zobrazte si jej </span><span style=3D=
"color: rgb(204, 0, 0); font-size: 12px; line-height: 14px;"><a style=3D"co=
lor:#0068A5;text-decoration: none; color: rgb(204, 0, 0);" href=3D"https://=
external-link-mall.yottly.com/1234­..." rel=3D"=
noopener noreferrer">zde >

Spíš je dost neuvěřitelné, že při změně hesla rozhoduje o tom, jaký algoritmus se použije, datum založení účtu.
Jak jste na něco takového přišel?

tři roky staré účty stále jedou na SHA1
I kdyby to byla pravda, vůbec ničemu to nevadí.

Jste si jistý, že ten váš e-mail je opravdu od Mall.cz? V tom mém hlavička Date je, na yottly.com vede jen odkaz na zobrazení obsahu e-mailu, pokud je v e-mailovém klientovi nečitelný – všechny ostatní odkazy vedou na mall.cz.