Legraci si nedělám, v bezpečnosti to samozřejmě srovnatelné je. Teda pokud se bavíme o skutečně doporučených postupech, ne o tom vašem postupu – kterému odpovídá třeba i zahashování MD5 bez soli a pepře, z čehož nekvalitní hesla získáte raz dva. Že je to srovnatelné zjistíte tak, že porovnáte předpokládané vektory útoku a jejich pravděpodobnost, a porovnáte to s vektory útoku na jiné části systému, se kterými to srovnáváte. Opakování někde zaslechnutých pouček k porovnání opravdu nestačí – což je váš případ, protože pokud byste problematice rozuměl, nenapsal byste „jednosměrně nevratně přehašovat“. Protože „nevratně“ (v tom významu, jak jste to myslel) plyne z toho, že je to jednosměrné, a „jednosměrně“ je definiční vlastnost hashovacích funkcí. A naopak, nestačí to jenom nějak zahashovat – aby to bylo bezpečné, jsou na to hashování a další operace kolem dost podstatné další požadavky.
Že hash hesla spočítá JavaScript v prohlížeči není řešení, protože to pořád bude počítat kód, který ovládá provozovatel. Z hlediska bezpečnosti je jedno, jestli se k tomu heslu dostane v prohlížeči, odkud ho může poslat na server, nebo až na serveru. Pokud byste chtěl argumentovat tím, že je možné udělat audit kódu na klientovi – ano, můžete, ale při příštím načtení stránky může být ten kód jiný. Takže rozdíl mezi hashováním v prohlížeči a na serveru je asi stejný, jako mezi bezpečným uložením údajů pro ověření hesla pomocí hashování a bezpečným uložením výchozího hesla pomocí asymetrického šifrování – tedy drobné rozdíly v bezpečnosti tam jsou, ale jsou zanedbatelné vzhledem k tomu, jak obrovské bezpečnostní díry jsou všude kolem.
Děláte si legraci ? "Stačí ho třeba zašifrovat veřejným klíčem a privátní klíč mít uložený někde off-line" není v bezpečnosti srovnatelné ani náhodou s doporučeným postupem heslo okamžitě jednosměrně nevratně přehašhovat.
Jinak to co popisujete - aby se heslo neposílalo drátem , ale hash se spočítala už v prohlížeči není samozřejmě žádný problém a v javascriptu stránky se to běžně dělá.
Ne, těm co si ho včas nezměnili poslali stejné heslo. Šlo o něco jiného, o přístup k účtu. Tedy jeden faktor je znalost hesla, další je kód opsaný ze SMS. Člověk co má přístup k SMS komponentě má podle jejich vyjádření obojí najednou. A bude to na klientovi, že si obojí dostatečně neochránil, protože "v našem systému se to stát nemohlo".
Já jsem myslel, že poštou i SMS rozesílali stejné heslo. Ono je to tak, že to mají jako dva faktory, takže poštou přišlo něco jiného, než SMS? To ale nemusí znamenat, že komponenta pro rozesílání SMS umí přečíst obě hesla.
Mimochodem, ovládnutí bankovní komponenty pro rozesílání SMS fakt nepovažuji za významné riziko. To jste někde dost hluboko v bankovním systému, pokud byste dokázal ovládnout tuhle komponentu, má banka nejspíš daleko větší problém.
Stále ale platí staré známé pravidlo: „Vůbec nevadí, když hesla ukládáte třeba v otevřeném tvaru. Vadí, když se z něčeho pozná, že to tak děláte.“
A ono je to ještě horší, než to na první pohled vypadalo. Myslel jsem, že vygenerovali heslo, poslali SMS a uložili jej do DB, pak jej vytáhli tou komponentou na tištěný dopis (sic).
V tom tweetu ale píší, že "Šifrování je obousměrné a dešifrování se používá pouze na těchto tiskových výstupech, jako je pošta nebo SMS.". Tedy komponenta, která má být použita na druhý faktor - rozesílání SMS - si umí nějakým způsobem přečíst heslo z databáze. Pokud tomu tak je, pak případnému útočníkovi stačí ovládnout pouze ji, a získá hesla, přesměruje autorizační kódy v SMS na jiné číslo a vybere účet.
Pevně doufám, že alespoň ten dešifrovací klíč byl vygenerován a uložen na nějakém tokenu, který po rozeslání SMS odpojili a uložili do trezoru a v systému je jen veřejný klíč, kterým se jednosměrně hesla šifrují. Ale začínám pochybovat, ten amatérismus z toho čiší. Jak tohle mohlo projít bezpečnostním auditem?
Nemohla by k tomu LUPA nebo měšec napsat článek?
Ono je tam ještě ten dopis - jak jsem psal, dá se do něj nahlédnout bez poškození obálky, proti tomu textu není žádný text na složené straně jen prázdný papír, takže při prosvícení obyčejnou baterkou si to heslo přečtete (i přes ten potisk, co tomu má zabraňovat). A ani nepoškodíte dopis. Pak už stačí jen sebrat vlastníkovi účtu mobil.
Druhou věcí je, že jejich nové bankovnictví je nějaká beta-verze, půlka věcí není dosud implementována a objeví se hláška o přesměrování do starého IB. Takže představa, že v databázi jsou plaintextová hesla nebo hesla kde je klíč v konfiguračním souboru skriptu IB mi vůbec nepřipadá nepravděpodobná, bohužel.
Vyjádření Monety na Twitteru je tady: https://twitter.com/MONETAMoney/status/1348977667949932546 I když přihlédnu k tomu, že je to vyjádření marketingového oddělení a je trochu zmatené, plyne z toho, že mají hesla uložená tak, že dokážou získat otevřený tvar hesla.
Co znamená „mají“? Pokud to znamená, že mají k heslu v otevřeném tvaru přístup – jak jsem psal výše, s tím oni nic neudělají. Pokud myslíte, že ho mají uložené – pokud by to bylo např. jak jsem psal výše, je riziko úniku menší než když jsou uložené jen (dobře udělané) hashe hesel. Větší riziko je, ž to heslo unikne někde mimo, před tím, než se zahashuje/zašifruje. U toho šifrování je samozřejmě otázka, zda půjde použít i pro ověření hesla – ne všechny šifrovací protokoly fungují tak, že když dvakrát zašifrujete to samé stejným klíčem, dostanete stejný šifrovaný výstup.
Jako člověk, který nějakou dobu dělal v bankovním IT (byť ne v ČSOB) dost pochybuji, že by skladovali heslo tak, aby se dal získat původní tvar. Pro banku není žádný důvod to tak dělat a jen to přináší bezpečnostní riziko. Nějaký no-name e-shop ano, ale v bankovnictví je bezpečnost přeci jen na vyšší úrovni.
To, že mají přístup k heslům v otevřeném tvaru, je průšvih – ale ne průšvih Monety, ale celého IT oboru, že nebyl schopen do teď vyvinout a nasadit standard, který by umožnil s heslem v otevřeném tvaru pracovat pouze v bezpečné části prohlížeče, kterou by opouštěl jen údaj, který by byl použitelný pro ověření uživatele, ale jeho znalost by nestačila pro přihlášení uživatele. Dneska se zdá, že tuhle fázi nakonec úplně přeskočíme a místo toho budeme používat nějaké autentizační tokeny.
Přístup k heslům mají totiž už v prohlížeči, pak se to heslo přenese na server a mají k němu přístup tam – a tam už nemáte vůbec žádnou kontrolu, co se s tím heslem děje.
Vy jste ale asi myslel to, že mají heslo v otevřeném tvaru (nebo jeho ekvivalent) uložené. To také nemusí být problém (když už to heslo tedy mají, protože jim ho prohlížeč poslal), heslo se dá uložit velmi bezpečně tak, že riziko jeho úniku je minimální. Stačí ho třeba zašifrovat veřejným klíčem a privátní klíč mít uložený někde off-line, jenom pro speciální případ, kdy bude potřeba to uložené heslo rozšifrovat.
Skutečný problém je to, že to uživatelské heslo takhle rozesílají. Za prvé to není ten výjimečný případ, kdy by bylo potřeba bezpečně uložené heslo získat. Za druhé proces úvodního nastavení hesla by měl být stejný, jako reset hesla. Tj. vytvoří se dočasné heslo, které platí souběžně s hlavním heslem (na začátku to hlavní heslo může být nastavené náhodně nebo tam může být speciální příznak „heslo nenastaveno“). Takže tady se vkrádá otázka, zda není řešen špatně i reset hesla a zda to nebude způsob, jak na účet udělat DoS.
Ano, tak mi to paní na klientské lince vysvětlila. Chyba nastala u toho, kdo si změnil heslo brzy poté, co dostal heslo SMS. Ten kdo čekal déle dostal původní vygenerované heslo.
A máte pravdu, papír jsem našel ve schránce. Nejednalo se o psaní do vlastních rukou.
14. 1. 2021, 11:21 editováno autorem komentáře
A když už se o tom píše, tak by ještě chtělo zdůraznit, že to plaintext heslo přišlo jako běžný dopis (jak předchůdce píše - tedy ne doporučený) s odtrhávacími boky, který ani nebyl v obálce a šlo do něj bez odtržení nahlédnout. Mě ale přišel s původním heslem ze SMS, asi nejprve generovali hesla a posílali SMS a pak tiskli dopisy, ale Vy jste se trefil do okamžiku mezi, mě den trvalo, než jsem se k tomu dostal. Nicméně to, že mají přístup k negenerovaným plaintext heslům je obrovský průšvih.
A to jsem byl tak rád, že jsem se s Monetou před asi 5 lety úspěšně rozloučil.
Psal jsem to včera jednomu redaktorovi Lupy a napíšu to ještě sem. Měl jsem spořící účet u Wustenrotu a od nového roku ho vzala pod sebe Moneta. 4.1. mi přišlo SMS vygenerované heslo a že si mám v IB nastavit nové heslo. To jsem udělal a všechno se tvářilo ok. Nicméně včera mi přišlo poštou jako obyčejný dopis mnou zadané heslo v plaintextu a že si mám nastavit další heslo. To jsem samozřejmě ihned udělal a volal jsem na klientskou linku, jak je možné, že mi heslo přišlo poštou. Prý se jedná o chybu a že mělo být v dopisu to heslo vygenerované bankou a ne to moje nastavené. Prý se ale nemám bát, že se jedná automatizovaný tisk bez přístupu lidí.
Musím říct, že mě podobné chování banky zarazilo. Asi bych nečekal, že má hesla někde jako plaintext a pokud z nějakého důvodu ano (nějaká povinnost), tak bych nečekal, že se něco podobného stane.