Názor ke zprávičce Třetina českých e-shopů má bezpečnostní problémy od Filip Jirsák - Jenže k pohodlí je právě potřeba to API....

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

Tvůrci prohlížečů a webových standardů jsou ti rozhodující. Na provozovatele webů mají dostatečné páky – jak je vidět na příkladu HTTPS nebo verzí TLS. Jistěže se tomu někteří uživatelé i provozovatelé webů snaží vzepřít. Ale v souboji provozovatel webu × prohlížeč tahá provozovatel webu za podstatně kratší konec provazu. Ano, web může použít CSS a JavaScript – ale prohlížeč u spousty uživatelů zná heslo, protože je uložené v interním password manažeru. Takže je triviální detekovat, že uživatel někam napsal text, který je shodný s jeho heslem. A i kdyby automatická detekce nefungovala, prohlížeč pořád může mít blacklist, který bude ručně spravovaný.

Tomu se už přiblužujeme…
Nepřibližujeme. Dnes musí uživatel ručně otevřít kontextové menu políčka, tam vybrat vygenerování hesla; strachovat se, že si správce hesel rozumí se stránkou alespoň do té míry, aby pak to heslo šlo uložit; potvrdit správci hesel uložení hesla, ne úplně výjimečně ručně upravit záznam ve správci hesel a někdy ho dokonce ručně vytvořit. To dělají přesvědčení uživatelé správců hesel, ale běžný uživatel tohle nikdy dělat nebude. Nehledě na to, že často selže už první krok, generování hesla – protože heslo obsahuje pro daný web nepovolené znaky, je příliš dlouhé apod.

Pak máte stateless správce hesel, se všemi nevýhodami, které jsem zmiňoval.
Nikoli. Řešení, kdy se bude přihlašovat přes API a nebude se zasílat heslo v otevřeném tvaru, funguje se stateful správci hesel, stateless správci hesel i bez správců hesel.

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. On je úplně zvrácený ten předpoklad, že ty statisíce nebo miliony provozovatelé webů po celém světe se chovají slušně. Vždyť víme, že se běžně prodávají e-mailové adresy i osobní údaje – proč bych si měl myslet, že s hesly je to jinak? Že zrovna k heslům se všichni chovají uctivě?

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

A pokud jde o správce, kteří to udělají úmyslně, tady si taky nepomůžete. Jak jsem psal výše, s možností vyrobit si něco jako password field vlastními silami těžko zabráníte tomu, aby získal heslo v plaintextu.
Pomůžu. 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. Stejně jako dnes reagují na to, když web nemá „zelený zámeček“.

U provozovatelů, kteří hashují hesla správně a nemají zlé úmysly hesla na vydolovat, si nepomůžete. Naopak, přinesete nová rizika související třeba s komplikovanou změnou způsobu hashování. Vámi navrhované řešení je ve skutečnosti technicky složité, vezmeme-li v úvahu stávající databáze hashů hesel, jejich solí, změny v hashovacích funkcích a jejich parametrech. Tato složitost vede k riziku chyb.
Za prvé, vy to jako uživatel z venku nevíte, zda provozovatel webu správně hashuje. On může deklarovat, že to dělá, může být přesvědčen o tom, že to dělá správně, a stejně může mít někde chybu a třeba omylem logovat hesla v otevřeném tvaru do logu.

V té nejjednodušší variantě, kdy by se z prohlížeče při přihlášení posílal stále stejný hash, by provozovatel nic měnit nemusel – prostě by jako heslo dostal hash zakódovaný třeba v BASE64 nebo jenom hexadecimálně, takže by to pro něj bylo, jako kdyby si uživatel zvolil dlouhé textové heslo. Jediný problém by byl při přechodu na tento nový systém přihlašování, kdy by si provozovatel musel nejprve vyžádat heslo v otevřeném tvaru, aby si na jeho základě mohl vypočítat hash. Ale to není žádný problém, pro většinu uživatelů by to provozovatel zvládl během běžného přihlašování, než by se přepnul na nové API.

Vizte výše, vaše řešení přináší spíše komplikace než zvýšení bezpečnosti.
Nikoli, nenapsal jste jedinou komplikaci, kterou by přinášelo moje řešení.

Máte řádově složitější problém než zaříznutí staré verze TLS nebo použití TLS pro formuláře.
Ne, ten problém je řádově jednodušší. 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. Z vypnutí podpory starých verzí TLS je nějaký užitek teprve tehdy, když se podpora v prohlížečích reálně vypne – a pak web používající jen starou verzi TLS prostě přestane fungovat. Za druhé, implementace TLS je mnohem náročnější a jediné místo, kde to lze implementovat, je webový server. Přihlašování lze řešit buď přes HTTP API nebo v kombinaci s JavaScriptovým API (čistě JavaScriptové API by nebylo vhodné). Obojí mají v ruce vývojáři webových aplikací, tedy to mohou implementovat hned, bez ohledu na to, zda to jejich server podporuje či nepodporuje.

řešit side channely
Ty musí provozovatelé webů řešit teď. Pokud by za ně zodpovědnost za nakládání s heslem převzal prohlížeč, o tuhle starost přijdou.

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.

v mnoha případech vlastně prakticky nezvýšili, protože již hashují a solí správně
Jak je vidět i na vašem příkladu, v mnoha případech by tím bezpečnost prakticky zvýšili – protože by si nemysleli, že dělají všechno správně, když správně solí a hashují. Těch možností, co dělat špatně, je mnohem víc. Právě proto nemá heslo v otevřeném tvaru vůbec opustit chráněnou část prohlížeče.

Začne se to obcházet vlastní implementací password fieldů, což ztíží práci password managerů.
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. A ostatní – podívejte se, jak je dnes rozšířené HTTPS. Spousta lidí brblá, že pro jejich web to není potřeba, ale podíl HTTPS pořád roste. Takže někteří z ostatních by to implementovali rovnou, někteří by chvíli přesvědčovali uživatele, že ten červený vykřičník v políčku s heslem mají ignorovat, že je to zas nějaký výmysl prohlížečů, a pak by to stejně implementovali. A někteří by to zkoušeli obejít, ale prohlížeče a hlavně uživatelé by to odhalili – a ono by to pak přestalo bavit i tyhle provozovatele. Koneckonců, pokud by pak uživatelé věděli, že „zadávám heslo přímo do webové stránky heslo musím považovat za veřejné“, sami by se pídili po tom, jak na takovém webu použít heslo, jehož zveřejnění by jim nevadilo.