Hlavní navigace

Vlákno názorů k aktualitě Mall.cz resetuje hesla, k části databáze se mohli dostat hackeři [AKTUALIZOVÁNO] od Filip Jirsák - Vždyť by to byla jen zbytečná komplikace. Museli...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 28. 8. 2017 8:38

    Filip Jirsák

    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.

  • 28. 8. 2017 8:42

    TM (neregistrovaný)

    v pripade ze neznaji plain text je to jedina rozumna metoda jak okamzite zabezpecit vsechna hesla. Vyse navrhovane zpusoby (cekat az se uzivatel prihlasi) jsou nesmyslne protoze u desitek procent uzivatelu budete cekat mesice a roky nez se prihlasi

  • 28. 8. 2017 10:48

    Lol Phirae (neregistrovaný)

    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.

  • 28. 8. 2017 8:06

    TM (neregistrovaný)

    Me by zajimalo co jim branilo v tom ty stara zahashovana hesla jeste jednou hashovat tim novym neprustrelnym algoritmem? Nemusi znat plain text. Proste jen projedou databazi a stavajici hashe zaheshuji znovu (a stejny postup pouziji pri ukladani hesla u novych uzivatelu)

  • 28. 8. 2017 8:43

    TM (neregistrovaný)

    z hlediska bezpecnosti - jsou docela dobre prozkoumane tyto postupy (pokud pouzivaji standardni hashovaci fce) a da se tedy urcit nakolik by to zasahlo bezpecnost.

  • 28. 8. 2017 11:53

    Filip Jirsák

    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.

  • 28. 8. 2017 12:17

    Filip Jirsák

    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.

  • 29. 8. 2017 12:34

    Ravise (neregistrovaný)

    >Hashování hesel nijak hacku nebrání.
    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...

  • 29. 8. 2017 23:37

    Ravise (neregistrovaný)

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

  • 30. 8. 2017 13:13

    Ravise (neregistrovaný)

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

  • 30. 8. 2017 14:08

    Filip Jirsák

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

  • 28. 8. 2017 9:16

    Filip Jirsák

    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.

  • 29. 8. 2017 13:04

    Filip Jirsák

    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.

  • 30. 8. 2017 7:26

    Filip Jirsák

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

  • 28. 8. 2017 12:08

    Lol Phirae (neregistrovaný)

    V textu, který citujete, jsem o rychlosti nepsal nic.

    No jistě, viz "ničemu nevadí, když to bude trvat měsíce nebo roky."

    No, tak jsme si odbyli pondělní dávku Jirsákových plků, nejvyšší čas jít na oběd.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).