Vlákno názorů k článku Ještě k úniku @gmail.com adres s hesly: používání e-mailu jako login je potíž od Filip Jirsák - Celý ten problém má velmi jednoduché řešení, které...
-
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ě.
- 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.
-
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.
-
Jenda (neregistrovaný)
> 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.
To si nějak nedokážu představit, můžeš to rozvést? Jak se liší MITM nad form+cookies „přihlašováním“ a nad HTTP auth?
> A když jsem psal, že aplikace nemá plnou kontrolu, tak jedním z nich představuje odhlašování.
Ano, to je myslím ten problém, o kterém Filip občas píše - prohlížeče neimplementují funkci „odhlásit“. Existují hnusné hacky jako že klientovi pošleš 403 a revokuješ mu pomocnou cookie, ale to je humus. Prostě ve Firefoxu mi schází tlačítko „logout“ (jde to jen globálně přes Odstranit citlivá data → Active Logins).
> Phishing lze provést i na něm.
Phishing lze provést tak nějak z principu úplně vždycky… Stejně, jako MITM.
> Takže na první pohled uživatel nepozná kdo ho volá
URL?
-
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.
ČLÁNKY DO MAILU