Názor ke zprávičce Třetina českých e-shopů má bezpečnostní problémy od Vít Šesták - > Server odpoví kódem 401 Unauthorized a v...

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

OK, s tímto se už pracuje lépe. Ale ještě to není úplně rozvedené. Řekněme, že mezi možnosti bude patřit bcrypt a scrypt s různými parametry. Někdy vznikne potřeba přehashovat všechny uživatele. Zřejmě tedy bude existovat mechanismus, který umožní přihlašovat různé uživatele s různými hashovacími funkcemi nebo jejich parametry. Z Vašeho popisu mi není jasné, jak tento mechanismus bude vypadat. A toto právě je jedna z těch věcí, která není až tak jednoduchá – zkuste to navrhnout tak, aby z toho nešlo poznat dlouho nepřihlašovaného uživatele ani existujícího/ne­existujícího uživatele. Možná přijdete s nějakým geniálním a prakticky použitelným řešením, možná uznáte, že toto není až taková sranda.

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

Nedoporučuje se mít veřejně dostupnou sůl. Útočník si pak může pro konkrétního významného uživatele předpřipravit rainbow table. Pokud útok vzbudí pozornost (třeba nějaký monitoring anomálií provozu), má útočník větší šanci heslo zneužít ještě před reakcí.

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

Obojí srovnání má smysl. Můžeme srovnávat všechny čtyři varianty (kombinace).

> Pořád je ta budoucnost mnohem blíž, než budoucnost, kdy spousta uživatelů dobrovolně používá správce hesel.

Problém je v tom, dlouho ty benefity nejsou naprosto žádné. Až časem by teoreticky mohly být, pokud budou lidé dostatečně uvědomělí. K čemuž jsem skeptický.

Oproti tomu password managery přinášejí pozvolné zlepšování bez nutnosti spolupráce velké skupiny lidí. Tu někdo vylepší password manager, tu někdo vydá článek o password managerech, tu někdo třeba upraví registrační formulář. Benefity každého kroku mohou být sice relativně malé, ale zde skoro každý malý krok dává smysl, aniž by se spoléhal na nejistou spolupráci mnoha dalších stran. To je hlavní důvod, proč password managery vidím v reálném světě jako vítěze nad oběmi nastíněnými alternativami (asymetrická kryptografie a Vaše nové schéma pro HTTP Auth), nezávisle na tom, co je lepší. Teda vlastně asymetrická kryptografie by možná mohla být přirozenou evolucí password managerů (ze kterých by se staly access managery).

> vaše řešení s password managery tohle řešení přes webové formuláře prodlužuje donekonečna – tak která varianta je horší?

Čemu to vadí při používání password manageru?

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

Myslíte něco jako https://developer.apple.com/documentation/security/password_autofill/enabling_password_autofill_on_an_html_input_element ?

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

Spousta webů používá například Google Analytics, které umožní mimo jiné najít místa, kde uživatelé opouští web. Bude-li to registrační formulář, dává to prostor k zamyšlení. Pravda, stále tu může být více důvodů. Ale přijde mi realističtější, že lidé budou brát zpětnou vazbu odtud (s motivací vlastního zisku), než že uvědomělí vývojáři přesvědčí uvědomělý management, že je potřeba věnovat úsilí postupnému přechodu na nový autentizační mechanismus pro blaho lidstva, bez přímé vazby na zisk firmy.

> U toho by snad měl být někdo, kdo bezpečnosti aspoň trochu rozumí, ne?

Záleží, kdo s kým má takový rozhovor. Šéf obvykle má nějaký přehled, případně si něco nechá vysvětlit. Pointa nicméně byla, že si nedovedu představit, jak přesvědčuju šéfa nebbo kolegu, že něco takového je potřeba udělat a že stojí za to tomu věnovat čas. Vy si to dovedete představit?

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

To záleží. Jednak to neřeší cílené útoky, jednak je to http://www.lamer.cz/quote/50132 .

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

OK, kolik jich bude? Řékl bych, že pár. Co pak dál? Varování na plain HTTP se taky neobjevilo ihned poté, co to zavedlo pár webů.

> Nebo si vážně nepamatujete, jak se prosazovalo a prosazuje HTTPS?

Pamatuju. Jen si nemyslím, že ten postup lze úplně znovupoužít zde. Třeba omezování funkčnosti webů se dělá těžko, když většinu funkcí může stejně dobře chtít i stránka, která nikde žádné přihlašování nemá.

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

No. Dnes jsou možnosti něco podobného implementovat v JS. Benefity i nevýhody by byly zhruba podobné. Proč se to tedy neprosadilo již dnes? A proč si myslíte, že řešení vyžadující dostatečně nový prohlížeč dopadne lépe?

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

Mám udělat mockup password fieldu, který to bude splňovat?

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

HTTPS stačí implementovat na serverech a v prohlížečích. Občas kvůli tomu je potřeba dělat nějaké úpravy, jako třeba změnit hardcodované „http://“. Není potřeba řešit žádnou migraci hashů hesel a nové způsoby autentizace v řádově větším množství autentizačních knihoven.

> To je právě ten problém, že se místo skutečné bezpečností řeší to, co jak nebezpečně „zní“.

Ale ono to je právě to, co má vliv na to, jestli se tím bude někdo zabývat. Ne vždy z toho jsem nadšený, ale je to realita, se kterou musíme pracovat. Budeme-li tuto realitu ignorovat, můžeme udělat krásné řešení reálného problému, který ale prakticky nikdo nepociťuje. Jaké bude mít takové řešení dopad.

> Je to [blacklist] jen dočasné řešení, než se ty podvádějící weby podaří úplně vymýtit.

Jak docílíte stavu, že nikdo nebude podvádět?