Třetina českých e-shopů má bezpečnostní problémy

Stačilo by privátní klíč odvozovat deterministicky z osoleného hesla.

To už někoho napadlo....

https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Klíčové jsou prohlížeče.

Velká část uživatelů bude používat to, co jim poskytne prohlížeč. Obavu, že se nepřihlásí na jiném stroji, podle mne velká část uživatelů neřeší. Z těch, kteří to řeší, jich zase velká část zná synchronizaci hesel přes uživatelský profil v cloudu. Navíc kdyby prohlížeče zacházely s hesly příčetně, ta obava by byla neopodstatněná – uživateli by stačilo jediné heslo.

Problém s externími správci hesel je v tom, že jsou do prohlížečů dohackované. A všechny správce hesel jsou dohackované do webových stránek – vždy jen hádají, kam se asi má heslo předvyplnit, co je asi vytvoření nového hesla, co asi změna hesla. Navíc spoustu bezpečnostních problémů přináší to, že se hesla vyplňují do webové stránky, heslem je chráněný jediný požadavek a pak už vše závisí na nějaké podobě session identifikátoru.

Rozumná implementace by byla taková, že je autentizován každý požadavek, citlivé údaje (heslo) uživatel zadává jen do prohlížeče (nebo jeho rozšíření, ale prostřednictvím nativního UI, ne přes webovou stránku) a z prohlížeče se řídí přihlášení, odhlášení, vytvoření hesla, změna hesla. Bylo by fajn, kdyby k tomu prohlížeče poskytovaly API, aby ta implementace „správce hesel“ nemusela být jen integrovaná v prohlížeči, ale aby si uživatel mohl zvolit vlastní správce hesel.

Webové stránky bude snadné donutit k používání jiného systému – stejně, jako už dlouho prohlížeče varují, že se heslo odesílá přes nezabezpečené spojení, mohou varovat před tím, že se heslo zadává do webového formuláře.

> Obavu, že se nepřihlásí na jiném stroji, podle mne velká část uživatelů neřeší. Z těch, kteří to řeší, jich zase velká část zná synchronizaci hesel přes uživatelský profil v cloudu.

To by mi možná znělo uvěřitelně, kdybych podobné protiargumenty neslýchával tak často, jako slýchávám. Na druhou stranu musím uznat, že nemám asi reprezentativní vzorek celé populace. Řekl bych, že toto není překážka pro dvě skupiny lidí:

1. Lidé orientovaní na bezpečnost. S nějakým přenosem (např. synchronizací) si poradí a z cizích strojů se zásadně nepřihlašují. Pokud synchronizují, dost možná použijí řešení, které hesla šifruje a poskytovatel k nim nemá přístup. Když náhodou budou chtít se přihlásit třeba na nákup jízdenky na cizím stroji, heslo třeba opíší z telefonu.
2. Lidé, kteří bezpečnost moc neřeší, ale jde jim o pohodlí. Taky používají jen pár strojů a odjinud se nepřihlašují. Nejspíš nemá tušení, zda provozovatel cloudové služby má přístup k jeho uloženým heslům, nebo jestli jsou zašifrovaná hlavním heslem.

Je tu ale spousta lidí, kteří vidí různé (byť třeba domělé) překážky, například:

* Člověk zvyklý se přihlašovat kdekam ze školních počítačů.
* Člověk, který se z nějakého důvodu nepřihlašuje ze smartphonu.
* Člověk, který sice nemá důvod se přihlašovat z cizích strojů a má možnost použít svůj smartphone, ale má zvyky z doby, kdy tomu tak nebylo. Mám pocit, že do této kategorie patří dost odmítačů správců hesel.
* Člověk, který nechce posílat hesla do cloudu. (Ano, lze to šifrovat, ale tuto obavu reálně slýchávám. Ne každá obava je racionální.)
* Člověk, který nechce dávat všechna hesla do jednoho místa, protože mu to přijde moc riskantní. (Celkem by mě zajímalo, kolik z těchto lidí bude používat jedno univerzální heslo. Ne každý postoj je vždy racionální.)

Není to vědecky zpracované, ale ani vycucané z prstu. Zakládám to na tom, co si vzpomínám, že mi lidi říkají jako důvody proti správcům hesel. Jak těmto lidem chcete „prodat“ řešení postavené na asymetrické kryptografii?

> Problém s externími správci hesel je v tom, že jsou do prohlížečů dohackované.

Existují i API pro správce hesel. Má to Android, má to iOS. Ve WebExtensions jsem to neviděl, ale i tak mi přijde mnohem realističtější to se přidat než razit novou metodu autentizace.

> A všechny správce hesel jsou dohackované do webových stránek – vždy jen hádají, kam se asi má heslo předvyplnit, co je asi vytvoření nového hesla, co asi změna hesla.

Ano. V praxi to ale funguje IMHO mnohem lépe než hypotetické dnes publikované řešení za pět let. Není to hezké, ale je to realita.

> Navíc spoustu bezpečnostních problémů přináší to, že se hesla vyplňují do webové stránky, heslem je chráněný jediný požadavek a pak už vše závisí na nějaké podobě session identifikátoru.

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.

> Webové stránky bude snadné donutit k používání jiného systému – stejně, jako už dlouho prohlížeče varují, že se heslo odesílá přes nezabezpečené spojení, mohou varovat před tím, že se heslo zadává do webového formuláře.

Prohlížeče mohou varovat před lecčím. Mohly by varovat i při použití TLS 1.2, protože je zastaralé. 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. 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. Neříkám, že je HTTPS třeba na zpravodajském serveru bez přihlášení zbytečnost, ale při přihlašování ten psychologický efekt asi bude někde jinde…

Neberte mě špatně. Taky bych rád používal technicky vyspělejší řešení. Jenže pokud jeho výhodám rozumí hrstka lidí a jeho úspěch stojí na masivním použití, prosadí se spíše méně vyspělé řešení, které je jednodušší nebo levnější nebo přišlo dříve.

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.

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

To v principu zní jako stateless password managery. Má to několik nedostatků řešitelných více či méně klasickými stateful password managery:

* Jak zmiňujete, heslo musí být silné, aby odolalo bruteforce. Bez toho po leaku jednoho hesla na mě může kdokoliv udělat offline útok.
* Nelze změnit heslo jen na jedné službě. Docela se to hodí po leaku.
* Nelze sdílet jen část přístupů. Na firemním počítači může zaměstnanec chtít třeba GitHub (vývojář), LinkedIn (HR), dopravce nebo hudební službu. Přitom ale pochopitelně nechce všechny dát firemnímu počítači bšechny přístupy.

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

Ano, ta API dnes neřeší všechno. Ale ukazují, že nejde o principiální problém.

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

Statistiky nemám. Pro obojí ale bude cca stejná cílová skupina. Password manager dnes může použít kdo chce na skoro kterékoliv stránce, heuristikám navzdory. Pokud byste vytvořil nový protokol, na jeho reálné nasazení na podobném počtu webů si počkáte. Za pět let by to IMHO bylo stále dost omezené.

> Některé weby ještě ani nemají implementován HttpOnly session cookie.

Httponly je pěkný způsob, jak v případě XSS zabránit ukrad… Teda on si útočník může z oběti udělat proxy a stejně udělat, co potřebuje, až tak velké omezení to reálně není. Byť v rámci principu least privilege je dobré httponly zapnout, kde to jde.

> Nepřipadá mi, že by tlak prohlížečů na zavádění HTTPS byl neúčinný.

Ten tlak nezačal od píky. A zejména negativní motivace se začíná objevovat až v posledních letech, kdy si to prohlížeče mohou dovolit. To se netýká nového způsobu autentizace.

> 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

Nepřipadá mi, že by se to tlačilo podobným způsobem ve chvíli, kdy to používala drtivá většina webů. Tady začínáte od píky.

> Varování při odeslání formulářových dat přes HTTP měl už Internet Explorer 4.0.

OK, ale to varování, které tak 99 % lidí odklikne bez rozmyslu asi nechcete dávat za vzor, že ne?

> Nebo by prostě stačilo v políčku pro heslo maskovat vstup

Jakože by se políčko pro heslo zobrazilo na webové stránce? Webová stránka má dnes možnsoti jak něco takového napodobit, pak by bezpečnost používání jednoho hesla šla do kytek…

Správci hesel dnes existují a někteří lidé je používají. Přesto dochází k únikům hesel, ze kterých plyne, že uživatelé používají slabá hesla a používají stejná hesla, která server zná, na více webech. Já z toho vyvozuju, že možnost používat správce hesel k vyřešení problému nestačí. Vy z toho děláte jiný závěr?

Já si z toho zároveň vyvozuju, že nebude fungovat nic, kde dáte lidem do ruky možnost používat něco jinak. Jediné reálné řešení je, že uživatelé budou dělat to, co dělají doteď – psát své jedno heslo do prohlížeče – akorát ta technologie pod tím musí být jiná. Už jenom když prohlížeč vezme uživatelem zadané heslo, přidá k němu základní doménu webu a uživatelské jméno, výsledek zahashuje a pošle serveru jako heslo, bude to mnohem bezpečnější, než dnes. Slabá hesla stejně pořád půjde lámat hrubou silou, ale budete to muset dělat po jednom uživateli na každém serveru. Ve srovnání se stavem, kdy máte heslo v otevřeném tvaru, je to pokrok o světelné roky.

Dnes uživatelé mohou změnit heslo jen na jedné službě a mohou sdílet přístupy nebo část přístupů, takže když se to z jejich pohledu bude chovat stejně, tato možnost samozřejmě zůstane zachována.

Mimochodem, sdílení přístupů sdílením hesla je jiný problém, i když daleko méně závažný než to, že neustále unikají hesla z prohlížečů. Zajímalo by mne, kdy třeba e-shopům dojde, že nenakupují jenom jednotlivci, ale i rodiny, firmy a další skupiny, takže by bylo vhodné mít k jednomu účtu více přístupových údajů.

HttpOnly na cookies se používá proto, aby nebylo možné je číst z JavaScriptu. Protože u typického webu je těžké dohlédnout, kdo všechno má v rámci webu možnost JavaScriptem cookies číst, a session cookie obvykle v JavaScriptu číst nepotřebujete.

Jak v případě HTTPS, verzí SSL/TLS nebo hashovacích algoritmů byl tlak prohlížečů zpočátku pozvolný a postupně se přitvrzuje, a trvá to roky. Nikde jsem nepsal, že by se hesla v otevřeném tvaru přestala používat za půl roku. Jenže o tom problému s hesly se ví řádově dvacet let, za tu dobu už opravdu mohlo být zasílání hesel v otevřeném tvaru vymýcené. Můžeme klidně čekat dalších dvacet let, zda se lidé nezmění a nezačnou používat správce hesel, ale na to vám mohu odpovědět rovnou – nezačnou. Ono se totiž nejspíš s hesly nebude dělat nic, a než naučit prohlížeče pracovat s hesly rozumně, to radši donutíme lidi používat FIDO nebo něco takového.

Jakože by se políčko pro heslo zobrazilo na webové stránce?
Ne. Byla by to součást nátlaku na tvůrce webů, aby přestali používat zadávání hesla ve webové stránce – prostě by se input[type='pas­sword'] začal zobrazovat úplně stejně, jako input[type='text'], tj. zadané heslo by nebylo maskované ale bylo by vidět. Zlepšilo by se UX, bezpečnost by se moc nesnížila a spousta lidí, kteří nepoužívají správce hesel z různých obskurních důvodů, by takové weby odmítla dál používat.

Já jsem netvrdil, že správci hesel tyto problémy již vyřešili. Já tvrdím, že je řeší, a že k praktickému vyřešení jsou blíže než nějaký váš abstraktní nápad, který zatím není ani přesně popsaný (nebo ano?), natož aby ho někdo začal implementovat nebo dokonce používat.

Věřím, že postupem času se vyřeší různé věci, které by password managery mohly řešit lépe a zvýší se jejich použití. Nemám přesný scénář, ale je tu několik faktorů, které by tomu mohly pomoci:

* Zlepšení integrace a UX nejen na telefonu, ale i na desktopu. Když to bude jednodušší použít, nechá se přesvědčit více lidí.
* Mám (čistě subjektivně) pocit, že propagace password managerů z bezpečnostních důvodů je spíše záležitostí posledních let, dříve se od toho spíše odrazovalo. Proto si získávaj důvěru až teď.
* Zlepšují se správci hesel integrovaní do prohlížečů. Můžeme se jejich možnostem smát, ale narovinu: Je to první volba pro spoustu uživatelů a pro masové rozšíření to může být klíčové.
* Snad cokoliv, co dnes není ideální u správců hesel, lze v principu evolučně přidat. Lze například přidat API na přihlašování, odhlašování a změnu hesla. Některé stránky to mohou implementovat, a password manager tam bude lépe plnit svou roli. Některé stránky to neimplementují, tam bude password manager fungovat aspoň nějak.

Všimněte si toho, že jde o čistě evoluční cestu, která se nesnaží najednou změnit. Bude to dlouhá cesta (a překážky vidím spíše v postupném přesvědčování uživatelů k jinému chování), ale vidím světlo na konci tunelu.

Naproti tomu vy, pokud to dobře chápu, vidíte cestu v nějakém zákazu.

> Jediné reálné řešení je, že uživatelé budou dělat to, co dělají doteď – psát své jedno heslo do prohlížeče – akorát ta technologie pod tím musí být jiná.

Toto zhruba splňuje i password manager s hlavním heslem.

> Už jenom když prohlížeč vezme uživatelem zadané heslo, přidá k němu základní doménu webu a uživatelské jméno, výsledek zahashuje a pošle serveru jako heslo, bude to mnohem bezpečnější, než dnes.

No, muselo by se to ale implementovat, a to i na webových stránkách. Dokud bude fungovat i stará cesta, bude tu prostor pro downgrade attack a prakticky nulové zlepšení. Ti, kteří dnes ukládají hesla v plaintextu nebo hashují slabě, to nejspíš stejně neimplementují. Navíc se to bude těžko implementovat do stávajících webů, kde hashujete už podle jiného schématu. Neříkám, že je to nemožné, řeší to dvojí hashování, ale zvýšíte tím komplexitu, protože hashování původně prováděné na straně serveru musí nově provést prohlížeč, a server mohl používat bambilión různých schémat. Navíc zpětně kompatibilní řešení nejspíš povede k určitým únikům informací, protože prohlížeč bude potřebovat vědět, jak má hashovat (což může odhalit legacy hesla zahashovaá postaru), jakou má použít sůl, apod. Možná by i to šlo implementovat bezpečně, ale vidím tu spoustu nástrah, kvůli kterým se na to nejspíše vykašlou i ti, kteří bezpečnost řeší – právě z bezpečnostních důvodů, kvůli riziku implementační chyby.

V neposlední řadě to může mít negativní vliv na bezpečnost kvůli falešnému pocitu bezpečí: Sám jste zmiňoval, že používat všude jedno heslo by s tím bylo OK. Stejného dojmu by mohli nabýt i různí lidé, kteří znají trochu principů. Jenže pak hesla leaknou z webu, který používá legacy způsob přihlášení, a v ničem si nepomůžete.

> Slabá hesla stejně pořád půjde lámat hrubou silou, ale budete to muset dělat po jednom uživateli na každém serveru. Ve srovnání se stavem, kdy máte heslo v otevřeném tvaru, je to pokrok o světelné roky.

Je to pokrok ve srovnání se stateful správci hesel je to krok zpět. Ano, v případě cloudové synchronizace můžete zkusit lámat hlavní heslo, ale stále je dost rozdíl mezi online a offline útokem. Online útok lze omezit třeba zvyšující se dobou přihlašování nebo pomocí CAPTCHA. Offline útok je omezen pouze výpočetní kapacitou útočníka.

Navíc i online útok by byl jednodušší než u správců hesel s cloudovou synchronizací. Na online útok by stačilo vybrat si jeden server s nejslabší ochranou proti online útokům. Případně se opřít o více serverů.

> budete to muset dělat po jednom uživateli na každém serveru

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.

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.

Ad httponly – přijde mi to v této diskuzi okrajové téma, ale když už: 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í…

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…

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

Nemyslím si, že bych ignoroval lidi. Lidi postupně svoje návyky mění a mají tendenci si zjednodušovat život. Děje se to postupně a nemusí to být na první pohled patrné, ale děje se to. Například:

* Ústup papírových diářů ve prospěch elektronických.
* Podobně i jízdních řádů.
* Ústup řetězových e-mailů ve prospěch Facebooku. (Super věc, že se člověk může lépe od těchto kravin izolovat.)
* Nástup smartphonů a jejich využívání ke všemu možnému. (PM)
* Nástup eshopů.
* Nástup platebních karet, později nástup bezkontaktního placení, placení telefonem, placení hodinkama.
* Ústup dobírky a nástup platby předem: https://www.novinky.cz/finance/clanek/dobirka-uz-neni-nejoblibenejsim-zpusobem-platby-za-zbozi-40031751
* Vyšší důvěra v cloudové služby. (PM)
* Dnes si lidé online účet nezřídka zakládají i kvůli operačnímu systému a prohlížeči. (PM)
* Synchronizuje se dnes kdeco. (PM)
* Lidi dnes tolik nependlují mezi různými cizími zařízeními, školními počítači a internetovými kavárnami, a spíše používají pár zařízení (telefon, přenosný počítač, pracovní počítač, …) (PM)

Ne všechno z toho přímo souvisí s password managery, některé věci jsem uváděl jen pro doložení faktu, že lidé jsou schopni akceptovat změny, zvlášť když to přinese pohodlí. Ale nemálo z toho seznamu (vizte značku „PM“) vliv má. Někde to ještě potrvá, ale šanci tu vidím.

Podstatným důvodem hrajícím do karet nástupu password managerů možná nebude bezpečnost, ale právě pohodlí. Při registraci je jednodušší ťuknout do tlačítka, které nabízí vygenerování hesla. Zvlášť když se pěkně nabídne. Při přihlášení je taky jednodušší heslo nepsat. S password managerem ostatně nemusíte typicky psát ani uživatelské jméno/e-mail, on vám to vyplní. Myslíte, že uživatelé budou ignorovat pohodlnější variantu, kterou jim budou prohlížeče a OS strkat čím dát tím víc pod nos?

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

To rozhodně nestačí. Těmi standardy se musí i někdo řídit. A to nejen prohlížeče, ale i autoři webů. I kdybyste jim sebral password fieldy, mají dnes kupu možností si je vytvořit pomocí HTML+CSS nebo HTML+JS (což by mimochodem poněkud zkomplikovalo password managery). A vzhledem k technické složitosti pro existující weby je prakticky jisté, že by to někdo udělal a nabídl knihovnu…

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

Tomu se už přiblužujeme… TODO

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

Pak máte stateless správce hesel, se všemi nevýhodami, které jsem zmiňoval.

> 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

Každé řešení může selhat na uživateli. Ve chvíli, kdy mizejí důvody, proč správce hesel nepoužívat, toto nevidím jako zásadní problém.

> Dneska si to heslo uživatele jako provozovatel webu prostě přečtete ze své databáze.

To předpokládá, že provozovatel ukládá hesla v plaintextu. 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ě.

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.

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.

> Já nechci správce hesel nahrazovat, v mém řešení fungují stejně dobře, jako dnes.

Vizte výše, vaše řešení přináší spíše komplikace než zvýšení bezpečnosti. Pravda, s password managerem by mohlo být bezpečnější, ale to už můžeme rovnou použít samotný password manager a nebudeme muset řešit různé side channely…

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

O tom jste mě zrovna nepřesvědčil, vizte výše.

> A zpětná kompatibilita je přesně to, co v tomto případě chceme porušit

Máte řádově složitější problém než zaříznutí staré verze TLS nebo použití TLS pro formuláře. Autoři webů mají spoustu možností, jak to obejít, pokud jim neseberete CSS a JS. Co si myslíte, že se stane?

a) Všichni autoři webů se začnou přizpůsobovat, řešit side channely apod. 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. Prostě udělají fúru práce, jen aby bezpečnost přihlašování na svém webu… v mnoha případech vlastně prakticky nezvýšili, protože již hashují a solí správně.
b) Začne se to obcházet vlastní implementací password fieldů, což ztíží práci password managerů.

Zapomněl jsem místo „TODO“ hodit screenshot: https://photos.app.goo.gl/t1ic1MRfQHZStJxv5

Myslím, že není problém si představit další iteraci, kdy to generování hesla bude mít ještě více v popředí a na psaní vlastního textu bude potřeba vynaložit větší úsilí…

Jo, a nereagoval jsem na to XSS. V rámci XSS můžete dělat prakticky libovolné requesty na aktuální doménu, a pošlou se s tím všechny cookies., včetně těch httponly. Potom vidíte obsah, který můžete někam odeslat. Exfiltrace není problém, lze použít například websockets, CORS nebo různé workaroundy s kódováním dat do URL obrázku*. A nebo lze kompletně změnit obsah stránky a chtít třeba jméno a heslo, uživatel se ochotně znovu přihlásí, a heslo lze odelat útočníkovi. Těžko tomu bránit, protože útočník zde jen využívá toho, co legitimní stránka celkem běžně potřebuje. Takže httponly je fakt spíše takový drobek, který teda zapnu, když už to jde, ale nemám od něj prakticky žádná očekávání.

A není mi jasné, jak to souvisí s tématem. Přihlašování lze řešit separátně od udržování přihlášeného stavu v nějaké session. Je to i žádoucí, třeba kvůli rate limits.

*) Tyto workaroundy jsou dnes celkem zbytečné, spíše ukazují, že i kdybychom se zbavili CORS a websockets, nepomůžeme si, protože možnosti tu budou stále.

V rámci XSS můžete dělat prakticky libovolné requesty na aktuální doménu, a pošlou se s tím všechny cookies., včetně těch httponly. Potom vidíte obsah, který můžete někam odeslat.
Kde ten obsah vidíte? Vidíte ho na serveru, ovšem tam byste zase musel mít nějaký kód, který vám tu cookie (nebo třeba celý požadavek i s hlavičkami) pošle zpět do prohlížeče.

A není mi jasné, jak to souvisí s tématem. Přihlašování lze řešit separátně od udržování přihlášeného stavu v nějaké session
S tématem to souvisí tak, že při přihlašování přes webový formulář je pouze přihlašovací požadavek „chráněn“ heslem, všechny ostatní požadavky od téhož uživatele už si musí aplikace nějak chránit sama, resp. sama si je musí spárovat s daným uživatelem. K čemuž se často používají cookies. Když se používá autentizace na úrovni HTTP protokolu, je autentizován každý jednotlivý požadavek. Tím pádem odpadá celá třída bezpečnostních problémů – únosy session.

> Kde ten obsah vidíte? Vidíte ho na serveru, ovšem tam byste zase musel mít nějaký kód, který vám tu cookie (nebo třeba celý požadavek i s hlavičkami) pošle zpět do prohlížeče.

Ale já jako útočník nepotřebuju tu cookie. Já potřebuju přečíst nějaká data nebo vykonat nějakou akci. To pomocí XMLHttpRequest nebo Fetch API udělat mohu.

Ano, získat tu cookie by mohlo být o něco lepší, ale i toto může často stačit.

A zobrazení přihlašovací obrazovky přímo na stránce serveru, kam útočím, může být taky dost účinné.

Posílat něco odvozeného z hesla v každém požadavku a následně to ověřovat možné samozřejmě je. Řeší to session fixation, a to je asi tak vše. Neřeší to třeba CSRF (aspoň ne v podobě dnešní HTTP autentizace) a těžko se taky sleduje nové přihlášení. A taky to předpokládá, že se secret z prohlížeče dál hashuje maximálně nějakou rychlou funkcí – což nemusí nutně vždy vadit, ale je dobré s tím počítat.

Ano, autentizace každého HTTP požadavku neřeší všechny problémy světa, ale řeší to problémy, které měly být vyřešeny už před dvaceti lety – a my s nimi zápasíme dodnes a řešení je v nedohlednu.

A s čím vlastně zápasíme dodnes?

Dodnes zápasíme s tím, že není autentizován každý požadavek, ale vše je závislé na session, často pomocí session cookie. Takže musíme řešit, aby neunikl identifikátor sezení, aby se stránkou nešlo manipulovat z jiného okna prohlížeče, aby sezení netrvalo věčně, když uživatel zavře okno prohlížeče. Ne že by to nijak řešit nešlo, ale řešíme zbytečné problémy a řešení samozřejmě nejsou dokonalá.

Jestli dobře rozumím, Vaše řešení je ekvivalentní tomu, že bychom místo náhodného session id, které po vypršení/odhlášení utrácí hodnotu, nahradili něčím, z čeho lze brutit heslo offline? To bychom mohli i dnes, jen nemám zrovna pocit, že to bude mít pozitivní vliv na bezpečnost.

Naopak by to mělo různé jiné nepříjemné důsledky, například:

* Vyšší praktická zneužitelnost útoků jako https://www.rc4nomore.com/ nebo POODLE.
* Motivovalo by to ke slabému server-side hashování (zátěž CPU).

Nikoli. Podívejte se třeba na HTTP Digest (primitivní řešení, ale po aktualizaci hashovacího algoritmu by to pořád bylo milionkrát bezpečnější, než posílat heslo v otevřeném tvaru). Pak existují komplikovanější metody, které ale mají proti Digestu další výhody – např. SCRAM. Při použití SCRAMu ani údaje uložené na serveru nestačí k úspěšnému přihlášení, nebo-li i pokud by ze serveru unikla databáze přihlašovacími údaji, nepůjde ji zneužít ani pro přihlášení přímo na ten server. Samozřejmě nepíšu o útoku hrubou silou – tam je jedinou systémovou obranou to, že útočník musí hádat každé jednotlivé heslo zvlášť, a dál už pomůže jenom silné heslo.

Mimochodem, když píšete o tom offline bruteforce útoku, zase jste zapomněl na to, že dnes se heslo posílá v otevřeném tvaru. Nemyslím si, že byste našel ještě méně bezpečné řešení.

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.

Možná je na čase tomu Vašemu řešení dát přesnější obrysy:

* Co bude ta hashovací funkce? Půjde o jednu funkci, nebo bude konfigurovatelná?
* Pokud bude konfigurovatelná, jak se bude konfigurovat?
* Jak se bude řešit změna hashování?
* Jak se bude řešit salt?
* Jak se bude řešit pokus o přihlášení neexistujícího uživatele? Neleakne zde informace, že ten uživatel neexistuje?
* 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?
* Jak si to poradí s offline útoky na hashe ve srovnání se stateful password managerem?

Už na toto může být problém odpovědět nějak konzistentně. Až na to odpovíte, můžeme se bavit třeba o side channels, které jsem měl namysli. Ale možná Vám to po sepsání bude jasné. Já jsem kdysi taky byl pro podobné schéma, ono to na první pohled vypadá dobře, ale jak přibývají detaily, člověk zjišťuje, jak komplexní problém to je.

> Na provozovatele webů mají dostatečné páky

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í?

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ě. Prohlížeče mohou varovat před něčím, co se děje vzácně. Což znamená, že prohlížeče touto cestou spíše pomohou v závěrečné fázi, ale do té doby to musí hnát jiné síly.

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

Myslím, že těch 40 % je dost nadsazené číslo. Ale i kdyby, dovedu si představit postupné evoluční zlepšování. Bude motivací každého správce webu mít web kompatibilní s password managery, jinak přijdou o uživatele. Dopad tu je celkem jasný.

> Nepřibližujeme. Dnes musí uživatel ručně otevřít kontextové menu políčka, tam vybrat vygenerování hesla;

Není vždy pravda. Ukazoval jsem screenshot, kde rovnou po ťuknutí do políčka s heslem jsem dostal tlačísko na vygenerování hesla. A jde to posouvat ještě dál – tlačítko pro vygenerování bude to hlavní, abych napsal něco vlastního, musím něco rozkliknout.

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

Promiňte, ale toto je jednoznačně vytrženo z kontextu. Napsal jsem toto: „To předpokládá, že provozovatel ukládá hesla v plaintextu. 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.

No, v obou případech si to lze implementovat vlastními silami a v obou případech lze využít knihovny.

> 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

Pokud je na implementaci něco špatně, je určitě správně tam nestrkat heslo, které by se dalo využít jinde. To řeší stateful password manager. Váš návrh to řeší částečně (hash odvozený z hesla je náchylný offline útokům), a přináší komplexitu. Mohou uniknout i další údaje, jako poslední přihlášení, nebo zda uživatel vůbec existuje. A i to může na některých webech být citlivý údaj. Je sice těžké některé údaje ochránit stoprocentně, ale to není důvod zavádět falší problémy. Pokud o tom mám diskutovat dál, poskytněte detailnější návrh, jak jsem zmiňoval na záčátku.

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

Možná. Někdy časem. Pokud se změní chování uživatelů, k čemuž jste sám byl skeptický. 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ů.

> Nikoli, nenapsal jste jedinou komplikaci, kterou by přinášelo moje řešení.

Vizte výše, dejte přesnější návrh, možná si těch komplikací všimnete i sám.

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

A teď si představte, že chcete u zaměstnavatele obhájit, že budete svůj čas věnovat podobné úpravě. Jak vysvětlíte benefity? Kdy přijdou? Někdy možná, až se prohlížeče rozhodnou brojit proti formulářům s hesly na webech?

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

To ano, ale mají poněkud volnější ruce. Mohou počítat s tím, že dostanou heslo v plaintextu a mohou si to pořešit podle sebe. Tady se velmi reálně může stát, že jejich stávající mechanismus hashování nebude kompatibilní s Vaším návrhem, a tedy budou muset nechat nějakou dobu klasický formulář, jak píšete.

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

Už si představuju hovor zaměstnance, který chce tu změnu implementovat:

A: Rád bych zde implementoval nový způsob přihlašování.
B: Co to přinese a kolik to bude stát MD?
A: Umožní to hashovat hesla přímo u zákazníka, takže to bude bezpečnější. U nás se budou ukládat hashovaná, takže kdyby se někdo dostal k databázi…
B: A teď je nehashujeme?
A: No, hashujeme, ale až na serveru.
B: Takže když se někdo dostane k DB, stejně dostane jen zahashovaná hesla, ne?
A: No ale někteří uživatelé zaměření na bezpečnost…
B: Ti si to vyřešili password managerem. A konkurence nic podobného taky nedělá. Získáme tím tak 0.0001 % navíc, ta práce se nezaplatí.

No, mnohem realističtější mi přijde, že někdo bude web dělat více friendly pro password manager, 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á. Tady je ekonomický dopad zřejmý.

> podívejte se, jak je dnes rozšířené HTTPS.

U HTTPS jde o mnohem jednodušší problém s větším dopadem. To, že si někdo může hesla přečíst po cestě, zní mnohem hůře. Úprava stránky routerem taky. Náročnost řešení záleží. Někdy si to může vyžádat nový hosting nebo upravit absolutní URL, někdy (hlavně v počátcích) vyřešit 3rdparty skripty. To může být pořád nic proti řešení bezpečné implementace Vašeho návrhu.

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.

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

OK, s tímto se už pracuje lépe. Ale ještě to není úplně rozvedené.
Jistěže to není úplně rozvedené. Je to jen náznak základních principů pro někoho, kdo se teď začal zabývat autentizací. Pokud bychom se bavili o tom, co se má reálně použít, odkázal bych vás například na SCRAM. Ale to už není úplně jednoduchý protokol pro začátek diskuse.

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
Tohle se řeší velice snadno – i na neexistujícího uživatele server reaguje stejně, jako kdyby uživatel existoval, a pokračuje v autentizaci.

Nedoporučuje se mít veřejně dostupnou sůl.
Jenom bych připomněl, že to stále porovnáváme s variantou, kdy se odesílá heslo v otevřeném tvaru. Proti tomu je veřejně dostupná sůl vrchol bezpečnosti.

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?
Protože by to bylo k ničemu. Pořád byste musel důvěřovat provozovateli webu. Přičemž celý problém s hesly v otevřeném tvaru je v tom, že provozovateli webu důvěřovat nelze.

Mám udělat mockup password fieldu, který to bude splňovat?
Žádný password field nebude splňovat to, že bude bezpečný. Bezpečné zadání hesla bude jedině takové, kdy se heslo bude zadávat do UI prohlížeče, které webová stránka nedokáže napodobit.

HTTPS stačí implementovat na serverech a v prohlížečích.
A v proxy serverech, antivirech, na firewallech. Potřebujete infrastrukturu certifikačních autorit, odvolávání certifikátů. Potřebujete mít seznam důvěryhodných certifikačních autorit. A také ta implementace TLS je mnohem mnohem těžší, než hashování hesel.

Jak docílíte stavu, že nikdo nebude podvádět?
Jednoduše plynutím času. Implementovat nově přihlašování pomocí standardních mechanismů bude mnohem jednodušší, než podvádět. Takže proč by to někdo dělal? Navíc uživatel bude vědět, jak vypadá UI prohlížeče pro zadání hesla, takže podvod „před 10 lety vypadaly přihlašovací formuláře takhle“ na něj fungovat nebude.

Tak jsem věnoval čas sepsání srovnávací tabulky:

https://docs.google.com/spreadsheets/d/17XXbY5w618CZSdiq8ovcpLrifqLRI3O8DPsXqp9ETZM/edit?usp=drivesdk

* Váš způsob přihlašování jsem nazval „FJ SCRAM“. Vaše iniciály jsem tam přidal, protože samotný SCRAM nepopisuje všechno podstatné.
* Plus jsem tam přidal i přihlašování asymetrickou kryptografií (ve stylu SSH klíčů).
* Snažil jsem se nejlepší variantu pro daný řádek obarvit nazeleno. Těch nejlepších variant v dané kategorii může být více.
* Protože jsme se o přihlašování asymetrickou kryptografií původně moc nebavili a protože v některých kategoriích vyšla jako suverénně nejlepší (byla by jediná zelená), označil jsem zde druhé místo jiným odstínem zelené.

Srovnání z hlediska bezpečnosti předpokládá, že se řešení podaří prosadit a uživatelé jej pochopí. (Naplnění těchto předpokladů je řešeno níže):

* Asymetrická kryptografie je jednoznačný vítěz.
* Úplně jednoznačného poraženého (tzn. ve všech kategoriích) nemáme, ale pro většinu situací se asi shodneme, že znovupoužitá hesla s plain autentizací jsou nejhorší varianta.
* Nelze jednoznačně určit vítěze mezi password managery a FJ SCRAM. Za mě to jsou password managery.
* Password managery + FJ SCRAM vycházejí jednoznačně lépe než FJ SCRAM samotný, nevycházejí jednoznačně lépe než password managery samotné.

V dokonalém světě bychom prostě vybrali to nejlepší řešení z hlediska bezpečnosti (tj. asymetrickou kryptografii) a bylo by. Jenže otázkou je, jak náročné to bude nasadit a vysvětlit všem, jak to správně použít:

* Tady už nemáme úplně jednoznačné (tj. ve všech parametrech) vítěze ani poražené.
* Nicméně password managery mají ve většině věcí navrch.
* FJ SCRAM naopak ve většině věcí propadá a vychází jednoznačně hůře než samotné password managery.
* Asymetrická kryptografie IMHO v obou kategoriích vychází celkově lépe než FJ SCRAM.
* Asymetrické kryptografii mohou cestu uhladit právě password managery, ze kterých by se staly obecnější access managery.
* Za mě tedy bych viděl cestu 1. password managery (=nedokonalé, ale praktické řešení) a 2. asymetrická kryptografie.

Máte k tomu nějaké námitky? Případné námitky by asi šlo rozdělit do třech kategorií:

a. Nesouhlas s tím, co v tabulce je.
b. V tabulce chybí podstatný údaj.
c. Nesouhlas s celkovým hodnocením.

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

To předpokládá, že máte správce hesel (nechtěl jste se náhodou obejít i bez něj?) a heslo máte v paměti v čitelném stavu (což taky nemusí s hlavním heslem být vždy pravda). Ale se správcem hesel tento problém vlastně nemusíte mít vůbec, tam nemáte důvod to heslo psát. Bez něj naopak ten problém nevyřešíte.

EDIT: A navíc je to řešení na způsob http://www.lamer.cz/quote/50132 .

> A i kdyby automatická detekce nefungovala, prohlížeč pořád může mít blacklist, který bude ručně spravovaný.

Blacklist není zrovna pěkné řešení…

2. 2. 2020, 17:32 editováno autorem komentáře

I e-maily už se dnes docela často při přenosu šifrují. No a když to heslo zná server, tak ho mimo jiné může poslat e-mailem, čímž to převedete na ten druhý případ.

Emaily sifruji mozna tak v 0.0001% pripadu. resp. nikdy sem zadnej sifrovanej email nevidel jen sem o tom slysel. Ty eshopy samozrejme emaily nesifruji, protoze by si nejdriv museli vymenit klice s uzivatelem a to je tolik prace navic ze to ani nedava smysl...

Ale vyvrátil. Sám jste jako příklad uvedl asymetrickou kryptografii. Když se něco rád dozvíte, poučím vás. Asymetrická kryptografie funguje na principu dvou klíčů, které jsou provázané – veřejného a soukromého. Veřejný klíč je odvozený od soukromého, ale opačná cesta je dnešními prostředky neproveditelná – tj. nelze z veřejného klíče odvodit ten soukromý. A dále pro ty klíče a algoritmus platí to, že co transformujete („zašifrujete“) jedním klíčem, převedete do původní podoby („odšifrujete“) tím druhým. Takže server pošle náhodnou výzvu, klient jí zašifruje svým privátním klíčem, výsledek zašle serveru, server dešifruje veřejným klíčem klienta a porovná, zda dostal to samé, co poslal jako výzvu. Pokud ano, ví, že klient má soukromý klíč odpovídající tomu veřejnému klíči. Server tudíž zná jen veřejný klíč a po síti se posílá náhodně vygenerovaná výzva a pak zašifrovaná výzva – k opakovanému přihlášení to nestačí, protože výzva příště bude jiná.

A to je jenom jedna z možností. Existují i jiné algoritmy pro přihlašování, kde informace, které musí znát server, nepostačují pro úspěšné přihlášení klienta. A také jednodušší algoritmy, kde informace uložené na serveru sice je možné použít pro přihlášení na stejném serveru, ale server nezná heslo ani jeho ekvivalent, takže se s těmi údaji nepřihlásíte nikde jinde. Takový způsob přihlašování je dokonce součástí protokolu HTTP jako autentizační metoda HTTP Digest. Akorát je v prohlížečích implementována otřesně, tudíž se nepoužívá a tudíž je dnes už beznadějně zastaralá (je založená na MD5).

Jenze tohle resi jen pripad, ze ten server nekdo napadne a ten nema hesla dostatecne zabezpeceny. Pokud nekdo napadne klienta, tak sme tam kde sme byly s heslem...

@BlackRider: Nějak netuším, kam míříte tím, že konstatujete všeobecně známou pravdu, která nemění nic na tom, o čem diskutujeme. Ano, dostatečně silný obušek dokáže eliminovat libovolně silné zabezpečení, protože uživatel nakonec raději sám přístup odemkne. A co?

"@BlackRider: Nějak netuším, kam míříte tím, že konstatujete všeobecně známou pravdu, která nemění nic na tom, o čem diskutujeme. Ano, dostatečně silný obušek dokáže eliminovat libovolně silné zabezpečení, protože uživatel nakonec raději sám přístup odemkne. A co?"

Jen rikam, ze privatni klic nic neresi, protoze pravdepodobnost napadeni klienta je radove vyssi nez pravdepodobnost napadeni serveru...

Asymetrická kryptografie sama o sobě neověří že jste to skutečně Vy
Jste si jist, že znáte kontext, ve kterém diskutujete? Heslo také neověří, že jsme to skutečně já. Heslo se ovšem používá tak, že provozovatel webu má u mého účtu uložené údaje, na základě kterých mne dokáže pomocí hesla ověřit. A místo těchto údajů může mít uložený veřejný klíč a ověří, že já vlastním odpovídající privátní klíč.

Stručně řečeno: to, k čemu se dnes na webu používají hesla, lze nahradit (mimo jiné) asymetrickou kryptografií.

pokud server zveřejní to co jste mu poslal (ten váš "podpis" užitím asymetrické kryptografie) jako to heslo, máte zhruba stejný problém
Vždyť jsem vám v předchozím komentáři vysvětloval, jak autentizace pomocí asymetrické kryptografie funguje. Pokud to nechápete, tak se prostě jen smiřte s tím, že není pravda vaše tvrzení, že pokud server něco zveřejní, je to stejný problém, jako když unikne (byť unikátní) heslo. Naopak, žádný problém to není – veřejný klíč se jmenuje „veřejný“ proto, že je opravdu veřejný, může ho znát kdokoli, můžete ho vystavit na internetu. Např. každý HTTPS server, včetně např. root.cz, posílá při navázání HTTPS spojení svůj veřejný klíč klientovi – a ničemu to nevadí, ten klíč je určený ke zveřejnění.

něco stejného jako jste tu argumentovat u elektronických občanek
Ne, ničím takovým jsem neargumentoval – já vím, jak funguje asymetrická kryptografie.

pak ale začnete na uživatele klást pro ně bohužel absolutně nesrozumitelné požadavky
Já nechci na uživatele klást žádné nové požadavky, já bych dokonce chtěl na uživatele klást méně požadavků, než dnes – aby nemuseli řešit, že mají pro každý web používat jiné heslo, aby nemuseli složitě zjišťovat, kam heslo mohou zadat a kam ne, aby nemuseli kontrolovat, zda heslo nezadávají do jiného webu atd. Já mám požadavky jen na autory webových prohlížečů, webových standardů, webových serverů a posléze by prohlížeče měly požadavky na provozovatele webů.

S HTTP Digest sice přenesete odpovědnost ze serveru, ale naložíte ji na běžného klienta
Nikoli, oproti dnešku by se ta odpovědnost uživatele zmenšila. Mimochodem, ten současný stav bych nenazýval odpovědností uživatele, ale alibismem tvůrců prohlížečů.

Svůj komentář jste vyplýtval na rádoby poučné, spíš výsměvné, poučení o základech asymetrické kdryptografie
Které bohužel evidentně nedopadlo na úrodnou půdu, když si stále myslíte, že zveřejnění veřejného klíče je problém.

k tomu jak skutečně vyřešíte jste nenapsal zhola nic
Ale napsal, a už jsem to napsal mnohokrát dříve. Heslo si má uživatel vyříkat s prohlížečem, prohlížeč je ten nástroj, kterému uživatel musí z principu důvěřovat. Prohlížeč to heslo má chránit jako oko v hlavě, nesmí heslo ani jeho ekvivalent zpřístupnit nikomu jinému. Uživatel má heslo zadávat do GUI prohlížeče, které bude snadno odlišitelné od webové stránky tak, aby jej nešlo napodobit, prohlížeč pak má uživateli umožnit i vytvoření účtu, změnu hesla a odhlášení. Po uživateli se pak bude chtít jediné – aby heslo nepsal kamkoli, kam napsat jde, ale jenom do toho speciálního dialogu prohlížeče. Už je pak implementační detail, zda tam bude psát master heslo, nebo heslo ke konkrétnímu webu (které klidně může být shodné s heslem pro jiné weby).

jenom popsal řešení které přenáší odpovědnost někam jinam, IMHO na slabší článek řetězu
Moje řešení přenáší odpovědnost na prohlížeč. Kam ta odpovědnost patří. Prohlížeč píší odborníci, používají ho laici.

IMHO je jednoduší vyškolit správce serverů a programátory v bezpečnosti než běžné uživatele
Není, správci serverů a programátoři webových aplikací jsou na tom se znalostmi bezpečnosti úplně stejně, jako běžní uživatelé. Je naivní myslet si, že jsou na tom výrazně lépe, než uživatelé. A pokud si to snad někdo kdysi myslel, měly ho z toho dávno vyléčit neustálé a další a další úniky hesel.

A+ je podmíněno použitím hlavičky HSTS (alespoň ještě v prosinci 2019 bylo)