Plaintextová hesla, uživatelé a SCRAM (diskuse)

[priman]

Nasazení nového hashe nemusí být problém, prostě prvodu autentizaci starou metodou a když už mám heslo z kterého jsem počítal starý hash, tak vypočtu i nový a ten uložím.

[Filip Jirsák]

Ty bezpečnější způsoby autentizace ale fungují tak, že server při autentizaci přímo heslo v otevřeném tvaru od uživatele nezíská. Tj. pro výpočet nového hashe je potřeba si heslo od uživatele explicitně vyžádat jiným způsobem, než při autentizaci. U bezpečných způsobů autentizace se navíc server heslo nedozví nikdy, ani při registraci uživatele.

[Martix.]

Pavle, děkuji za informativní článek a za příspěvek.

[Filip Jirsák]

Uživatel představuje v IT vždy největší slabinu celého systému.

S tím nesouhlasím. Podle mne je to tak, že odborníci navrhnou špatně systém, a v návrhu hodí veškerou zodpovědnost na uživatele. A pak tvrdí, že uživatelé jsou největší slabinou celého systému. Stačí se podívat na dva největší bezpečnostní problémy na webu. Jednak přístup k HTTPS webům - místo toho, aby se s webem s nedůvěryhodným certifikátem zacházelo úplně stejně, jako s webem na HTTP, prohlížeč nutí uživatele, aby odklikl, že je certifikát důvěryhodný - a při té příležitosti mu rovnou jako výchozí volbu nabízí důvěřovat tomu webu trvale. To, že prohlížeč nutí uživatele odsouhlasovat něco, s čím uživatel nesouhlasí, a ještě mu to podstrčí k trvalému souhlasu, přece není chyba uživatele, ale chyba tvůrců prohlížeče. Druhý problém - nejčastější způsob přihlášení je webový formulář a heslo posílané přes síť v otevřeném tvaru při registraci i při každém přihlášení. To, že na zadání hesla není v prohlížeči speciální dialog, že to heslo má zpracovávat výhradně prohlížeč a webu má poskytnout až odvozené údaje (osolený hash) a to jak při přihlašování tak při registraci -ale neděje se tak -, že má být znalostí hesla autentizován každý požadavek (a ne jen ten první a pak už spoléhat na cookie) - to přece nejsou chyby uživatelů, ale chyby tvůrců prohlížečů, serverů a standardů.

[oldjay]

'aby se s webem s nedůvěryhodným certifikátem zacházelo úplně stejně, jako s webem na HTTP'

Co by jste tím chtěl dosáhnout? Jestli je použité HTTPS nebo HTTP nemá žádný vliv na to co daná stránka dělá, jenom na to jestli je komunikace šifrovaná nebo ne. Takže případný podvodný WEB by to nijak neomezilo a WEB, kde mají vlastní certifikát, který třeba i znáte a opravdu mu věříte, by nefungoval.

[Petr]

To jste asi vůbec nepochopil co ten člověk píše a píše to dobře. Doporučuji přečíst znovu. Zato vaší poslední větu jsem vůbec nepobral.

[pavlix]

To jste asi vůbec nepochopil co ten člověk píše a píše to dobře.

Ani já jsem nepochopil sdělení ohledně HTTPS. A i tu část o přihašování heslem bych formuloval jinak.

Zato vaší poslední větu jsem vůbec nepobral.

Já osobně jsem poslední větu pochopil tak, že oldjay nechce degradaci HTTPS v případě, že je schopný sám ověřit certifikát nebo chce alespoň prvnímu certifikátu důvěřovat i nadále a spoléhat se na to, že při té první komunikaci nebyl cinknutý.

[oldjay]

Možná jsem opravdu větu 'aby se s webem s nedůvěryhodným certifikátem zacházelo úplně stejně, jako s webem na HTTP' nepochopil, ale pod tím 'zacházet stejně, jako s webem na HTTP' si neumím představit nic jiného, než že se prohlížeč pokusí stránku znovu načíst pomocí HTTP. Normální server to z bezpečnostích důvodů nebude akceptovat a znovu se pokusí přejt na HTTPS, server s podvrženým webem vám prostě pošle stejné stránky, jako by posílal pomocí HTTPS. Technicky to není žádný problém. Co si pod tím 'zacházet stejně, jako s webem na HTTP' představujete vy?

[Pali]

Ja si myslim, ze som to pochopil a skusim to napisat trochu inac

Majme metody A a B, pomocou ktorych mozeme komunikovat s jedym a tym istym serverom. Dalej bude platit, ze metoda B bude aspon tak bezpecna ako metoda A.

1. Ak sa rozhodneme pre pouzitie metody A, tak by sme mali informovat pouzivatela o bezpecnostnych rizikach pouzitia danej metody minimalne takym sposobom ako pri pouziti metody B.

(Toto by malo byt jasne, lebo A je rovnako alebo menej bezpecne ako B.)

2. Ak sa pri pouziti metody A nerozhodneme informovat uzivatela o bezpecnostnych rizikach a povolime mu spojenie so serverom bez akychkolvek otazok (a dalsich overovani), tak potom pri pouziti metody B nema zmysel sa pytat na bezpecnost tiez.

(Predpokladame, ze B je aspon tak bezpecne ako A. Pri A sme sa rozhodli o neinformovani bezpecnostnych problemov, takze pri rovnako bezpecnej, ci bezpecnejsej metode, to nebude potrebne taktiez.)

3. Komunikacia web browsera s jednym a tym istym serverom po HTTPS je aspon tak bezpecna ako komunikacia bez TLS ciste plaintextom po HTTP.

(Toto je dufam kazdemu zrejme.)

Z tychto tvrdeni (pre A=HTTP, B=HTTPS) mi vyplyva par logickych otazok:

Majme webovy server, ktoru komunikuje po HTTP aj HTTPS. Pre TLS metodu ma u seba vygenerovany self-signed certifikat.

1. Preco pri pristupe cez HTTPS mi kazdy webovy browser nadava ci chcem naozaj sa spojit s nedoveryhodnym serverom a pri HTTP mi spoji ihned bez zbytocnych otazok?

2. Preco pri pristupe cez HTTPS na server, ktoremu vyprsala platnost SSL certifikatu dostavam este vacsie varovanie a u niektorych prehliadacov priamo znemoznenie pouzivania HTTPS? Podotykam ze HTTP spojenie s tym istym serverom stale funguje bez problemov a bez akehokolvek varovania.

3. Preco mi nove verzie prehliadacov zakazuju pristup k webovemu serveru po HTTPS s pouzitim SSLv2 a SSLv3 ale povoluju mi pristup po HTTP?

Alebo tu mam nejaku logicku chybu?

[pavlix]

Otázky skutečně dávají smysl. Nicméně ani odpověď není složitá. HTTPS má nabízet bezpečný přístup, tedy vytváří očekávání, proto se k němu nelze chovat stejně jako k HTTP, které ta očekávání nevytváří. Jiná možnost by byla k tomu od začátku přistupovat tak, že by se ona očekávání neodvíjela od HTTPS, ale od určitého stupně bezpečnosti. Ale to by pak neumožňovalo použít https:// ve smyslu připoj se bezpečně k ..., což ovšem je dosavadní status quo.

Nejlepší by bylo zakomponovat TLS do HTTP (toho, co není HTTPS), a celé to postavit odznovu bez speciálního portu, naučit to pořádně používat SASL a GSS_API a dodávat informace o úrovni bezpečnosti separátní cestou, zde mě napadá DNSSEC v kombinaci s lokální konfigurací.

[Pali]

Otázky skutečně dávají smysl. Nicméně ani odpověď není složitá. HTTPS má nabízet bezpečný přístup, tedy vytváří očekávání, proto se k němu nelze chovat stejně jako k HTTP, které ta očekávání nevytváří. Jiná možnost by byla k tomu od začátku přistupovat tak, že by se ona očekávání neodvíjela od HTTPS, ale od určitého stupně bezpečnosti. Ale to by pak neumožňovalo použít https:// ve smyslu připoj se bezpečně k ..., což ovšem je dosavadní status quo.

Problem je stale v tom, ze HTTP a HTTPS su medzi sebou previazane a jedna stranka z HTTPS moze odkazovat sa na inu po HTTP (a opacne). Teda tu ocakavanie bezpecnostneho pristupu straca svoj zmysel a nadalej si budem stat za svojimi tvrdeniami. Nehovoriac este o moznom downgrade utoku. Okrem toto si myslim, ze cele overovanie SSL certifikatu je v kazdej aplikacii naimplementovane zle. Tu si autori (takmer) vsetkych aplikacii vylucne myslia ze iba ich "doverihodne" autority su doverihodne a to pre vsetkych. Nehovoriac o tom, ze kazda aplikacia si overuje certifikat po svojom a ak som uz jednej aplikacii povedal, ze plne doverujem certifikatu C, tak ine to samozrejme ignoruju... Podla mna by to mal riesit system (alebo nejaka jeho kniznica) a tam by som mohol jasne povedat ze pre server S sa moze pouzit jedine certifikat C (a je jedno ci je self-signed alebo vyprsal...).

Nejlepší by bylo zakomponovat TLS do HTTP (toho, co není HTTPS), a celé to postavit odznovu bez speciálního portu, naučit to pořádně používat SASL a GSS_API a dodávat informace o úrovni bezpečnosti separátní cestou, zde mě napadá DNSSEC v kombinaci s lokální konfigurací.

Ano. Spolahlive riesenie je asi jedine spravit protokol HTTP nanovo a poriadne.

[pavlix]

O system-wide správě certifikátů se hodně mluví, ale zatím asi opravdu jenom mluví. Mnoho dalších věcí jsou záležitosti implementace a tady bohužel trochu vládnou majoritní implementace, protože na nich záleží, jak se budou chovat webové aplikace. Já sám vůbec nejsem příznivcem samostatných portů pro TLS, osobně si myslím, že by TLS mělo být z hlediska uživatele implementační detail schovaný za pokročilou konfiguraci, kterou zajišťuje administrátor (počítám s tím, že geek je typicky sám sobě administrátorem). Uživatel by měl podle mě být od bezpečnosti maximálně odstíněný a měla by se projevit jen tím, že se někam nedostne a kontaktuje technickou podporu.

V případě self-supportu jako například při využívání různých free služeb by měl být uživatel prvně obeznámen nějakým standardním způsobem s úrovní bezpečnosti, a pak teprve s konkrétními technologiemi, ne že bude mít na jedné straně insecure verzi a na druhé straně secure verzi s výjimkami. Já bych třeba moc rád chodil na weby, které chtějí komunikovat pouze přes TLS a umožnil jim komunikovat přes TLS přestože jsem je neměl možnost autentizovat. A ano, rád bych aby se spojení graficky prezentovalo jako nezabezpečené (detailně jako šifrované a neautentizované). Nevidím důvod, proč nepoužívat TLS jen proto, že momentálně nemám, jak protistranu autentizovat.

Takže pokud nové HTTP/TLS, tak bych primárně začal u toho, aby se na HTTP používalo TLS, kdykoli to server i klient podporují a já to v klientovi zapnu, aniž by mě to muselo takto obtěžovat v případech, kdy TLS nemůžu ověřit.

[Filip Jirsák]

Přistupovat k HTTPS s nedůvěryhodným certifikátem stejně jako k HTTP znamená, že se prohlížeč bude z pohledu uživatele chovat, jako by přistupoval k webu přes HTTP. Tj. nebude otravovat hloupými hláškami "opravdu?, "jste jist?", "a stejně vás tam nepustim", ale prostě web zobrazí stejně, jako by ho stáhl přes HTTP. Akorát někde v adresním řádku může nabídnout ikonu "k tomuto webu by bylo možné přistupovat bezpečně, ale předtím musíte ověřit certifikát". Pokud uživatel certifikát ověří, samozřejmě se nejedná o nedůvěryhodný certifikát a neplatí pro něj výše uvedený postup. Je logické, že když si uživatel HTTPS explicitně vyžádá (napíše ho do adresního řádku, otevře z oblíbených), má být důrazně varován, pokud se prohlížeč přepne do nedůvěryhodného režimu. Když ale sem na fórum někdo plácne odkaz s HTTPS "podívejte se na mojí wiki, tam jsem to perfektně popsal", nevidím jediný důvod, proč by mne prohlížeč měl donutit nainstalovat si certifikát toho webu a utvrzovat v mne v návyku, že pokud chci na webu něco vidět, musím tak dlouho klikat na OK, dokud to prohlížeč nevzdá a nepustí mne tam. Mimochodem, tohle byl v počátcích Firefoxu důvod, proč se uživatelé Firefoxu chovali na webu mnohem zodpovědněji, než uživatelé MSIE. Protože MSIE se uživatelů ptal na každou blbost, takže si je brzy vytrénoval, že ta upozorňovací okna jsou taková soutěž, a vyhrává ten, kdo je umí nejrychleji odklikat. Firefox se tenkrát ptal jen na důležité věci, takže když už se na něco zeptal, bral to uživatel vážně. Dnes je v některých případech Firefox horší, než tehdejší MSIE - a Chrome je na tom jen o kousek líp. Očekávání uživatelů se neodvíjejí od HTTPS, ale od toho, zda je adresní řádek prohlížeče zelený, se žlutým vykřičníkem nebo červeně přeškrtnutý. U HTTP 2.0 se střídavě uvažuje o tom, že bude existovat jenom šifrovaná varianta. Nevím ale, zda je to teď zrovna ve fázi "pal" nebo "nepal".

[oldjay]

Tak jsem to asi pochopil, tak jak jste to myslel. To by ovšem znamenalo, že když vás někdo přesměruje na podvodný web předstírající, že je vaše oblíbená služba, tak jediné varování bude ta ikonka "k tomuto webu by bylo možné přistupovat bezpečně, ale předtím musíte ověřit certifikát". Plus to, že veškerá komuniakce bude nešifrovaná včetně autentizačních údajů. To mě moc dobré nepřipadá.

[pavlix]

Taky vnímám Jirsákův nápad jako přílišné zjednodušení (jako ostatně většinou).

Kdyby byly ty bezpečnostní úrovně standardizované, tak by mohly mít také standardizovaná jména a odkazy by mohly být ve formátu http+tls+<security-level>://, tedy by se daly reimplementovat odkazy typu http://, s tím rozdílem, že by bezpečnost šla různě vrstvit jako třeba http+tls+selfsigned:// (jen ilustrativní) a uživatel by pak nemusel být konfrontován nabídkou typu potvrď to nebo z toho nic nebude v případech, kdy se od něj potvrzení neočekává. Oproti tomu by běžný http:// stále umožňoval vynucení bezpečnostní politiky například pomocí (samozřejmě podepsaných) dat v DNS nebo využití bezpečnostních prvků na základě možností.

Problém je v tom, že zrovna HTTP se konfiguruje nejhůře, ostatní protokoly mají většinou mnohem omezenější možnosti využití a autentizace se u nich často předpokládá a není tedy problém při prvním přihlášení (registraci) nechat uložit nejen heslo, ale i konfiguraci bezpečnostních prvků, která už se nadále vynucuje. Implementace v HTTP by skutečně znamenala opustit klasická formulářová hesla a používat mechanismus, který na straně klienta uloží jak (volitelně) heslo, tak i další detaily pro komunikaci s daným webem.

[Filip Jirsák]

Pokud k nějaké oblíbené službě chci přistupovat bezpečně, měl bych ji mít v oblíbených a označenou takovým způsobem, že k ní chci vždy přistupovat jen bezpečným kanálem. Pak by prohlížeč při pokusu navštívit takovou stránku nešifrovaným spojením samozřejmě uživatele varoval. Navíc když mne někdo na takový web odkáže, stejně si musím zkontrolovat, kam jsem se to dostal. A do třetice, ten oblíbený web by měl mít zapnuté HSTS, takže mne nikdo na HTTP variantu nepřesměruje. Autentizační údaje řešila druhá část mého komentáře, podle mne by autentizační údaje v otevřeném tvaru nikdy neměly opustit bezpečnostní modul prohlížeče.

[Nikita Bretschneider]

Jde o to, že z pohledu BFU je http totéž co https, čili to u nich žádná očekávání nevyvolává. Aplikujte, přečtěte si komentáře ještě jednou a pochopíte.

Ono by se uživatelům asi líbilo, kdyby se "zabezpečení" indikovalo nějakou ikonkou v případě, že se povedlo ověřit identitu serveru a jinak se ssl neprojevovalo vůbec, jenže náhlá změna v self-signed by se pak taky nikde neprojevila, ač všichni víme, že to bude nejspíš mitm, že. A to by byl celkem průs..švih. A řešení "semaforkem" ve stylu "trusted", "learned", "no-ssl" taky nikam nevede, protože minimálně změnu pro "learned" bych zase musela potvrzovat, ikdyž možná ne při prvním připojení, čili bych tím nic nevyřešila a jen věci zkomplikovala. Čili tak jak to je to funguje správně, jen rozdíl mezi http a https by pro BFU měl být větší než jedno písmenko. Aby vyvolal ono očekávání.

[pavlix]

Obávám se, že je tento pohled je jednak příliš zkratkovitý, abych mo mohl aplikovat, a jednak toho moc neříká o komentáři, ke kterému má být odpovědí.

[Honza]

že má být znalostí hesla autentizován každý požadavek (a ne jen ten první a pak už spoléhat na cookie)

V čem vidíte problém se spoléháním se na cookie?

SASL po počáteční autentizaci také spoléhá na to, že TCP spojení patří stále tomu samému uživateli - po výše popsané výměně se už předpokládá že data patří uživateli který se autentizoval. (Přestože unést TCP spojení možné je, podobně jako lze ukrást cookie.)

Řeší se to samozřejmě tak, že místo samotné autentizace (auth) se v rámci SASL komunikace vymění také klíče, kterými je následá komunikace podepisována (auth-int - integrita) nebo rovnou celá šifrována (auth-conf - důvěrnost). Pokud chceme zajistit to samé na webu, je nejjednodušší řešení použít HTTPS, které zajistí jak integritu, tak důvěrnost spojení.

Nemusíme přitom vůbec spoléhat na důvěryhodnout serveru deklarovanou jeho certifikátem, ale použít místo toho výše popsané metody výměny hesla za pomoci javascriptu a HTTPS nechat hlídat jen to, že komunikace probíhá stále mezi těmi stejnými stranami, mezi kterými proběhla autentizace.

[pavlix]

Jak se pak řeší důvěra tomu javascriptovému kódu?

[Filip Jirsák]

Problém cookies je v tom, že si je může každý po cestě přečíst. A když s nimi zacházíte neopatrně, tak nejen po cestě. Takže se pak různě pokouší řešit to, aby nebylo možné unést sezení. Což je absurdní, protože celý problém únosu sezení vzniká jenom praštěnou implementací autentizace uživatele.

[Jendа]

Dobře napsáno.

Zkoušel jste se zamyslet nad tím, proč to webové prohlížeče neimplementují? To, co jste popsal, mi přijde docela jednoduché na implementaci. Nenapadá mě žádné vysvětlení (kromě konspiračních jako že NSA to tak vyhovuje).

[petr_p]

Důvod je stejný, jako proč weby odešly od HTTP autentizace: protože klienti neimplementovali odhlašování. Momentálně je ale touha udělat věci ještě javascriptovější. Říká se tomu U2F a jde to tak daleko, že někteří by rádi viděli JS API pro přístup k čipovým kartám.

[Filip Jirsák]

Vzhledem k tomu, že se Oracle s Googlem společnými silami snaží dostat z prohlížečů Javu, což je dnes jediný použitelný způsob, jak v prohlížeči kryptografii s čipovými kartami dělat, dávalo by to JS API smysl...

[petr_p]

Problém je, že mezi klávesnicí a čipovou kartou je kód, který pochází z webového serveru. Tohle je cesta do pekla.

[Filip Jirsák]

Samozřejmě že záleží na tom, co ten kód může dělat. Pokud jedinou jeho možností je dát prohlížeči pokyn "toto zobraz uživateli a umožni mu to podepsat - pokud tak učiní, vrať mi podpis", tak ten kód nemůže napáchat žádnou škodu. Navíc současné řešení s Javou také používá kód, který pochází z webového serveru - takže implementace ve webovém prohlížeči by byla bezpečnější.

[Jendа]

Důvod je stejný, jako proč weby odešly od HTTP autentizace: protože klienti neimplementovali odhlašování.

Asi jsme se špatně pochopili:

Jenda: Proč prohlížeče neimplementují odhlašování?

petr_p: Protože prohlížeče neimplementovaly odhlašování.

[Filip Jirsák]

Ano, je to jednoduché na implementaci. Důvodů je podle mne několik. Za prvé nestačí implementovat to v prohlížečích, je potřeba podpora i na straně serverů. Dále by bylo potřeba do procesu registrace zakomponovat GUI prohlížeče a nějak spojit obě části registrace (v GUI prohlížeče bych zadal login a heslo, na webové stránce další údaje vyžadované při registraci - adresu, e-mail, telefon, číslo bot...). Je to řešitelné a je to jen otázka zvyku - ale nové řešení by bylo přínosné teprve tehdy, až by si uživatelé zvykli, že heslo v prohlížeči nesmějí zadávat jinam, než do speciálního okna prohlížeče. Do té doby by to ale bylo něco netypického, tím pádem otravného - takže se k tomu nelze dostat evolucí, je potřeba se nějak dostat přes ten odpor "je to nové a prospěch z toho budu mít až později". Navíc tedy to pravidlo "nikdy nezadávej heslo jinam" by mělo výjimky, jako třeba právě Jabim - tam, kde by bylo potřeba heslo získat pro jiný způsob autentizace. Ale dá se očekávat, že (pokud by se v HTTP používala rozumná autentizační metoda), postupně ji převezmou i další systémy.

Rozhodně se ale dá začít alespoň něco zlepšovat. Např. zkulturnit GUI pro autentizaci metodou HTTP Digest, dotáhnout to tak, aby to bez problémů fungovalo mezi aktuálními prohlížeči a často používanými servery, standardizovat, že realm je řetězec v UTF-8, který se uživateli zobrazuje v přihlašovacím dialogu. A především do prohlížečů implementovat odhlašování z HTTP autentizace. Pak se dá pokračovat standardizací SCRAM v HTTP, a registraci z prohlížeče lze implementovat až nakonec.

Ale především si musí tvůrci prohlížečů uvědomit, že bezpečnost prohlížeče se nezvyšuje tím, že se přidá další alibistický dotaz na uživatele.

[Jendа]

místo toho, aby se s webem s nedůvěryhodným certifikátem zacházelo úplně stejně, jako s webem na HTTP

Vypadá to, že si někdo přečetl váš komentář a rozhodl se, že u webů přes čisté HTTP taky bude zobrazovat varování

[gsnak]

Na co jabbim potrebuje hesla v plaintexte?

[Petr]

Nevrtejte nám tady do toho! :) Právě vám bylo vysvětleno, že vůbec nejhorší je nekompatibilní hash a že heslo v plaintextu na straně provozovatele vlastně není taková hrůza. Sice si to nikdo z těch uživatelů, jejichž heslo, které mají k dalším 50 službám, uniklo z jejich db na internet nemyslí, ale budete tomu muset věřit :) Mně teda stačí už to, že kdejaký zaměstnanec dané služby může teoreticky vidět hesla lidí a může je zkoušet jinde, prodat atd atd stačí.. Jistě, uživatel by měl dávat heslo jedinečné a pak znalost hesla kýmkoliv na straně služby zase tolik nevadí, ale víme jak to funguje, BFU to nedělá. Dokonce znám hodně lidí, kteří si myslí, že když je někde login na email / heslo, tak to musí být heslo k tomu emailu, jinak by to nefungovalo. Že si mohou vymyslet jiné ani netuší.

[Filip Jirsák]

Mně teda stačí už to, že kdejaký zaměstnanec dané služby může teoreticky vidět hesla lidí a může je zkoušet jinde, prodat atd atd stačí.

To je ale dané tím, že službě to heslo v otevřeném tvaru posíláte. Ukládání hesla v otevřeném tvaru do databáze je jen jedna z mnoha možností, co se s ním u té služby může dít.

[Jendа]

Mně teda stačí už to, že kdejaký zaměstnanec dané služby může teoreticky vidět hesla lidí a může je zkoušet jinde, prodat atd atd stačí..

Ale já ta hesla vidím v tcpdumpu pořád, i když už je Jabbim ukládá hashovaně!

[Jendа]

Aby mohl podporovat bezpečnou autentizaci klientů, kteří neumí TLS. Třeba různé javové mobily.

[gsnak]

To im na to nestaci ROT13?

[Heron]

Nešlo by u těch obrázků změnit pozadí z průhledného na nějakou dostatečně kontrastní barvu se zbytekem diagramu?

Na černém stylu jsou vidět pouze barevné čtverečky, což je sice samo o sobě výtvarně hezké, ale neposkytuje to onu informační hodnotu, kterou do toho autor vložil

[Bedňa]

+1

[Tadeáš Pelech]

Zrušil jsem průhlednost. Díky za upozornění.

[Pali]

Ale neumím si představit účinnou kamufláž počtu iterací, pokud by byly pro různé existující uživatele různé.

Co takto pouzit opat hashovaciu funkciu na uzivatelske meno a nejaky salt?

[pavlix]

Neměl jsem nouzi o nápady na čem, by se řešení stavělo, jako spíše o konkrétní metodu, která by zajistila, že útočník u každého jednotlivého jména bude stejně dobře věřit že je to existující uživatel jako že je to neexistující uživatel. Dokud je množina různých počtů iterací existujících uživatelů jednoprvková, je to jednoduché. Pokud se změní na dvouprvkovou, tak je uživatel s novým počtem iterací prozrazen, pokud není zakryt odpovídajícím počtem neexistujících uživatelů s tímto počtem iterací. Jenže změna počtu iterací převážně u neexistujících uživatelů o systému prozrazuje další informace. Řešení něčeho takového si podle mě nejde takhle jednoduše vycucat z prstu.

[Pali]

Ak kazdemu uzivatelovi povolime si nastavit pocet iteracii ako chce on (bude to samozrejme vyzadovat nejake dalsie rozsirenie XMPP) a pre neexistujuich uzivatelov bude server deterministicky oznamovat pocet iteracii (= pre jedneho neexistujuceho uzivatela oznami vzdy rovnake cislo), tak utocnik z poctu iteracii (ktore dostane od serveru) nebude mat ako zistit, ci uzivatel existuje alebo nie.

[pavlix]

Ak kazdemu uzivatelovi povolime si nastavit pocet iteracii ako chce on

Uživatelé typicky nebudou vybírat počet iterací, uživatelé budou zadávat jenom heslo a o existenci dalších hodnot v lepším případě nebudou mít tušení.

bude to samozrejme vyzadovat nejake dalsie rozsirenie XMPP

Jednak se to netýká jen XMPP, jednak, jak už jsem psal v článku, tak jsem nenašel, že by XMPP specifikovalo vůbec nějakou metodu SCRAM registrace.

a pre neexistujuich uzivatelov bude server deterministicky oznamovat pocet iteracii (= pre jedneho neexistujuceho uzivatela oznami vzdy rovnake cislo), tak utocnik z poctu iteracii (ktore dostane od serveru) nebude mat ako zistit, ci uzivatel existuje alebo nie.

Leda ve snu, ale důvody už jsem popsal a výběr na straně klienta situaci jen zhoršuje.

[Conscript89]

to jako ze usernamy by byly taky zahashovany? To jako ze si budu povidat s nejakym: $6$8nTNx1O7/Wr3m5SF$d1zHjql7m3ZwVl2761MF8t74jY1.PBYO4P4PE/RjGqhhmdcf8iFnebUhQXqXS9VJ040kD6YJFS8gMY9jIxj5I/ ?

[Pali]

Nie, myslel som ze z (neexistujuceho) uzivatelskeho mena by sa deterministicky odvodil pocet iteracii. A to tak aby neslo spatne z poctu iteracii odvodit meno a aby nebol viditelny rozdiel medzi existujucim uzivatelskym menom (pre ktory existuje zaznam s poctom iteracii) a neexistujucim uzivatelom.

[Conscript89]

Jo tak, tak to me taky napadlo kdyz jsem si to cetl

[Bedňa]

Moc pekné.

Nedá sa mi vrátiť k iteráciam čo sme preberali. Už som si spomenul na časť z článku kde bolo naznačené, čo sa ti vybaví keď zbadáš čísla 2, 4, 8, 16, 32, 64, 128, že sú to mocniny čísla dva. Teda jako ja som šifrovacia láma a dokonca som študoval aj kód asi najlepšieho, aktívne vyvíjaného šifrovacieho kódu pre JavaScript, asmCrypto a moc som to nepobral, ale vidím tam rotujúce matrice, pri ktorých sa práve iteráciami môže zdvojiť, strojiť ... hash, alebo nastane iná predvídateľná chyba. Ja osobne používam soľ vytvorenú z dát od užívateľa a k tomu pridám serverovú napr. 128bitovú to už nemá nikto v slovníkoch a musel by to lámať hrubou silou. Žiadny rekurzívny efekt pre zníženie algoritmu tam nehrozí.

OT: Štyri mesiace som pracoval na šifrovaní cez prehliadač, prešiel som desiatky projektov a môžem definitívne prehlásiť, že aj tie naznámejšie knižnice asmCrypto schová do vrecka, teda pokiaľ sa bavíme o dátach v stovkách až tisícoch megabajtov, tak až s tým niekto bojoval práve našiel riešenie.

[pavlix]

Nedá sa mi vrátiť k iteráciam čo sme preberali.

Už jsem se bál, že nepřijdeš. Jsem rád, protože tady je alespoň nějaká šance, že se tvého komentáře chytí někdo, kdo nemusí do svých článků psát dva disclaimery, že o kryptografii nic neví. Tak uvidíme.

Ja osobne používam soľ vytvorenú z dát od užívateľa a k tomu pridám serverovú napr. 128bitovú to už nemá nikto v slovníkoch a musel by to lámať hrubou silou.

Sůl slovníkový útok neznemožňuje, jen zpomaluje. Rozdíl je v tom, zda máš slovník hesel, nebo předgenerovaný slovník hashů, popřípadě si mo můžeš předgenerovat jednou než začneš louskat databázi, aspoň jak já to chápu. Klasickým brute force se pokud vím myslí procházení možností úplně bez slovníku.

Ja osobne používam soľ vytvorenú z dát od užívateľa a k tomu pridám serverovú napr. 128bitovú to už nemá nikto v slovníkoch a musel by to lámať hrubou silou.

Kombinovat sůl od klienta a serveru při konfiguraci autentizačních údajů by bylo fajn. Taková challenge-response registrace. Akorát jsem trochu nervózní z možnosti, že by server mohl klienta v důsledku donutit používat už dříve známou sůl.

OT: Štyri mesiace som pracoval na šifrovaní cez prehliadač, prešiel som desiatky projektov a môžem definitívne prehlásiť, že aj tie naznámejšie knižnice asmCrypto schová do vrecka, teda pokiaľ sa bavíme o dátach v stovkách až tisícoch megabajtov, tak až s tým niekto bojoval práve našiel riešenie.

Tak to se těším na článek nebo přednášku.

[Bedňa]

Tak že si vieme stiahnuť slovník na hashe a slovníky na hashe s najpoužívanejšími heslami sa asi nemusíme baviť, preto tá zložitejšia soľ.

že by server mohl klienta v důsledku donutit používat už dříve známou sůl.

Áno, ale z môjho pohľadu to nijak neznižuje obranu voči slovníkom.

Tak to se těším na článek nebo přednášku.

Pochybujem že by to niekoho zaujímalo okrem jedného človeka, nemyslím teba, ale všeobecne známeho chlapíka čo na tom robí biznis :)

[pavlix]

že by server mohl klienta v důsledku donutit používat už dříve známou sůl.

Áno, ale z môjho pohľadu to nijak neznižuje obranu voči slovníkom.

V takové chvíli už je především jakákoli ochrana zbytečná, vzhledem k tomu, že tím útočník záská přihlašovací údaje na jinou službu se stejným heslem, čemuž měl právě SCRAM zabránit. Pokud už si dám tu práci, aby server neznal heslo, tak mu snad nebudu dávat mechanismus pro výrobu klíčů k jiným službám.

[Bedňa]

Tu sa nejak nerozumieme, poznať soľ a vedieť heslo, sú dosť odlišné veci.

[pavlix]

O znalosti soli vůbec nebyla řeč, to je veřejný údaj.

[spam]

I am hoping that you will continue writing this kind of blog. Thanks for sharing this information Click here

[spam]

Awesome! Learned alot thanks so much keep posting more. fencingidahofalls.com

[spam]

I really loved it here but are there any recent updates? Thanks affordable dental implants atlanta

[spam]

I really loved it here but are there any recent updates? Thanks indoor remodel