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
To jedine v prípade, ak by mal buď prístup k tvojmu privátnemu kľúču, alebo by bol medzi vami v roli MITM. Prvý prípad je triv. fuckup, tam nie je čo riešiť. Na druhý existujú štandardné mechanizmy, ako takú situáciu detekovať/vylúčiť, viď napr. [1].
A aj ten MITM scenár (za predpokladu, že teda zlyhali všetky prostriedky, ktoré mu majú predísť, napr. niekto odignoroval upozornenia ohľadom certifikátov, má zavedený cert. alebo cert. autoritu podhodenú útočníkom a pod.) je stále o zneužiteľnosti čisto v kontexte tej jednej konkrétnej session. Autorizáciu mimo tento kontext mu odchytenie pokojne aj celej kumunikácie medzi vami neumožní.
2. 10. 2024, 09:59 editováno autorem komentáře
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 š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.
Vy to stále nechápete. Bezpečné heslo je takové heslo, které zná jenom uživatel (a jím ovládaný software) a nikdo jiný. Jakmile se to heslo zadá do webové stránky (kterou má pod kontrolou provozovatel webu, resp. možná útočník), dozvídá se to heslo někdo, kdo ho znát nemá.
Většina lidí používá jedno heslo na více místech, spousta dokonce používá všude to samé heslo. Takže třeba mají heslo k e-mailu, kam jim chodí spousta citlivých věcí. Stejné heslo mají na Faceboook, kde mají třeba soukromé fotky. A stejné heslo mají třeba tady na Rootu. Připadá vám v pořádku, že vaše heslo k e-mailu a vaše heslo k Facebooku pošle prohlížeč provozovateli Root.cz?
Je to srovnatelné s tím, kdybyste každému, kdo vám má něco doručit domů (úřadům, e-shopům, doručovacím společnostem, přátelům, vydavatelům, dámejídlům) dal klíč od svého bytu. A tvrdil byste, že s těmi klíči přece musí zacházet bezpečně. No, musí – ale nemělo by se začít tím, že nebudete dávat klíč každému, kdo si o něj řekne?
Já jsem nikde nepsal, že ledabylé zacházení s hesly na serveru je omluvitelné. Psal jsem, že je neomluvitelné ledabylé zacházení s hesly v prohlížeči, a je to daleko větší problém, než to zacházení s nimi na serveru.
I pak by bylo mírně lepší, kdyby se heslo na druhou stranu neposílalo, protože to rozšiřuje možnosti útoků a úniků. Může dojít k nějaké částečné kompromitaci, která nebude stačit pro zajištění přístupu/perzistence (útočník se třeba dostane na jeden z mnoha nodů v load balanceru kde se terminuje TLS -- může přepisovat různé věci v aktuální session ale nemůže dělat úplně všechno a napořád), ale heslo unikne. Nebo k té chybě kdy heslo vypíšete při chybě omylem do logu.
Teraz ste objavili zdroj vsetkych chyb
Jenže lidi nepředěláte a nenaučíte je pamatovat si desítky či stovky hesel. Správce hesel je také jen způsob, jak to obejít – heslo původně znamenalo něco, co si uživatel pamatuje, není to nikde uložené. Když už mám možnost nějaké tajemství uložit, dává daleko větší smysl používat klíče a asymetrickou kryptografii než hesla.
Správci hesel v prohlížečích jsou jen o málo méně špatné kusy softwaru, než byla podpora HTTP autentizace. Dlouho neuměly hesla generovat (což je klíčová funkce); neumějí k heslům přistupovat jinak, než z prohlížeče (některá hesla musím zadávat i jinde); neumějí uložit k autentizačním informacím další údaje; neumějí pracovat s hesly sdílenými napříč doménami; neumějí pracovat s OTP; zamknou vás na své platformě, protože neumějí export; neumějí poskytnout další funkce, jako sdílení v rodině…