Vlákno názorů k článku Postřehy z bezpečnosti: pomsta ztraceného telefonu od Filip Jirsák - Hlavně že se pořád řeší hashování hesel v...

Hlavně že se pořád řeší hashování hesel v databázi na serveru, ale odesílání hesla v otevřeném tvaru z klienta je považováno za normální. Pak to takhle dopadá.

double hashing, kedy jeden prebehne ešte na strane klienta a druhý na strane servera znie zaujímavo, ale nemalo by byť toto riešené už pomocou HTTPS/SSL, akurát iným spôsobom, ale vlastne že nejde to heslo v surovom tvare cez sieť?

4. 10. 2021, 12:16 editováno autorem komentáře

HTTPS/SSL je něco jiného, to zajišťuje šifrovaný kanál. Ale jinak ano, tohle by mělo být přímo součástí HTTP standardu – heslo by měl hashovat rovnou prohlížeč a měl by zaručovat, že s heslem se pracuje jen v bezpečné části prohlížeče a ven (do skriptů, do HTTP požadavků apod.) se dostane jedině zahashované heslo.

A čemu přesně tohle hashování v prohlížeči bude bránit? Když se útočník dostane k tomu zahashovanému heslu, tak ho prostě na ten server pošle v tom zahashovaném tvaru. Vůbec nemusí rekonstruovat předlohu v té bezpečné části prohlížeče.
Jaká situace by musela nastat, aby útočníkovi co má přístup k těm prohlížečem zahashovaným heslům byla k něčemu užitečná i ta nezahashovaná?
I kdyby prohlížeč ta hesla hashoval na požádání s dodanou solí, tak je nabořený komunikační kanál a útočník může solit podle svých chutí.

> I kdyby prohlížeč ta hesla hashoval na požádání s dodanou solí, tak je nabořený komunikační kanál a útočník může solit podle svých chutí.

Navyse v tomto pripade by musel mat server heslo ulozene v plaintexte, aby si vedel dany hash overit.

Hashování v prohlížeči nemusí být tak triviální, jak si představujete. Součástí hashe může být výzva serveru, takže pokud se útočník dostane k obsahu komunikace, bude mu to k ničemu, protože získaný hash nebude moci použít k ničemu. Představte si schéma hash(výzva serveru + tělo požadavku + hash(identifikace serveru + login + heslo)). Server má uložené jen hash(identifikace serveru + login + heslo). Údaje, které zná server, nelze použít pro přihlášení k jinému systému. Údaje, které putují po síti, lze použít nanejvýš pro zopakování stejného požadavku (pokud si server nebude pamatovat použité výzvy).

hashovanie na klientovi neriesi, nic. Docieli sa tym iba to, ze namiesto lobovolneho retazca posiela iny, vzdy s rovnakych znakov a vzdy konkretnej dlzky. Bezpecnosti to nijak nepomohlo.

Ako clovek co sa v IT uz nejaky cas pohybuje viem, ze hashovanie hesla s challnege na serveri bolo (asi aj stale je) sucastou HTTP specifikacie- nejaky derivat HTTP Basic autorizacie. No ta sa nikde neujala.

Pardon, malo to byt na klientovi - https://en.wikipedia.org/wiki/Digest_access_authentication

Je hezké, že nejprve napíšete, že to nic neřeší, a pak dáte odkaz na stařičké řešení, které uvedený problém řeší. A od té doby samozřejmě doba pokročila a máme modernější autentizační schémata, třeba SCRAM (pro HTTP definováno už od roku 2016).

V otevřeném tvaru by to bylo nebezpečné, od toho tu máme TLS.

Bylo by to bezpečné i v otevřeném tvaru. Ale to je jedno, o to tady nejde. Jde o to, že máme tisící první důkaz toho, že neplatí předpoklad „klient vždy komunikuje se správným serverem a server je vždy naprosto bezpečný a bezchybný“.

Vážně považujete posílání hesel v otevřeném tvaru po síti za bezpečné? To budete ve výrazné menšině, protože většina bude považovat možnost odposlechnutí síťového provozu za znepokojivou.

K tomu aby platil předpoklad "klient vždy komunikuje se správným serverem" existuje TLS které to při správné implementaci zajistí. Je to postup jak se použitím existujícího standardu vyhnout nutnosti komplikovat spousty protokolů na aplikační úrovni.

No a předpoklad "server je vždy naprosto bezpečný a bezchybný" je jen marný výkřik, na tom se živí spousta IT pracovníků a stejně to nemá stoprocentní řešení.

Vážně považujete posílání hesel v otevřeném tvaru po síti za bezpečné?
Myslím, že když si přečtete můj první komentář v diskusi, kde kritizuji posílání hesel v otevřeném tvaru šifrovaným kanálem, po jednoduché úvaze dojdete k tomu, že posílání hesel v otevřeném tvaru nešifrovaným kanálem nebudu hodnotit o nic lépe.

K tomu aby platil předpoklad "klient vždy komunikuje se správným serverem" existuje TLS které to při správné implementaci zajistí.
Tak si přečtěte kapitolku „Závažný bug v Microsoft Exchange Autodiscover funkci vyzrazuje uživatelská hesla“ v článku, pod kterým diskutujete. A zjistíte, že nezajistí.