Názory k článku Ještě k úniku @gmail.com adres s hesly: používání e-mailu jako login je potíž

Ano, je to tak. Napsal jsem HTTP Digest, protože je to protokol, který už je ve standardu dlouho (i když není povinný), a je implementován ve spoustě klientů i serverů. A proti dnešku by to bylo podstatné zlepšení.
Odolný proti krádeži údajů ze serveru by měl být třeba SCRAM, ale přesný princip fungování jsem zatím nezkoumal.

Používáte to v praxi? Já bych se bál toho, že to nebudou mít na serveru implementované správně. Není úplně výjimečné, že se špatně překóduje zobrazené jméno, a bojím se, že u hesel to bude implementované správně v ještě menším počtu případů.

Uživatel zadá své heslo, k tomu se připojí pojmenování serveru a z toho vytvoří prohlížeč hash. Ten pošle serveru a server si tenhle hash uloží. Tedy mělo by to tak být, pokud by se registrace standardizovala. Dál už by to bylo současné HTTP Digest. Server pošle výzvu (náhodný text). Prohlížeč se uživatele zeptá na heslo, připojí pojmenování serveru, vytvoří hash (pokud uživatel zadal správné heslo, je to ten samý hash, který má uložen server). K tomuto hashi prohlížeč přidá výzvu serveru a vytvoří druhý hash, který odešle serveru. Server zná první hash i výzvu, spočítá druhý hash a porovná jej s tím, který dostal od uživatele. Tj. uživatel zadává jen heslo, díky prvnímu hashi, který obsahuje i pojmenování serveru, se nedá znalost jednoho hashe použít pro přihlášení na jiný server, i když má uživatel stejné heslo. Díky té výzvě a druhému hashi není možné použít replay attack – i když někdo odposlechne druhý hash poslaný po síti, nemůže jej použít, protože příště pošle server jinou výzvu.
Když uživatel používá více prohlížečů, prostě jen do prohlížeče zadá svoje heslo. Prohlížeč si nemusí nic pamatovat, pojmenování serveru a výzvu dostane od serveru, heslo zadá uživatel. Proto je to právě jednodušší na použití, než správce hesel, protože nepotřebujete nic nikam ukládat, stačí jenom prohlížeč.

Jasně, odhlášení je další věc, která ve standardu chybí. Psal jsem to už někdy dříve, nechtěl jsem to tentokrát celé opakovat. Základní věc je tlačítko pro odhlášení přímo v prohlížeči, na tom není co řešit, to se dá implementovat hned teď, a bylo by to užitečné. Další věc je, aby se o odhlášení aplikace dozvěděla a aby se dalo vyvolat u webové stránky – ale to už jsou takové třešničky na dortu.
HTTP Digest je proti MitM útoků odolná, na rozdíl třeba od session řešené přes cookie.
Masově se nepoužívá z několika důvodů. Implementace přihlašování v prohlížečích byla dlouho z pohledu UX příšerná, dnes už je to o něco lepší. HTTP Basic je nebezpečnější, než přihlášení přes formulář, protože se heslo posílá v otevřeném tvaru s každým požadavkem (při přihlášení přes formulář se pošle jen jednou na začátku session). No a implementace HTTP Digest nebyla povinná a byly problémy s kompatibilitou mezi klienty a servery (přitom je to tak jednoduchý standard). No a ta absence odhlášení v prohlížečích je také dost problém, navíc je to dost nepochopitelné.
Součástí formuláře pro přihlášení musí být webová adresa, tím pádem je to naopak odolné vůči útokům přes různé překrývání formulářů a iframy – uživatel vždy vidí skutečnou adresu, ke které se přihlašuje. Rozlišení Digest vs. Basic je opět na prohlížeči – jak jsem psal, měl by uživatele varovat, pokud se heslo posílá v otevřeném tvaru.

A jak chcete zajistit, že nějaký hash patří zrovna tomuto uživateli? Jak chcete zajistit, že tento hash nepoužije někdo jiný? A jak se řeší situace, kdy jeden uživatel používá službu na více prohlížečích (doma u PC, na cestách v notebooku apod)?

HTTP autentizace je v tomto přijatelná. Jenže problém je, že aplikace nad nim nemá plnou kontrolu. Tudíž nemůže plně důvěřovat datům, které dostane. Ostatně největší problém tohoto typu autentizace je náchylnost na man-in-the-middle attack.
A když jsem psal, že aplikace nemá plnou kontrolu, tak jedním z nich představuje odhlašování. Toto je naprosto mizerně implementováno. Jasně stačí ukončit prohlížeč. Ale tak snadné to není. V dnešní době tabů, je problém ukončit prohlížeč, když jsou v prohlížeči otevřeny další stránky. A co v případě, že se chci odhlásit a přihlásit se pod jiným účtem? Existuji metody jak dosáhnout odhlášení nebo přelogování, ale jsou to jen finty a ne plnohodnotné operace.

Kdyby HTTP autentizace byla bezpečná, tak proč se masově nepoužívá?

Když tak přemýšlím, tak i HTTP autentizace není žádná sláva. Phishing lze provést i na něm. A mám pocit, že až moc snadno. Za prvé formulář pro přihlášení je za všech okolností identický, protože ho volá prohlížeč. Takže na první pohled uživatel nepozná kdo ho volá, nehledě na to, že požadavek může přijít ještě před načtením stránky, tudíž chybí grafická kontrola. Za druhé. Co brání útočníkovi místo digest použít basic? Uživatel nic nepozná (hlavičky nevidí) a prohlížeč na to neupozorní, pokud tam neimplementuji hlášku, že posílá heslo v plain textu. Takže uživatel nevědomky nepošle hash, ale jméno a heslo.

Heslo napsané na monitoru nebo v peněžence prakticky nevadí. Spousta uživatelů pochopí, že heslo se v prohlížeči píše jen do toho jediného dialogového okna, stejně jako spousta uživatelů už dnes chápe, že heslo má být složité. Dost uživatelů chápe i to, že nemají při registraci zadávat e-mail a heslo, které je stejné, jako heslo k tomu e-mailu. Akorát to těm uživatelům nikdo neřekl.
Systém, kdy vyzrazení jednoho hesla znamená kompromitaci všech služeb, je i password manager. Pochybuju o tom, že si pamatujete stovky hesel, takže nějaké sdružování pod jedno nebo několik hesel taky používáte. V tom vám nic nebrání. Jde jenom o to, aby provozovatel služby vaše heslo (ani jeho ekvivalent použitelný jinde) vůbec neznal.
HTTP Digest se občas používá, ale bohužel málo. Pokud máte něco lepšího, co by se hodilo pro použití na veřejném webu, sem s tím.

Úniků ubýt může, pokud to vyřeší odborníci. Jak jsem psal v předchozím komentáři, řešení je jednoduché, a bude fungovat i s těmi návyky, které mají uživatelé teď. Na uživateli by zůstalo jenom to mít heslo dostatečně složité – což by při jednom univerzálním hesle nebyl takový problém.

Celý ten problém má velmi jednoduché řešení, které by mohli implementovat autoři webových prohlížečů a serverů – pokud by jim skutečně šlo o bezpečnost. Ti mohou bezpečnost skutečně zvýšit – chtít po všech uživatelích, aby se přihlašovali komplikovanějším způsobem, je nereálné a naivní. Už nějaký ten pátek je v HTTP standardu definováno přihlašování metodou HTTP digest, při které server vůbec nemusí znát heslo v otevřeném tvaru. Chybí ovšem druhá polovina standardu, totiž jak toto heslo bezpečně vytvářet. Navíc implementace tohoto způsobu přihlašování v prohlížečích je často dost nepřívětivá. Stačilo by tedy dohodnout se na způsobu, jak se bude serveru předávat hash, který server potřebuje znát k ověření uživatele (ten hash by i při registraci počítal prohlížeč). Prohlížeč by pak mohl při každém použití formulářového prvku pro zadání hesla nebo při každém použití Basic autentizace uživatele varovat, že server získá jeho heslo v otevřeném tvaru. Jedině při použití HTTP Digest nebo Kerberos autentizace by nevaroval, protože to je bezpečný způsob přihlášení. Mělo by to tyto výhody:

• Server by vůbec neznal heslo uživatele, takže i když uživatel použije stejné heslo na více místech, ničemu to nevadí.
• Heslo se nikdy nepřenáší po síti v nešifrované podobě.

A jako bonus:

• Autentizován je každý HTTP požadavek. Takže už žádné únosy session.
• Heslo se zadává do dialogu prohlížeče, takže nehrozí žádné skryté formuláře nebo script injection.

Úplně by stačilo, aby to Google implementoval na svých serverech a v Chrome, ostatní by se museli přizpůsobit. Nebo aby to stejně implementoval Microsoft. I kdyby to implementovala Mozilla, ostatní těžko obhájí, proč to nepodporují.