Z webu OpenSubtitles uniklo sedm milionů uživatelských účtů včetně MD5 hašů hesel

Poučení zní, jakékoliv služby by měly mít zakázáno získávat přes internet hesla v čitelné podobě.

Prohlížeče měly už dávno obsahovat API, které provede solení a hash hesla na klientské straně, aby služba ani nemohla hashování/solení řešit. S tím, že standard pro hash a způsob solení bude daný. V případě [[deprecated]] hashů budou správci služeb, které využívají hesla nuceni to aktualizovat při dalším použití. Šlo by to, bylo by to správně, přesto je to Sci-fi...

Tito borci by měli dostat pokutu za porušení legislativy pro ochranu OU (GDPR), stejně jako dostal Mall, aby si i ostatní uvědmili, že přes nesolený MD5/SHA-1 cesta nevede! A přehashovali to na něco rozumějšího a ta stará hesla v MD5, co nikdo už několik let nepoužil smazali.

Alternativou je vyhnout se používání hesel... tokeny, certifikáty, otp, apod.

Internet nejsou jen prohlizece...tolik k tomu API na klientske strane.

Je spousta služeb, které jsou dostupné jenom přes HTTP. Kdyby pro HTTP existoval standard pro bezpečné vytváření účtů a přihlašování, většina úniků hesel v posledních letech by se nestala, protože by nebyla vůbec technicky realizovatelná. V HTTP je definována autentizační metoda Digest, která je takovým náznakem – jenomže má šílené UI a UX, a chybí k ní ta registrační část, aby se provozovatel serveru nedozvěděl heslo ani při vytváření účtu a tudíž si ho ani nemohl špatně uložit.

Naprosto souhlasím s panem Veberem, tohle je selhání všech, kteří se pohybují kolem bezpečnosti webových prohlížečů. Co se týče bezpečnosti, je to důležitější než HTTPS (a to je pro mne HTTPS bez diskuse must have), důležitější než PNA, důležitější než různé same-site ochrany.

Pořád se řeší, jestli se ze seznamu fontů a rozlišení obrazovky nedá jednoznačně identifikovat konkrétní prohlížeč – ale že prohlížeč bez mrknutí oka vyžvaní vaše heslo, to nikoho netrápí.

To sic.

Ale pak by ta implementace musela byt nederava v kazdem klientovi, od lynx, linkx, wget, curl, php, nodejs, a dalsich a dalsich, vcetne reseni zavislosti na verzi (resp. aktualizace protokolu, security atd.) casove i pres 10 let. A tohle roztahnout pres veskere firmy, ruzne produkty s ruznymi pozadavky (2FA, SSO, crt, atd.).

Myslim, ze jednotny format je utopie.

Ano, stejně jako musí být v každém klientovi neděravá implementace TLS. Přičemž ta hesla jsou řádově jednodušší, než TLS. Kdyby se s tím začalo před dvaceti lety, kdy byl nejvyšší čas, už by to dávno bylo všude implementováno.

Nevím, co je utopického a o jakém jednotném formátu je řeč. Už HTTP/1.0 má HTTP Digest autentizaci, což je takový zárodek toho, co by bylo potřeba. Chybí k tomu ta první polovina – registrace účtu. A pak by se to samozřejmě muselo povýšit na moderní standardy – HTTP Digest je založené na MD5. V HTTP protokolu je to už ale od dob dinosaurů, podporují to servery i prohlížeče (i když z uživatelského hlediska špatně). Ale technologicky to fakt není problém, problém je jenom to, že to nikdo netlačí, protože všichni pořád spokojeně posílají hesla v otevřeném tvaru.

Když vy jste takový teoretik, pane Jirsáku... A jinak ty same-site ochrany sice možná nezajímají vás, za to zajímají provozovatele webů.

Jenže provozovatele webů by mělo daleko víc zajímat, že jim pořád někdo nutí hesla uživatelů v otevřeném tvaru, a oni se pak o ně musí pořád starat a hlídat je, aby nikam neunikla.

Přes zákazy cesta nevede, pro tlachání stačí srandaheslo klidně v otevřené podobě s únikem musí zodpovědný uživatel stejně počítat, pro důležité věci jsou tu klíče.

Nějak nechápu, jak by jako to API mělo fungovat, zkuste to prosím dovysvětlit.

Pokud chcete příklad něčeho, co už je v prohlížečích implementované, pak se podívejte na HTTP Digest autentizaci. Dnes by to samozřejmě chtělo něco modernějšího, třeba OPAQUE. Něco k tomu třeba zde: OPAQUE: The Best Passwords Never Leave your Device

Ten návrh som celkom nepochopil, ak by solil klient, čo by bolo uložené na serveri? V podstate by tam bolo len expandnuté heslo, čo je to isté ako keď si dnes pri registrácii užívateľ vygeneruje náhodné heslo, (alebo svoje heslo transformuje hashom na zložitejšie).
Existuje aj HTTP Digest Authorization, neviem, či to podporujú prehliadače a či sa to používa, pri použití TLS to asi nemá význam.

Význam je v tom, že server nezná uživatelovo heslo, takže se provozovatel webu (ani nikdo jiný, když uniknou uložené údaje) nemůže přihlásit na jiný web (nebo dokonce nějaký interní IS), pokud uživatel používá stejné heslo na více místech.

Ale čo by prinieslo nové API na prehladači? Sol by bola z čoho generovaná? Ak náhodne, kde by sa pamätala? Ak v nejakom sprívcovi solí, tak v čom je rozdiel oproti správcovi hesiel?

Podstata solení je v tom, že i stejná hesla mají díky rozdílným solím jiný hash. Obecně jde o to, že pokud máte ve službě statisíce uživatelů je narozeninový efekt jistý, zkrátka několik desítek až stovek uživatelů tam bude mít stejné heslo a pokud to neosolíte i stejný hash. Z těch hash pak hned poznáte kteří.

Navíc existuje něco jako rainbow tables, kde jsou vygenerované hashe a k nim zpětně hesla. Takže už z těch hash je možné zpětně snadno zjistit jaká hesla se k nim váží - alespoň pro taková běžná hesla. Pokud to osolíte komplexnost potřebných ranbow tables roste a to s mocninou bitů, které může sůl obsahovat a přestávají být použitelné.

Z toho důvodu se hesla solí. Reálně pokud budete mít API, které se bude o hesla "starat" bude muset komunikace fungovat tak, že při zadání nového hesla pošle klient na server kombinaci (náhodná sůl, hash hesla) -> to se uloží na serveru, a to "může" uniknout.

Za předpokladu, že je zvolena rozumná hash a rozumný rozsah (množství bitů) soli, bude útočníkům trvat roky, než jedno takové heslo prolomí a do toho se nebude chtít nikomu investovat.

V případě ověření to funguje tak, že server pošle klientovi nejdříve sůl s jakou má uložené heslo a klient pošle na server výsledný hash zadaného hesla se zapojením dané soli. Server pak už jen ověří, zda je hash jakou má stejná jako ta co dostal.

Není k tomu třeba v základu řešit nic navíc, myslím že je to snadné, ale... zkrátka nebyla vůle to prosadit, i přes zjevné nedostatky stávající metody. Ano, bude třeba řešit povýšení API na jiné algoritmy, protože stávající dříve nebo později zastarají. Pokud však nebudu hashovaním zadaných hesel zatěžovat server mohu zvolit i poměrně silné hash algoritmy aniž bych způsobil výkonnostní problémy serveru na který se přihlašuje současně velké množství uživatelů.

Není to odolné vůči ph*gu, ale zajistí to odpovídající odolnost proti takovýmto únikům - technicky vaše heslo takto neunikne i když ten ph*ng bude úspěšný, ale útočníkům takto bude stačit ta kombinace (sůl, hash) o kterou si mohou říct na vlastní stránce. Pro vás ale i takový únik neznamená nutnost měnit heslo, jen znovu zadat (klidně stejné) heslo v dané službě (které se únik týkal), aby tam heslo bylo s jinou solí.

Nové API v prohlížeči by přineslo to, že by se provozovatel webu nikdy nedozvěděl heslo v otevřeném, tvaru nebo jeho ekvivalent. Takže i pokud uživatel používá heslo na více webech, provozovatel jednoho webu by údaje, které zná, nemohl použít pro přihlášení jménem uživatele na jiný web. A případný únik by neohrozil jiné účty uživatele, případně ani samotný účet u webu, odkud hesla unikla (záleží na konkrétním protokolu, zda by server znal údaje potřebné pro přihlášení nebo ani to ne).

Sůl do toho nemíchejte, náhodná sůl není pro bezpečné uložení hesel nutnou podmínkou.

To je fakt takovy problem generovat unikatni hesla?

Pro uživatele, kteří nepoužívají správce hesel, to problém je. A takových uživatelů je stále většina.

Mimochodem, prohlížeče už dlouho mají vestavěnou takovou demoverzi správce hesel. Ty demoverze dlouho neuměly unikátní hesla generovat – mám pocit, že teď už to konečně některé prohlížeče umí. Ještě se divíte, že je pro spoustu uživatelů problém generovat unikátní hesla?

Prohlížečoví správci hesel jsou bezpečnostní díra jako kráva. Pokud vím, Chrome ještě donedávna hesla ani nešifroval a teď, když je šifruje "heslovou frází účtu Google", se uživatele na heslo neptá = někde má v plaintextu klíč. Některé jiné prohlížeče mají možná v plaintextu přímo i to heslo.
Navíc bylo mnohokrát prokázáno, že prohlížeč je schopen heslo vyžvanit komukoliv - dřív si třeba stačilo na stránce nehlídat iframe. Plně automatický autofill (jakožto feature zapnutà by default) zase zajišťuje, že prohlížeč heslo vyžvaní nejen komukoliv, ale i kdykoliv.

21. 1. 2022, 07:27 editováno autorem komentáře

To, že prohlížeč lokálně hesla nešifruje (nebo tak, že jsou snadno dešifrovatelná bez zásahu uživatele), je daleko menší bezpečnostní problém, než to, že heslo zná provozovatel webu. Vždyť si to stačí porovnat – u nešifrovaného lokálního uložení hrozí riziko, že se heslo dozví někdo další, u přihlašování webovým formulářem je jistota, že se heslo dozví někdo další (provozovatel webu).

Že prohlížeč vyžvaní heslo komukoli a kdykoli, to je problém, o kterém se diskutuje výše. Ano, přihlašování a registrace účtů by měla být řešena přímo na úrovni HTTP protokolu tak, aby heslo v otevřeném tvaru nebo ekvivalentu nikdy neopustilo bezpečnou část prohlížeče. Bohužel realita je taková, že se i v roce 2022 stále přihlašujeme plaintextem.

V českých e-kvelbech účty mít nemusíte. Jak je tomu na Slovensku, nevím.

Á, pardón, v důsledku jazykových nedostatků vašeho příspěvku jsem špatně pochopil, co píšete.

„hašů hesel“

Haš je hašiš, ne? Takže buďto „hashů“, nebo „hešů“.