Názor ke zprávičce Třetina českých e-shopů má bezpečnostní problémy od Vít Šesták - Možná je na čase tomu Vašemu řešení dát...

Možná je na čase tomu Vašemu řešení dát přesnější obrysy:

* Co bude ta hashovací funkce? Půjde o jednu funkci, nebo bude konfigurovatelná?
* Pokud bude konfigurovatelná, jak se bude konfigurovat?
* Jak se bude řešit změna hashování?
* Jak se bude řešit salt?
* Jak se bude řešit pokus o přihlášení neexistujícího uživatele? Neleakne zde informace, že ten uživatel neexistuje?
* Když se uživatel nějakou dobu nepřihlásil, a tedy nemohl přehashovat svoje heslo dle libosti, jak to utajíte, když se hashuje v prohlížeči?
* Jak si to poradí s offline útoky na hashe ve srovnání se stateful password managerem?

Už na toto může být problém odpovědět nějak konzistentně. Až na to odpovíte, můžeme se bavit třeba o side channels, které jsem měl namysli. Ale možná Vám to po sepsání bude jasné. Já jsem kdysi taky byl pro podobné schéma, ono to na první pohled vypadá dobře, ale jak přibývají detaily, člověk zjišťuje, jak komplexní problém to je.

> Na provozovatele webů mají dostatečné páky

Jak jsem psal, nemyslím si, že by zde tato analogie fungovala, a psal jsem proč. Pokud si to myslíte, zkuste napsat, jak takovéto páky vypadají. Představte si, že vámi navržené řešení dnes implementovaly prakticky všechny prohlížeče. Co se bude dít dál? Kdo bude co na existujících stránkách měnit a jakou k tomu bude mít motivaci? Kdy se projeví první benefity Vašeho řešení?

Nechci odpověď „prohlížeče budou viditelně varovat uživatele“. Prohlížeče prakticky nemohou varovat před něčím, co dělá každý, protože to nikdo nebude brát vážně. Prohlížeče mohou varovat před něčím, co se děje vzácně. Což znamená, že prohlížeče touto cestou spíše pomohou v závěrečné fázi, ale do té doby to musí hnát jiné síly.

> Jenže k pohodlí je právě potřeba to API. Pokud password manažer nebude ve 40 % případů fungovat, protože se mu nepodaří uhodnout, co je na stránce, nebude to pohodlné.

Myslím, že těch 40 % je dost nadsazené číslo. Ale i kdyby, dovedu si představit postupné evoluční zlepšování. Bude motivací každého správce webu mít web kompatibilní s password managery, jinak přijdou o uživatele. Dopad tu je celkem jasný.

> Nepřibližujeme. Dnes musí uživatel ručně otevřít kontextové menu políčka, tam vybrat vygenerování hesla;

Není vždy pravda. Ukazoval jsem screenshot, kde rovnou po ťuknutí do políčka s heslem jsem dostal tlačísko na vygenerování hesla. A jde to posouvat ještě dál – tlačítko pro vygenerování bude to hlavní, abych napsal něco vlastního, musím něco rozkliknout.

> > To předpokládá, že provozovatel ukládá hesla v plaintextu.
> Což musíte předpokládat u každého provozovatele, u kterého si nejste jist opakem.

Promiňte, ale toto je jednoznačně vytrženo z kontextu. Napsal jsem toto: „To předpokládá, že provozovatel ukládá hesla v plaintextu. Neříkám, že se tak nikdy neděje, ale po někom takovém těžko očekávat, že přejde na nový způsob přihlašování a že to implementuje správně. Ono to není až tak jednoduché udělat správně.“

> Dříve bylo přihlašování implementováno přímo ve webovém serveru. To teprve s tím, jak se přešlo na přihlašování přes webové formuláře, začalo být nutné, aby si to každý naimplementoval znovu.

No, v obou případech si to lze implementovat vlastními silami a v obou případech lze využít knihovny.

> Navíc to, co jste napsal, je argument pro moje řešení. Pokud není jednoduché implementovat správně přihlašování, pak samozřejmě do takové implementace nebudu strkat svoje heslo v otevřeném tvaru, ale poskytnu jí jenom hash. Pokud bude na implementaci něco špatně, přinejhorším se nepřihlásím – ale nemůže nastat to, že moje heslo unikne ven

Pokud je na implementaci něco špatně, je určitě správně tam nestrkat heslo, které by se dalo využít jinde. To řeší stateful password manager. Váš návrh to řeší částečně (hash odvozený z hesla je náchylný offline útokům), a přináší komplexitu. Mohou uniknout i další údaje, jako poslední přihlášení, nebo zda uživatel vůbec existuje. A i to může na některých webech být citlivý údaj. Je sice těžké některé údaje ochránit stoprocentně, ale to není důvod zavádět falší problémy. Pokud o tom mám diskutovat dál, poskytněte detailnější návrh, jak jsem zmiňoval na záčátku.

> Protože postupem času bude uživatelům divné, že mají heslo zadávat do webové stránky a ne do speciálního dialogu prohlížeče.

Možná. Někdy časem. Pokud se změní chování uživatelů, k čemuž jste sám byl skeptický. A hlavně to znamená, že reálný bezpečnostní benefit odsouváte někam do vzdálené budoucnosti, až totéž udělá spousta provozovatelů webů.

> Nikoli, nenapsal jste jedinou komplikaci, kterou by přinášelo moje řešení.

Vizte výše, dejte přesnější návrh, možná si těch komplikací všimnete i sám.

> Za prvé, je možné pořád dál používat formulářové přihlašování – jediné, co hrozí, je že v určitém okamžiku někdy v budoucnosti před tím bude prohlížeč varovat a případně ještě později se to bude snažit blokovat.

A teď si představte, že chcete u zaměstnavatele obhájit, že budete svůj čas věnovat podobné úpravě. Jak vysvětlíte benefity? Kdy přijdou? Někdy možná, až se prohlížeče rozhodnou brojit proti formulářům s hesly na webech?

> > Začnou také řešit hashe hesel stávajících uživatelů, které z různých důvodů nejsou kompatibilní s novým schématem.
> Což dělají pokaždé, když přecházejí na nový hashovací algoritmus. Pokud to dělají opravdu správně, jak tvrdíte, už tenhle problém museli v minulosti řešit.

To ano, ale mají poněkud volnější ruce. Mohou počítat s tím, že dostanou heslo v plaintextu a mohou si to pořešit podle sebe. Tady se velmi reálně může stát, že jejich stávající mechanismus hashování nebude kompatibilní s Vaším návrhem, a tedy budou muset nechat nějakou dobu klasický formulář, jak píšete.

> Kdo to myslí s bezpečností opravdu vážně, ten zajásá, že má konečně k ruce nástroj, se kterým tu bezpečnost opravdu může řešit.

Už si představuju hovor zaměstnance, který chce tu změnu implementovat:

A: Rád bych zde implementoval nový způsob přihlašování.
B: Co to přinese a kolik to bude stát MD?
A: Umožní to hashovat hesla přímo u zákazníka, takže to bude bezpečnější. U nás se budou ukládat hashovaná, takže kdyby se někdo dostal k databázi…
B: A teď je nehashujeme?
A: No, hashujeme, ale až na serveru.
B: Takže když se někdo dostane k DB, stejně dostane jen zahashovaná hesla, ne?
A: No ale někteří uživatelé zaměření na bezpečnost…
B: Ti si to vyřešili password managerem. A konkurence nic podobného taky nedělá. Získáme tím tak 0.0001 % navíc, ta práce se nezaplatí.

No, mnohem realističtější mi přijde, že někdo bude web dělat více friendly pro password manager, protože si někdo z analýz vyčetl, že registrační nebo přihlašovací stránka často bývá ta poslední, na kterou se uživatel podívá. Tady je ekonomický dopad zřejmý.

> podívejte se, jak je dnes rozšířené HTTPS.

U HTTPS jde o mnohem jednodušší problém s větším dopadem. To, že si někdo může hesla přečíst po cestě, zní mnohem hůře. Úprava stránky routerem taky. Náročnost řešení záleží. Někdy si to může vyžádat nový hosting nebo upravit absolutní URL, někdy (hlavně v počátcích) vyřešit 3rdparty skripty. To může být pořád nic proti řešení bezpečné implementace Vašeho návrhu.