Názor ke zprávičce Třetina českých e-shopů má bezpečnostní problémy od Filip Jirsák - Vy se pořád věnujete jen technické stránce věci...

Vy se pořád věnujete jen technické stránce věci a úplně ignorujete lidi. Aby problém vyřešili správci hesel, musel byste ke změně zvyků přesvědčit několik miliard lidí. Aby to vyřešily prohlížeče, musíte přesvědčit několik stovek lidí, kteří mají reálně vliv na webové standardy a jejich implementaci. Takže k praktickému vyřešení mají správci hesel mnohem dál.

Správci hesel se samozřejmě mohou evolučně zlepšit. Mohou se dokonce zlepšit tak, že nebude potřeba, aby uživatelé změnili své chování. Aby to celé vedlo k tomu, že uživatelé nebudou mít stejné heslo na více službách, které zároveň to heslo znají, musí se začít už u vytváření hesla. Nemůže to fungovat tak, že kdokoli bude po uživateli chtít, aby si zadal nové heslo. Ne, jediná možnost, kdy to bude fungovat, je ta, že někdo uživateli to heslo vytvoří. Aby to bylo spolehlivé a uživatelé to opravdu používali, nemůže to být implementované tak, že se správce hesel bude pokoušet uhodnout, která stránka zakládá nový účet. Naopak, musí to dát vědět ta stránka. To samé platí pro přihlášení heslem – správce hesel musí vědět, ne hádat, že se uživatel chce přihlásit, k jakému webu se chce přihlásit a musí vědět, jak má předat přihlašovací údaje. Takže musí vzniknout nějaké API, kterým spolu budou komunikovat správce hesel a webová stránka nebo webový server. No a když už takové API bude existovat, kdo říká, že přes něj musí putovat heslo, které uživatel zadal na klávesnici? I kdyby uživatel trval na tom, že si nenechá heslo vygenerovat správcem hesel, ale zadá si svoje, může přece prohlížeč tohle heslo zahashovat (spolu s dalšími údaji) a přes to API poslat až ten hash. Pokud to budou všechny prohlížeče dělat stejně, bude dál fungovat to, že uživatel kdekoli zadá svoje heslo a přihlásí se.

Nebo-li vaše řešení se správci hesel nebude fungovat, pokud uživatel z nějakého důvodu správce hesel nechce používat. A aby fungovalo se správcem hesel, stejně vyžaduje vytvoření nějakého API. Přičemž když se to API jenom malinko dotáhne, bude to to mnou navrhované řešení, které bezpečnost zvýší všem, ať správce hesel používají nebo nepoužívají, a zároveň odstraní celé třídy problémů způsobené tím, že se dnes přihlašujeme přes webové formuláře.

Naproti tomu vy, pokud to dobře chápu, vidíte cestu v nějakém zákazu
Ne, vidím cestu v tom, že prohlížeče nabídnou novou metodu autentizace, a postupně budou tlačit na to, aby se přestala používat metoda založená na webových formulářích. Tak, jako postupně tlačí na používání HTTPS, aktuálních verzí TLS apod.

Toto zhruba splňuje i password manager s hlavním heslem.
Akorát to vyžaduje používání správce hesel, pokud uživatel používá více prohlížečů (např. v počítači a v mobilu), vyžaduje to synchronizaci hesel. Moje řešení dává uživateli volbu – funguje i se správcem hesel i bez něj.

No, muselo by se to ale implementovat, a to i na webových stránkách.
Ano, ale na to mají prohlížeče páky, jak víme z příkladů s HTTPS, verzemi TLS apod.

Ti, kteří dnes ukládají hesla v plaintextu nebo hashují slabě, to nejspíš stejně neimplementují.
Ale implementují, protože to, že by to neimplementovali, by bylo na první pohled vidět, prohlížeč by na to uživatele pokaždé upozornil. To, že někdo zachází špatně s hesly, není vidět do té doby, než ta hesla uniknou.

Je to pokrok ve srovnání se stateful správci hesel je to krok zpět.
Jenže to, že budou všichni používat stateful správce hesel, je jen vaše zbožné přání. Já neřeším, jaké jsou teoretické možnosti. Já píšu o tom, co se dá reálně dělat pro zvýšení bezpečnosti na webu.

Co si pod tím mám představit? Když na jednom serveru prolomím heslo uživatele, který všude používá stejné heslo, udělám to pro toho uživatele jednou a mám jeho heslo všude.
Dneska si to heslo uživatele jako provozovatel webu prostě přečtete ze své databáze. Kdybyste už od prohlížeče dostal jen hash login+heslo+doména, budete ta hesla muset louskat uživatele po uživateli (protože součástí hashe je i login, takže i dva uživatelé se stejným heslem na vašem serveru budou mít různé hashe).

Přijde mi, že chcete technologii, která něco řeší relativně dobře, zpětně kompatibilně a pomalu, ale jistě se dostává do používání a zpřístupňuje masám (password managery), nahradit něčím zatím neexistujícím, méně bezpečným a bez pořádného řešení zpětné kompatibility.
Já nechci správce hesel nahrazovat, v mém řešení fungují stejně dobře, jako dnes. Já jen nesdílím vaše přesvědčení, že do pár let budou správce hesel používat všichni uživatelé. Moje řešení je podstatně bezpečnější, než používání správců hesel bez samostatného API pro komunikaci mezi webem a správcem hesel. A zpětná kompatibilita je přesně to, co v tomto případě chceme porušit – pokud budou mít provozovatelé webů dál přístup k heslům uživatelů, kteří to samé heslo používají na spoustě jiných webů, není potřeba nic řešit, takhle to funguje i dneska. Takže to zrušení zpětné kompatibility, tedy odstranění hesel z databází provozovatelů webů, je cíl.

Jsem pro použití httponly, kde to jde, ale nepřeceňoval bych význam. Když už uděláte XSS, můžete si z prohlížeče oběti udělat proxy a session cookie nepotřebujete. Nebo můžete zobrazit přihlašovací dialog, ani pozorný uživatel nemá moc šanci si všimnout, že je něco špatně, doména v adrese přece sedí…
To záleží na tom, co vše si s tím XSS můžete dovolit. Každopádně „zabezpečení“ pomocí session cookie je velmi děravé a opět musí všichni autoři webů implementovat spoustu různých ochran jenom kvůli tomu, že prohlížeče neumožňují rozumně implementovat přihlášení jménem a heslem. Jednou z oblíbených ochran dříve bylo svázání session s konkrétní IP adresou…