Vlákno názorů k článku „Jak ukládáme hesla, vám z důvodu bezpečnosti neprozradíme“ od Filip Jirsák - Tohle se ale míjí s podstatou problému. Když...

Tohle se ale míjí s podstatou problému. Když vám někdo řekne, jak ukládá hesla, můžete mu věřit a nemusíte. A i když bude dotyčný mluvit podle svého nejlepšího vědomí a svědomí, pořád se dozvíte akorát to, jak si myslí, že ukládají hesla – jenže v implementaci může být chyba nebo hesla mohou unikat někudy po cestě.

Správné řešení je, že se provozovatel webu heslo vůbec nedozví. Aby to bylo bezpečné, heslo nesmí nikdy opustit webový prohlížeč – prohlížeč ho má zahashovat a posílat jedině hash (i při registraci).

Tlačit na provozovatele, aby prohlásili, že hesla hashují, povede k jedinému – provozovatelé prohlásí, že hesla hashují. Ostatně to, že v roce 2016 není přihlašování pomocí hashů standard a že ani neexistuje norma pro registraci, která by provozovateli webu nezasílala heslo, ale jen hash, to je ostuda všech lidí „od webu“.

Nepsal jsme o hashi hesla a myslel jsem právě HTTP Digest, CRAM a podobné.

Předávání hesla v otevřeném tvaru provozovateli webu a spoléhání na to, že ho nikdo cestou neodposlechne, že ho nezneužije provozovatel a že s ním dokáže pracovat tak, aby ho nezneužil někdo jiný, to také nefunguje. Rozdíl je v tom, že standardizovat nějakého nástupce HTTP Digest jde a není to tak složité, donutit všechny provozovatele webu, aby s hesly zacházeli bezpečně, je nemožné. Mimochodem, i HTTP Digest s MD5 by byl milionkrát lepší, než se přihlašovat webovým formulářem a session cookies.

Tohle moc nechápu. Pokud jediné, co odejde z prohlížeče, je hash, čím se to liší od situace, kdy jediné, co odejde z prohlížeče, je heslo? Ano, ten hash je sice výrazně silnější heslo než password123, takže ho asi nikdo neuhodne, ale pokud někdo odposlouchává komunikaci či pokud protistrana ten hash uloží tak, jak přijde (což by se imho stávalo častěji než ukládání plain hesel dnes, protože leckomu by přišlo zbytečné hashovat hash) a ta databáze unikne, jste na tom stejně. Přijde mi, že řešíte jen brute-force attack, což ale opravdu není vše.

Navíc mě napadá další problém, který ale možná má nějaké řešení, rád se ho dozvím. Uživatelé svůj účet chtějí používat v různých prohlížečích na různých zařízeních, přičemž všude by platilo, že pokud zadají své heslo, musí z toho vypadnout stejný hash (ten, který byl vypočítán při registraci, opomíjím situace, kdy by bylo možné říct, že dva různé hashe patří stejnému heslu, stejně jako možnost, že by server posílal nějakou sůl, přijde mi, že funkce, která umožňuje říct "ano, tento hash patří neznámému heslu se solí A a tento stejnému heslu se solí B", nebude zrovna bezpečná - ale třeba je tohle právě to, co už bylo vyřešeno).

To ale znamená, že hashovací funkce by musela být univerzální a závislá jen na zadaném heslu. Jenže pak by se daly použít úplně stejné metody pro brute-force attack jako dnes, akorát by se jim předřadila rainbow table pro tuhle funkci.

Když z prohlížeče odejde hash(web+heslo), nezná provozovatel původní heslo. Přičemž znalost hesla je to, co je problematické – protože lidé používají na více místech stejná hesla. Když uniknou hashe pro danou službu, je to problém jenom té služby.

Hashovací funkce má být univerzální, je závislá na heslu a na identifikaci serveru, sůl se nepřidává. Pro vlastní autentizaci se pak vytvoří hash toho prvního hashe a výzvy serveru, takže ani při odposlechnutí komunikace nezíská útočník údaje potřebné pro opakované přihlášení. I když to je při použití HTTPS méně zajímavé. Takhle funguje třeba HTTP Digest, novější protokoly fungují tak, že ani to, co má uložené provozovatel webu, nestačí pro přihlášení.

Mimochodem,i v prohlížeči pak může být místo hesla uložený ten hash (heslo + identifikace webu), takže heslo pak útočník nezíská ani z prohlížeče (může získat ten hash, kterým se přihlásí na ten konkrétní web).

Děkuji za vysvětlení, ale pořád mi to není úplně jasné, pokud vytvořím hash původního hashe a výzvy serveru a ten odešlu při autentizaci, tak aby ho server ověřil, musí být schopen udělat totéž, to znamená, že má ten původní hash někde u sebe uložený v otevřené podobě (či obecně tak, že původní hash získat lze). Je to tak?

Asi je to profesní deformace, ale opřít bezpečnost o to, že se k té databázi nedostane nikdo nepovolaný... Na to bych si fakt nevsadil. A zabránit MITM tím, že někde centrálně uchovávám vše potřebné k autentizaci... Určitě existují prostředí, kde to smysl dává, ale že by jím byl "internet obecně", to mi nepřijde.

Zajímavější by mohly být ty novější protokoly, kde k přihlášení data na serveru nestačí. Nějaký příklad? Takový, který je pořád použitelný pro situaci "uživatel se přihlašuje z mnoha prohlížečů na mnoha zařízeních a jediné, co má k dispozici (a co je tedy přítomno při všech pokusech o autentizaci), je heslo v hlavě", protože to je maximum, co se dá od většiny uživatelů očekávat.

"Když z prohlížeče odejde hash(web+heslo), nezná provozovatel původní heslo."

To je pravda, nicméně dnes se toto dá implementovat pouze pomocí JavaScriptu (případně pomocí JavaScriptu a Web Crypto API), což znamená, že provozovatel to heslo pořád znát může. Může totiž svůj JavaScriptu (třeba cíleně) upravit tak, aby browser heslo vlastně nehashoval a poslal v čitelné podobě a nikdo to nezjistí, bohužel.

Dnes se tedy toto nepoužívá, protože stále musím věřit provozovateli, že jeho kód je v pořádku a to se moc neliší od toho, že mu musím věřit, že moje heslo nezneužije. A pokud se ve speciálních případech (správce hesel apod.) něco takového používá, tak se používá protokol SRP, ale pro většinu běžných webů (ať už to znamená cokoliv) se to nehodí už třeba jenom z důvodu náročnosti implementace.

A to je právě ta ostuda, že už na to dávno neexistuje standard a dávno to není implementované v prohlížečích. Protože v tomto případě to technicky vyřešit jde, na rozdíl od prohlášení provozovatele webu, že s hesly určitě ale určitě zachází bezpečně.

Mimochodem, ta implementace v JavaScriptu by pořád byl závislá na session cookies. Výhoda přihlašování pomocí HTTP hlavičky Authorization je i v tom, že řeší problém únosu session, protože je autentizován každý jednotlivý požadavek.