Názor ke zprávičce Třetina českých e-shopů má bezpečnostní problémy od Filip Jirsák - Jak těmto lidem chcete „prodat“ řešení postavené na...

Jak těmto lidem chcete „prodat“ řešení postavené na asymetrické kryptografii?
Já lidem nechci prodávat řešení postavené na asymetrické kryptografii. Já bych se spokojil i s řešením založeným na klasických heslech, kde by prohlížeč neposílal heslo v otevřeném tvaru ani jeho ekvivalent. Uživatel by tím pádem mohl docela bezpečně používat všude stejné heslo, pokud by bylo dost silné na to, aby odolalo útokům hrubou silou. Proti dnešku by to byl pořád obrovský pokrok. Samozřejmě by byla ideální varianta, že by web povinně musel implementovat více algoritmů a uživatel by si mohl vybrat, zda chce používat heslo nebo asymetrickou kryptografii, ale to by bylo řešení hodné roku 2020 – mně by prozatím stačilo, kdybychom měli alespoň řešení hodné roku 2000.

O asymetrické kryptografii jsem psal jen proto, že jsem (marně) doufal, že si Scrappy Coco uvědomí, že server opravdu nemusí znát nic, co by bylo možné zneužít pro přihlášení.

Existují i API pro správce hesel. Má to Android, má to iOS.
Desktop má pořád ještě na webu docela silné zastoupení.

V praxi to ale funguje IMHO mnohem lépe než hypotetické dnes publikované řešení za pět let.
Nefunguje. Jaký je podíl uživatelů, kteří používají správce hesel, a navíc ho používají správně – tj. používají unikátní generovaná hesla? Ne, nebude fungovat nic založeného na tom, že se musí uživatel o bezpečnost aktivně starat a ještě si komplikovat život. Jediné reálné řešení je takové, že prohlížeče prostě postupně znemožní posílat hesla přes webové formuláře. Stejně jako postupně tlačí na HTTPS.

Jistě tu je určitý prostor něco pokazit v případě třeba generování tokenu, museli bychom to ale srovnávat s jinou variantou, která by nejspíš část potenciálních chyb vyřešila a část vytvořila.
Běžný přístup je, že se vytvoří identifikátor session, uloží se do cookie (v horším případě do URL) a posílá se s každým požadavkem. Některé weby ještě ani nemají implementován HttpOnly session cookie. Tím se jenom obchází to, že prohlížeče neimplementují pořádný způsob autentizace. A vytváří to zcela novou třídu problémů – únosy sezení nejsou možné, když je autentizován každý HTTP požadavek. Stejně tak je spousta útoků založena na tom, že uživatel heslo vyplňuje do webové stránky. V tomto případě má alternativní řešení opravdu podobný typ útoku – bylo by možné snažit se napodobit dialog prohlížeče pro zadání hesla. Jenže prohlížeč má mnohem víc možností, jak se tomu bránit, než webová stránka.

Pokud ale varování bude na každé druhé stránce, lidé to přestanou vnímat. A podobně pokud varování nebude vypadat jako dostatečná hrozba.
Nepřipadá mi, že by tlak prohlížečů na zavádění HTTPS byl neúčinný. Nebo tlak na to, aby se přestaly používat SHA-1 certifikáty nebo staré verze SSL a TLS. Zdá se, že autoři prohlížečů dobře zvládají to časování, kdy nejprve jen „straší“ provozovatele webů a skutečné varování zapnou až v případě, kdy se s ním uživatel reálně potká jen málo často.

Myslím, že není náhoda, že zmíněné upozornění prohlížeče (byť není dokolané) přišlo teprve relativně nedávno v době masivního nasazení HTTPS a se snahou to omezit na případy, kdy by to uživatele nejspíš mohlo zajímat.
Varování při odeslání formulářových dat přes HTTP měl už Internet Explorer 4.0. Mozilla mu tenkrát konkurovala mimo jiné tím, že tuhle hlášku odstranila. To varování přece hned nemusí být modální dialog, který bude muset uživatel potvrdit. Nejspíš by se zase začalo nějakou červenou ikonou buď u políčka pro heslo nebo v adresním řádku. Nebo by prostě stačilo v políčku pro heslo maskovat vstup – sice by to bylo plus z hlediska UX a bezpečnost by to nijak výrazně nesnížilo, ale ty správné uživatele by to nejspíš správně vyděsilo.