Názory k článku
Meta zaplatí pokutu 91 milónů eur za hesla v plaintextu

Já nedokážu pochopit, že tohle někdo udělá a že nikoho kdo nad tou databází dělal nějaký dotaz tohle nenapadlo. Tohle chování je naprosto neomluvitelné.

To nie je problém len kvôli tomu že zamestnanci majú prístup k databáze, ale aj kvôli tomu že ak databáza unikne, no tak máš po účtoch.

Mať účet na Meta (Facebook, Instagram, WhatsApp, Messenger), je doslova riskovanie.

Pro mne je teda mnohem víc nepochopitelné, že prohlížeče odesílají heslo v otevřeném tvaru, a všichni se tváří, že je to v pohodě. Přitom to je ten největší problém. Ledabylé zacházení s hesly na serveru je samozřejmě omluvitelné – právě tím, že když mi prohlížeč to heslo prozradil, tak proč bych s ním já měl zacházet výrazně lépe, než prohlížeč.

Práveže ak odosiela v textovej podobe tak je to správne (a ono to vlastne v textovej podobe neposiela, lebo je to SSL šifrované)... ak by hash posielal už priamo prehliadač, tak to znamená že API prijíma hash, takže ak by unikla databáza s hashom, tak by vlastne sa vedel hocikto prihlásiť. Takto je nutnosť z hashu dostať to pôvodné heslo, ktoré APi prijíma. Takto je útok obmedzený len na útok v pamäti servera, čo je najmenšie riziko. Samozrejme tu ale záleží už od alokovaní. Problém je u jazykov s GC, kde nikto nikdy nevie kedy sa objekt uchovávajúci to heslo uvolní.

30. 9. 2024, 15:00 editováno autorem komentáře

Naštěstí už 45 let existuje asymetrická kryptografie, takže heslo ani nemusíme posílat na druhou stranu, ani nemusíme na druhou stranu posílat nic, čehož odchycení by umožnilo v budoucnu přihlášení.

Ne, takhle to opravdu není, kryptografické algoritmy jsou mnohem dál.

To s tým nemá nič spoločné... vždy ak API očakáva "A" a informácia "A" je prezradená, tak je absolútne jedno aká je podoba "A", a či je to šifrovaná podoba informácie "B".

Problém je v tom, jak má prohlížeč poznat, která informace z té přehršle dat je heslo a že je zrovna v plaintextu.

Zde má kompletně máslo na hlavě jen a pouze Meta, která nastavila ten proces právě takhle.

Aby to bylo bezpečné, nemohlo by se to vůbec zadávat do webové stránky, ale do speciálního dialogu prohlížeče. Takže prohlížeč by to poznal velice snadno – prostě první řádek by byl login a druhý heslo. Ostatně v HTTP protokolu je autentizace na úrovni protokolu specifikovaná, akorát k tomu měly prohlížeče otřesné UI. Jenže místo toho, aby se UI spravilo a protokol zmodernizoval, na bezpečnost se úplně rezignovalo a necháváme hesla zadávat do webové stránky, ta je pak posílá v otevřeném tvaru na server – a pak si všichni divý, že server to heslo zná.

Meta má máslo na hlavě pouze v tom, že v tomhle případě nehraje jako ostatní hru „tváříme se, že server heslo nezná, i když ho zná“.

Nehájím Metu. Jenom mi vadí, že se tohle řeší jako velký problém, ale mlčí se o tisíckrát větším problému, který je příčinou toho, že vůbec Meta mohla takovouhle chybu udělat.

Není to ani týden, co jsi pod jiným článkem argumetnoval, že se systémy mají přizpůsobovat realitě. Opravdu nechápu, jak můžeš zároveň zastávat princip A a zároveň princip not A.

Připomínáš mi inženýra, co počítá nosnost výtahu a nadává, proč se lano počítá s bezpečností k=10, když si křídla letadel můžou dovolit být jen o chlup nad jedničkou. Ten rozdíl stejně tam jak tady existuje kvůli úplně odlišnému riziku. Zatímco heslo letí - dnes už šifrovaným - kanálem a v otevřené podobě tam existuje po dobu mrknutí oka, v databázi leží a leží a vysloveně si říká o nějaký průšvih. *

Je ustálenou praxí zacházet s hesly speciálně, protože hesla jsou něco speciálního. Otevřené mléko taky potřebuje speciální zacházení a když ho nechám týden na lince, tak se nemám co divit, když ho zkusím a bude zkažené.

[*]: u výtahů se bezpečnost přehání proto, že se silnou bezpečností a jednoduchým výpočtem učiní za dost i výpočtům složitým, jakým je namáhání lana v ohybu. Opět mi to přijde jako dost vhodná analogie: meta zvlášť mohla nasadit takové prostředky ověřování, aby heslo v otevřeném tvaru neopustilo prohlížeč (byť by si takové řešení museli přiohnout). Ale neudělali to, tady ušetřili a zapomněli tam přidat a když jim to křachlo, dostali zcela po zásluze přes prsty.

Já jsem ale v této diskusi nikde netvrdil, že se systémy nemají přizpůsobovat realitě. Pokud se něco v realitě používá a je to velmi nebezpečné, upozorňování na tu nebezpečnost nepovažuju za „nepřizpůsobení se realitě“.

Kdyby heslo v otevřeném tvaru nikdy neopustilo prohlížeč, nemůže ležet v databázi. To, že heslo letí šifrovaným kanálem, je jenom maličká část zabezpečení. Když z toho šifrovaného kanálu vypadne na serveru, není v bezpečí. Jak ukazuje právě i tento případ, kdy se to heslo v otevřeném tvaru uloží do databáze. A jak ukazují tisíce jiných případů, kdy je heslo v logu, uložené v databázi slabě zahashované, slabě zahashované nebo v otevřeném tvaru někde v záloze… Navíc to heslo se posílá při každém přihlášení znovu a znovu.

Jinak mne zrovna únik hesla trápí ze všeho nejméně, protože to heslo je unikátní jenom pro jednu službu a nic neznamená. Únik všech ostatních informací, které jsou někde evidované, mi vadí víc. Ale realita je taková, že spousta uživatelů používá jedno heslo na více místech. A to je problém. Problém je, že Facebook zná něčí heslo k e-mailu a souborovému úložišti, e-shop zná jeho heslo k Facebooku a k bankovnictví atd.

Řešení tohoto problému opravdu není v tom, že teda dobře, ať Facebook to heslo k e-mailu a souborovému úložišti zná (nebo ho může zjistit, kdy se mu zachce) – ale ať předstírá, že ho nezná. A pokud to bude předstírat špatně, tak ho potrestáme a budeme se mu smát, jak je bezpečnostně neschopný.

Meta měla prohlásit, že zaměstnanci měli povinnost zavřít oči pokaždé, když viděli v té databázi hesla. Protože přesně tak se s hesly na webu zachází – to heslo tam je sice napsané, ale když zavřu oči, tak zmizí, takže je vše v pořádku.

Je ustálenou praxí zacházet s hesly speciálně, protože hesla jsou něco speciálního.
To je právě ten problém, že se s hesly zachází speciálně, místo aby se s nimi zacházelo bezpečně.

TLS je plaintext? A je navíc uložený na trvalém úložišti? "proč bych s ním já měl zacházet výrazně lépe" - koukám, že se překonáváte.

1. 10. 2024, 08:23 editováno autorem komentáře

TLS je šifrovaný kanál mezi prohlížečem a serverem. Server ovšem z šifrovaného kanálu všechna data vybalí a má je k dispozici v otevřeném tvaru. Co s tím heslem server udělá je už čistě na jeho provozovateli (případně útočnících, kteří se na server dostanou). Jestli provozovatel serveru (nebo útočník) to heslo hned zahashuje, nebo he zapíše do textového logu, nebo ho prodá na darknetu, to jako uživatel nevíte. Jediný způsob, jak jako uživatel můžete zařídit, aby server neprováděl s heslem něco nekalého, je vůbec to heslo webové stránce nepředávat.

Ano, bezpečné zacházení s hesly by bylo takové, že by heslo v otevřeném tvaru nebo jeho ekvivalentu vůbec neopustilo bezpečnou část prohlížeče. Cokoli jiného je jen Potěmkinova vesnice a u každé informace o tom, že provozovateli serveru unikla hesla, by mělo být uvedeno, že hlavní problém byl už v tom, že se ta hesla vůbec dozvěděl.

Prohlížeč udělá maximum pro bezpečnost (neposílá žádný plaintext, ale šifrovaně přes TLS). Pokud je na straně serveru inteligent "Ledabylé zacházení s hesly na serveru je samozřejmě omluvitelné", tak si pokutu rozhodně zaslouží.

Ja to nechci procitat, muze mi jen nekdo strucne vysvetlit, proc by za spatne ulozena hesla mela Meta dostat pokutu? Ja to vidim tak, ze je to soukroma spolecnost, ktera si s nasimi daty muze delat cokoliv, co jsme jim odsouhlasili v podminkach, takze pokuta by byla na miste pouze v pripade, ze by mela nekde explicitne napsano, ze k nasim heslum nema pristup, protoze jsou nekde zasifrovana a pak by klamala a lhala.

Protože zákony jsou nad dohody takže určité věci se nesmí a jiné musí i kdyby jste se stokrát dohodli jinak. V digitálním světě je to ještě celkem novinka všude jinde je to běžné. Jsou nějaké předpisy jak skladovat potraviny, jak paliva, jak munici, jak hesla. Něco je závazné něco doporučené, něco je smysluplné něco zmršené… a pořád vznikají další, anarchie dávno skončila, i ta digitální.

Tot otazka jakou vhodnou paralelu vymyslet. Pravidla a zakony na nakladani s munici maji vysoky spolecensky zajem, protoze hrozi nehody s vaznymi nasledky. To same zakony pro nakladani s potravinami - otravy jidlem. Ale napriklad zakon neupravuje ze skrine musi byt pripevneny ke stene, to je ciste ponechano na blbosti lidi jestli jim spadne na hlavu nebo ne.
A jaky je zajem na uprave chodu facebooku? Prece jen nikdo nenuti nikoho to pouzivat, a pokud tam naladuje sva osobni data, je to jeho blbost. Problem s hesly je spis obecny dusledek - chceme aby vsechny firmy spravne ukladali hesla, protoze lidi pouzivaji stejna hesla pro vice uctu, a nekdy i pro dulezite ucty (napr. banka). Takze to ze facebook dostal pokutu je vlastne jen dusledek blbosti lidi, a kdyby tahle blbost neexistovala, pak by nebyl jediny duvod nutit facebook aby dobre pracoval s hesly.

Heslo se dá považovat za osobní údaj, vzhledem k jeho zneužitelné povaze, a máme hento GDPR.

K těm přišroubovaným skříním... To je trochu absurdní situace. Ještě nedávno jsem nezažil potřebu šroubovat skříně ke stěně.

Koupil jsem nedávno skříň, poskládal ji, umístil, otevřel ji a ona spadla a rozbila se. Prostě se převážila. Když jsem trochu pátral po tom proč, tak jsem zjistil, že dveře té skříně jsou z těžšího materiálu než stěny - prostě konstrukční vada. V minulosti jsem toto nikdy nezažil.

(Reklamace byla docela prdel, nechtěli o ní vůbec bavit - nakonec jsem jim na prodejně navrhl, aby tam sestavili další skříň - když nespadne, tak ji koupím a odvezu, jinak ať mi vrátí peníze. Všichni si byli tak jistí, že se nic nestane, že když spadla, tak praštila technika do hlavy a byl z toho ještě pracovní úraz.)

Osobně považuji nutnost šroubovat skříň ke stěně jako smutný pomník doby. Ať už pro výrobce, že vyrábí takový šmejd, ať už pro kupující, že nepřemýšlí.

Dekuji za vysvetleni. Uz problem chapu. Nicmene prijde mi ti smutne.

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.