Vlákno názorů k článku
Z webu OpenSubtitles uniklo sedm milionů uživatelských účtů včetně MD5 hašů hesel
od JVr - Poučení zní, jakékoliv služby by měly mít zakázáno...
-
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.
-
Filip JirsákStříbrný podporovatelJe 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.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
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.
-
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í.
-
Filip JirsákStříbrný podporovatel
Když to bude implementované JavaScriptem, nebude to mít ten nejpodstatnější efekt, že se provozovatel webu to heslo vůbec nemůže dozvědět.
-
O tomto jsem již několikrát uvažoval, a ano, je to řešení. ALE!
- Chybí tam standardizace tzn. každý si to nabastlí, jak ho zrovna napadne a může to dopadnout přesně tak, jako v případě výše zmíněného OpenSubtitles (bude tam MD5 bez solení), nikam se neposuneme.
- Chybí tam důvěra 1 jak píšu, ten skript je sice klientovi přístupný, ale pokud bude rozumně obfuskovaný a bude s tím heslem dělat psí kusy, nemám nad tím kontrolu. Kdo bude každou stránku kontrolovat, jestli to heslo stejně nepošle v čitelné podobě na server? Toto zkrátka považuji za práci s přísně důvěrným údajem, kterou bych rád svěřil auditovanému kódu (ten prohlížeče mají) a ne nějakému JS, co na stránku nabastlil Franta z Horní Dolní.
- Chybí tam důvěra 2 Problematika XSS a XSRF, kdy mi někdo může takový JS klidně podstrčit… popř. poslat heslo k sobě místo toho kam má jít...
NE, děkuji, tudy cesta nevede!
21. 1. 2022, 13:21 editováno autorem komentáře
-
„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.“
Když útočník získá dobrovolně od serveru sůl, čímž solení ztratí smysl, a ještě k tomu může poslat k ověření serveru rovnou hash získaný z úniku, aniž by něco musel vůbec počítat, v čem pak spočívá to zabezpečení hesla a autentizace?
-
Sůl není nic tajného, je to něco (náhodně vygenerovaného) co se "přimíchává k heslu", aby se výsledné hash lišily i při stejném hesle. Tzn. její vyzrazení vám nic neřekne.
Solení neztratí smysl, je tam kvůli tomu, aby hashe nebylo snadné v případě úniku hashe přeložit rainbow-tables anebo identifikovat uživatele s totožným heslem.
Hash získaný z úniku se bude s vysokou pravděpodobností lišit od toho, co je na serveru, protože sůl se bude lišit (sůl ovlivní výsledný hash) a v důsledku i hash se bude lišit.
Zabezpečení hesla tady spočívá v tom, že pokud vám unikne hash a sůl v jedné službě nikomu to nepomůže v uhodnutí hesla v jiné službě, protože při použití rozumného hash algoritmu a jiné soli není schopen zpětně získat heslo a díky rozdílné soli se hash liší. Ano, existuje nenulová pravděpodobnost, že jiná služba zvolí stejnou sůl při stejném hesle, ale tato pravděpodobnost klesá s druhou mocninou bitů soli.
Tzn. v případě, že vám unikne kombinace účet, hash, sůl má teoreticky útočník šanci k jiné službě přistoupit s vaší účtem a ověřit, zda je sůl totožná a následně využít získaný hash aniž by jej zpětně převáděl na heslo. Nicméně korm toho, že vaše heslo reálně nezná, tak ta pravděpodobnost, že najde někde jinde match v kombinaci účet, sůl při dostatečném množství bitů v soli (a tam zrovna budete mít stejné heslo, tedy hash bude odpovídat), se bude limitně blížit nule. V porovnání se současným stavem jsme někde úplně jinde.
Pokud mluvíte o bezpečnosti z pohledu onoho ph*gu, tak jak jsem psal, takovou ochranu toto schéma nenabízí, pokud vás útočník vmanipuluje do situace, kdy k jím požadované soli zadáte heslo, může přístup k nějaké službě, která využívá totožnou sůl a heslo „prolomit“. Problém bude mít s ostatními službami, které využívají jinou sůl. Pokud to porovnám se současným schématem, kdy získá rovnou heslo, a to může zadat do všech služeb, co na netu najde, je to o maličko lepší…
21. 1. 2022, 13:05 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Aby nebyly hashe stejného hesla napříč weby stejné, stačí místo soli k hashi přidávat hostname serveru.
Posílat serveru nejprve login uživatele a k němu server pošle sůl by byla bezpečnostní díra, protože by umožňovala zjistit existenci loginu bez znalosti dalších údajů.
-
Filip JirsákStříbrný podporovatel
Pokud by to bylo takhle jednoduché, nezačal by někdo hned počítat rainbow tables k nejzajímavějším doménám?
Hashuje se trojice doménové jméno (případně zleva oříznuté, aby třeba s www a bez www mělo stejný hash), login a heslo. Dělat rainbow tables na kombinace login+heslo se nevyplatí. -
Filip JirsákStříbrný podporovatel
Sice netuším, proč v příspěvcích řešíte shodu přihlašovacích údajů přes více služeb (o tom zprávička nebyla)
Ono to ve zprávičce není explicitně napsané, ale největší průšvih těchto úniků je v tom, že spousta lidí používá stejné heslo na spoustě webů (a nejen tam). Na webu, odkud hesla unikla, se obvykle všechna hesla zneplatní – takže paradoxně ten web zodpovědný za únik je pak jediný, kam se útočník nedostane.možná byste mi mohl říci, v čem spočívá přínos vašeho řešení s API proti řešení s hashováním a solí na serveru.
To bych mohl. Přínos řešení s API je ten, že je to řešení, opravdové řešení. Server se nedozví heslo ani jeho ekvivalent, takže ho nemůže zneužít ani provozovatel, ani nikdo jiný.Hashování a solení na serveru naproti tomu řešení není, protože já si klidně můžu na web vystavit obrovský nápis, že hesla hashuju se solí i s pepřem, ale můžu si je dál ukládat v plaintextu. Ať už záměrně, nebo omylem. Vy nemáte šanci, jak to zjistit, dokud nenastane průšvih. Vždyť už dnes všichni předpokládají, že server ukládá hesla bezpečně – a je to jeden únik za druhým. Takže víra v tomhle případě evidentně nestačí, jediná možnost je ta, že se provozovatel webu heslo nikdy nedozví.
-
Filip JirsákStříbrný podporovatel
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.
