Vlákno názorů k článku
Meta zaplatí pokutu 91 milónů eur za hesla v plaintextu od Saljack - Já nedokážu pochopit, že tohle někdo udělá a...

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ží.