Názor ke zprávičce Třetina českých e-shopů má bezpečnostní problémy od Filip Jirsá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
Prohlížeč zavolá webový server s požadovaným URL, které bude chráněné autentizací. Server odpoví kódem 401 Unauthorized a v hlavičce WWW-Authenticate pošle údaje nutné pro autentizaci – podporované protokoly, doménové jméno a výzvu. Prohlížeč získá login a heslo (z password manažera, od uživatele, jakkoli jinak) a pošle serveru spolu s požadavkem zvolený typ autentizace, login a podpis požadavku, přičemž podpis vznikne z údajů, které má uložené server, z výzvy a z klíčových údajů požadavku (metoda, URL, další kritické hlavičky). Údaje, které má uložené server, mohou být např. hash loginu, doménového jména a hesla, nebo to může být třeba náhodně vygenerovaný klíč, pokud uživatel používá stateful password manažer.

Změna hashování se bude řešit podobně, jako změna hesla – prohlížeč pošle serveru nové údaje, které si má server uložit. Akorát změna hashování proběhne bez zásahu uživatele a jen v případě, že to bude změna na bezpečnější algoritmus.

Sůl je uživatelské jméno, pepř je doménové jméno.

Pokud o přihlášení neexistujícího uživatele bude probíhat stejně, jako dnes. Prohlížeč pošle login a přihlašovací údaje, server zjistí, že takového uživatele nezná, a odpoví jak uzná za vhodné – že uživatel neexistuje, že má uživatelské jméno chybný formát, nebo že uživatelské jméno neexistuje nebo je chybné heslo. Nebo jakkoli jinak, jak bude chtít.

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?
Co bych měl tajit? Dokud se uživatel nepřihlásí a nemůžu heslo přehashovat, buď budu držet starou slabou variantu hashe a nebo hash vymažu a při příštím přihlášení bude uživatel muset heslo resetovat. Ony by se ty hashovací funkce zase neměly měnit každé dva měsíce, a pokud se někdo nepřihlásil tři roky, asi mu ten reset hesla nebude tak vadit. Spousta uživatelů ho stejně bude muset provést rovnou, protože si heslo stejně nebudou pamatovat.

Jak si to poradí s offline útoky na hashe ve srovnání se stateful password managerem?
Nic nebrání uživateli používat stateful password manager, takže srovnávat netřeba – když chcete, můžete použít obojí. Za to je ale potřeba offline útoky na hashe porovnávat s offline útoky na hesla v otevřeném tvaru. Protože to je současný stav a od něj se chceme posunout do bezpečnějšího stavu. A – přiznejme si to – hesla v otevřeném tvaru si v offline útocích nevedou moc dobře.

Až na to odpovíte, můžeme se bavit třeba o side channels, které jsem měl namysli.
Ano, můžeme se o tom bavit. Těším se na porovnání side channels s tím, že se heslo pošle v otevřeném tvaru. Jestli se vám podaří dokázat, že existuje ještě nebezpečnější způsob autentizace, než posílání hesla v otevřeném tvaru, bude kvůli vám muset být zavedena Nobelova cena za IT.

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í?
Měnit to v prvním kole budou všichni, kdo dnes deklarují, že hesla ukládají bezpečně. Protože to bude důkaz místo slibů. Další v pořadí to udělají ti, kteří dnes ukládají hesla bezpečně, ale nemluví o tom – protože jim na bezpečnosti záleží, nebo se bojí úniku hesel, a v obou případech získají zlepšení oproti současnému stavu. A jako bonus budou mít ten důkaz místo slibů.

No, a to pro prvotní rozšíření bohatě stačí. Benefity se projeví hned, jakmile to nasadí první web – protože budeme mít jistotu, že ten web zachází s hesly bezpečně a hesla z něj nemohou uniknout.

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ě.
Vy jste byl posledních patnáct let mimo naši sluneční soustavu? Nebo si vážně nepamatujete, jak se prosazovalo a prosazuje HTTPS? Nejprve to chtěl, kdo chtěl a zaplatil si certifikát, pak se postupně začalo mluvit o tom, že by tom měl mít aspoň každý, kde se posílají hesla nebo jiné citlivé údaje, pak přišel Let's Encrypt, který dramaticky snížil náklady, dnes už některé funkce prohlížečů jsou dostupné jen přes HTTPS, prohlížeče klidně zobrazují červený zámeček nebo dokonce uživatele na stránku vůbec nepustí, a už se řeší označován HTTP webů jako nezabezpečené. Tak mi netvrďte, že to nejde.

To řeší stateful password manager.
Neřeší, protože drtivá většina uživatelů password manažer s generováním hesel nepoužívá. Přičemž jakékoli bezpečnostní řešení, které závisí na tom, že uživatel dobrovolně dělá pro bezpečnost něco navíc, je špatné. Aby to opravdu pomáhalo bezpečnosti, uživatel nesmí mít možnost chovat se nebezpečně, nebo to pro něj alespoň musí být značně komplikované.

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ů.
Pořád je ta budoucnost mnohem blíž, než budoucnost, kdy spousta uživatelů dobrovolně používá správce hesel.

tedy budou muset nechat nějakou dobu klasický formulář
Vzhledem k tomu, že ten webový formulář používají už o dvacet let déle, než by bylo vhodné, další tři pět let už je nezabije. Vždyť nejde o zhoršení stavu, jde jen o prodloužení dnešního nevyhovujícího stavu. Mimochodem, vaše řešení s password managery tohle řešení přes webové formuláře prodlužuje donekonečna – tak která varianta je horší?

Už si představuju hovor zaměstnance, který chce tu změnu implementovat
U toho by snad měl být někdo, kdo bezpečnosti aspoň trochu rozumí, ne? Ten váš rozhovor je nerealistický – reálně by to v téhle situaci bylo: „Nehashujeme, máme je bezpečně uložená v databázi a do databáze se nikdo nedostane.“

No, mnohem realističtější mi přijde, že někdo bude web dělat více friendly pro password manage
Já bych to upřesnil. Někdo se bude snažit udělat web password manager friendly. Ale zjistí, že se každý password manager chová jinak, a že to nejde udělat tak, aby vyhověl všem. Protože k tomu by bylo potřeba API, aby se web s password manažerem dohodly, ne aby web hádal, co asi chce password manager, a password manager hádal, co asi chce web.

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á
Takovou analýzu, ze které plynulo to, že je to dané nevlídností k password managerům, bych fakt rád viděl.

To předpokládá, že máte správce hesel
Pro odhalení webu, který podvádí, stačí velmi málo uživatelů. I kdyby vhodné podmínky byly splněné u 0,1 ‰ uživatelů, pořád to je pro autory prohlížeče dost a dost materiálu.

U HTTPS jde o mnohem jednodušší problém s větším dopadem.
Nikoli, je to nesrovnatelně komplexnější problém, který se dotýká většího množství subjektů.

To, že si někdo může hesla přečíst po cestě, zní mnohem hůře.
To je právě ten problém, že se místo skutečné bezpečností řeší to, co jak nebezpečně „zní“. Každý si představí útočníka, který může po cestě odposlechnout údaje. Ale provozovatel webového serveru je vždy ten hodný, ten uživatelské údaje nikdy nemůže zneužít…

Blacklist není zrovna pěkné řešení…
Je to jen dočasné řešení, než se ty podvádějící weby podaří úplně vymýtit. Vzhledem k tomu, že se whitelist používá třeba pro HSTS preload, kde je to dočasně trvalé řešení, bych ošklivost blacklistu vůbec neřešil. Ostatně podobné blacklisty se používají třeba pro detekci webů napadených malwarem.