Portál AbcLinuxu, 23. říjen 2017 04:49

Nástroje: Začni sledovat (1) ?Zašle upozornění na váš email při vložení nového komentáře.

Vložit další komentář
11.12.2014 01:21 priman
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
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.
11.12.2014 07:01 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
11.12.2014 03:13 Martix. | skóre: 15
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
Pavle, děkuji za informativní článek a za příspěvek.
11.12.2014 07:11 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
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ů.
11.12.2014 09:08 oldjay
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
'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.
11.12.2014 10:38 Petr
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 11.12.2014 10:46 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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ý.
11.12.2014 13:20 oldjay
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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?
11.12.2014 14:51 Pali
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 11.12.2014 15:11 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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í.
11.12.2014 15:33 Pali
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 11.12.2014 16:17 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
11.12.2014 21:21 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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".
12.12.2014 09:07 oldjay
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 12.12.2014 09:38 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
12.12.2014 14:35 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
12.12.2014 15:07 Nikita Bretschneider
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 12.12.2014 15:24 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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í.
11.12.2014 10:44 Honza
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
ž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 avatar 11.12.2014 10:49 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Jak se pak řeší důvěra tomu javascriptovému kódu?
11.12.2014 21:25 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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а avatar 13.12.2014 00:59 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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).
13.12.2014 09:04 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
13.12.2014 11:17 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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...
13.12.2014 14:20 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
13.12.2014 18:50 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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а avatar 13.12.2014 16:01 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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í.
13.12.2014 11:16 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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а avatar 13.12.2014 16:49 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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í :-)
11.12.2014 08:13 gsnak | skóre: 20 | blog: gsnak
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
Na co jabbim potrebuje hesla v plaintexte?
DOGE: DE7q1kxqvoFek7UGWBWBt47QWJTRBqVNLL
11.12.2014 10:51 Petr
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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ší.
11.12.2014 21:47 Filip Jirsák
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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а avatar 13.12.2014 00:54 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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а avatar 13.12.2014 00:57 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Aby mohl podporovat bezpečnou autentizaci klientů, kteří neumí TLS. Třeba různé javové mobily.
15.12.2014 10:52 gsnak | skóre: 20 | blog: gsnak
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
To im na to nestaci ROT13?
DOGE: DE7q1kxqvoFek7UGWBWBt47QWJTRBqVNLL
Heron avatar 11.12.2014 08:38 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
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 :-)
Heron
Bedňa avatar 11.12.2014 09:35 Bedňa | skóre: 33 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
+1
Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
Tadeáš Pelech avatar 11.12.2014 09:38 Tadeáš Pelech | skóre: 34 | Malenice
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Zrušil jsem průhlednost. Díky za upozornění.
11.12.2014 10:57 Pali
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
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 avatar 11.12.2014 11:35 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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.
11.12.2014 14:20 Pali
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 11.12.2014 15:18 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 11.12.2014 13:43 Conscript89 | Brno
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
to jako ze usernamy by byly taky zahashovany? To jako ze si budu povidat s nejakym: $6$8nTNx1O7/Wr3m5SF$d1zHjql7m3ZwVl2761MF8t74jY1.PBYO4P4PE/RjGqhhmdcf8iFnebUhQXqXS9VJ040kD6YJFS8gMY9jIxj5I/ ?
I can only show you the door. You're the one that has to walk through it.
11.12.2014 14:16 Pali
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 12.12.2014 19:03 Conscript89 | Brno
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Jo tak, tak to me taky napadlo kdyz jsem si to cetl :-)
I can only show you the door. You're the one that has to walk through it.
Bedňa avatar 11.12.2014 21:00 Bedňa | skóre: 33 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
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.
Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
pavlix avatar 11.12.2014 21:20 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 avatar 11.12.2014 21:49 Bedňa | skóre: 33 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
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 :)
Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
pavlix avatar 11.12.2014 23:40 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
ž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 avatar 12.12.2014 06:34 Bedňa | skóre: 33 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Tu sa nejak nerozumieme, poznať soľ a vedieť heslo, sú dosť odlišné veci.
Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
pavlix avatar 12.12.2014 08:21 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
O znalosti soli vůbec nebyla řeč, to je veřejný údaj.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.