Vlákno názorů k článku
Meta zaplatí pokutu 91 milónů eur za hesla v plaintextu od Vladki - To je sranda číst tu diskusi. Když nechcu ukládat...

To je sranda číst tu diskusi.

Když nechcu ukládat plaintext heslo, ale jen hash, tak musím poslat heslo v plaintextu (šifrovaným kanálem) aby si server ten hash mohl vytvořit.

Když nechcu posílat heslo, ale hash, tak musí mít server uložené plaintext heslo aby si hash udělal sám.

Ale neznám auth metodu, která by fungovala s hashem jak na servru tak v komunikaci, a netrpěla na replay attack, kdy odposlech hashe je postačující pro příští přihlášení.

Pokud ano, prosím o osvícení...

Ono je možné odposlechnout https přenos?

Nevím jestli je něco takového běžně implementované v prohlížečích, ale jinak to jde třeba takto: z hesla si deterministicky vygenerujete soukromý klíč pro asymetrickou kryptografii, a následně použijete ten algoritmus co používá SSH při přihlašování klíčem (u HTTPS existuje přihlašování certifikátem, což funguje podobně).

Tu sa bavime o ochrane v pripade ze je napadnuty server. Ten vam moze podstrcit challenge z ineho servera kde sa chce vasim uctom dostat a ked mate rovnake heslo aj tam tak sa tam dostane.
Takze sme vsetko super prekomplikovali ale nic sme nezlepsili.

Tohle je mnohem komplikovanější útok, který vyžaduje plnou kontrolu serveru místo jednoduché exfiltrace databáze. A navíc řešení dávno existuje a používá se. Uživatel se identifikuje podepsaným payloadem (většinou JWT, další alternativa je Paseto token), který obsahuje zamýšleného příjemce tokenů (u JWT je to AUD). Pokud si napadený server vezme payload a zkusí ho použít jinde, jiný web je s tím pošle do háje.

Chápu správně, že tvrdíte, že když používám stejný SSH klíč pro servery A a B, tak server A může nějakým způsobem zproxovat přihlašování na server B a přihlásit se tam místo mě?

To mi přijde neuvěřitelné, a dokonce si myslím, že to nejde ani v případě, kdy budu slepě odklikávat takové ty hlášky že klíč protistrany není známý/změnil se.

Ja som to pochopil inak a možno keď to spíšem, tak sa mi utriedia myšlienky.

Máme dva servery, kam sa klient prihlasuje kľúčom (môže byť SSH). Jeden je napadnutý útočníkom a má ho plne pod kontrolou.

Vy sa pokúsiťe prihlásiť na ten napadnutý server a ten urobí to, že preproxuje ( nie priamo, ale s úpravami) spojenie na cielový server, ktorý ešte nemá pod kotrolou. Urobí naň výzvu, To čo sa má podpísať pošle vám, vy to podpíšete mysliac si, že ide o prvý server (ten napadnutý), napadnutý server prevezme odpoveď a pošle ju na server, ktorý sa snaží napadnúť. A voilá, je tam.

Možno si to predstavujem veľmi jednoducho.

> budu slepě odklikávat takové ty hlášky že klíč protistrany není známý
A dokonca ani to sa nestane, lebo spojenie so serverom A je validne. Proste iba challenge servera A bude ten zo servera B a potom odpoved poslete na server B.
Z toho isteho dovodu mate iny kluc na podpisovanie dokumentov a iny na prihlasovanie. Teoreticky by vam server mohol podhodit ako challenge hash nejakeho dokumentu a ak ho podpisete 'podpisovym klucom' tak ma vami podpisany dokument.

Když nechcu ukládat plaintext heslo, ale jen hash, tak musím poslat heslo v plaintextu (šifrovaným kanálem) aby si server ten hash mohl vytvořit.
Nemusím.

Když nechcu posílat heslo, ale hash, tak musí mít server uložené plaintext heslo aby si hash udělal sám.
Nemusím.

Ale neznám auth metodu, která by fungovala s hashem jak na servru tak v komunikaci, a netrpěla na replay attack, kdy odposlech hashe je postačující pro příští přihlášení.
To umí i hloupá autentizační metoda HTTP Digest, standardizovaná v roce 1997.

Vtip je v tom, že těch hashů je víc. Na serveru je uložený hash odvozený ze jména, hesla a domény. V komunikaci se pak posílá hash odvozený z prvního hashe a výzvy poslané serverem.

Jak tak koukam na diskuzi, tohle tema by stalo za clanek.

Skuste si pozriet take mTLS. To by v podstate stacilo, dokonca by vam stacil certifikat od hociktorej uznavanej autority aby ste si nemuseli nikde zriadovat ucet a vsade vas 'poznali'.

O HTTP digest sem si cetl kdyz to byla 5 let zhava novinka, tak sem si to precetl znova... A nepamatuju si to az tak spatne, cituji z wikipedie:

A server can store HA1 = MD5(username:re­alm:password) instead of the password itself. However, if the stored HA1 is leaked, an attacker can generate valid responses and access documents in the realm just as easily as if they had access to the password itself. The table of HA1 values must therefore be protected as securely as a file containing plaintext passwords.

Kdyz se nad tim zamyslim, tak ano porad je to lepsi nez primo plaintexty, protoze to v pripade uniku jde pouzit pouze pro prihlaseni k te postizene sluzbe, a nejde to vytezit na databazi hesel pro jine sluzby (kde by mohl byt stejny login a heslo) protoze aspon realm bude jiny (snad). A taky to zabrani pripadnemu odposlechu hesel na napadenem servru.

Jak tam ale pisou ze tyhle digesty by mely zabranit phishingu, tak o tom pochybuji. Pokud se dostanu na phishingovou stranku, a ta misto digestu pouzije basic auth, tak si to ani nevsimnu, a heslo poslu... Aspon sem si teda nevsiml ze by prohlizece nejak prominentne informovaly jestli se pouziva basic nebo digest. A to nemluvim o tom, ze HTTP auth se vubec pouziva strasne malo.

Kazdopadne nejaky clanek o tom jak to udelat nejlepe (a prakticky) - aby heslo nebylo ani na servru ani nikde po ceste v plaintextu by bylo zajimave. Zatim mi z toho vychazi jenom autentizace klientskymi SSL certifikaty, a s tou jsem se na webu nikde nepotkal. (pouze SSH klice jedou na stejnem principu). Pripadne nejake ty kerberosy, a autentizace pres 3. stranu (mojeID)? Ale i tam to heslo nekde lita, takze je to jenom prehozeni problemu na jiny server.