Portál AbcLinuxu, 19. března 2024 06:25

Plaintextová hesla, uživatelé a SCRAM

10. 12. 2014 | Pavel Šimerda
Články - Plaintextová hesla, uživatelé a SCRAM  

Diskuze pod další z mnoha zpráviček na téma plaintextových hesel mě přesvědčila, že by toto téma zasloužilo trochu potrápit. Především bych chtěl poukázat na zkušenosti, které ne všichni čtenáři mají kde získat, a rovněž nějaká technická fakta, která je jinak potřeba těžce dolovat z RFC.

Nejsem žádný expert na kryptografii, a tak ode mě můžete očekávat spíše pragmatický pohled vystavěný na obecně uznávaných předpokladech než nějaký hloubkový rozbor. Na druhou stranu snad dokážu podat informace pro laika stravitelnějším způsobem.

Obsah

Hesla a klíče

link

Možností autentizace je celá řada. Běžně se na Internetu vyskytují především hesla a asymetrická kryptografie.

Asymetrická kryptografie v oblasti autentizace nabízí bezbolestné ověření vlastnictví soukromého klíče pomocí klíče veřejného. Ke vzájemné autentizaci je tedy potřeba, aby měl uživatel uložený svůj soukromý klíč a veřejný klíč serveru nebo certifikační autority.

To je takřka ideální situace, přesto autentizace heslem neztrácí na oblibě, a to především díky tomu, že nevyžaduje na straně klienta žádné úložiště a v nejjednodušší podobě ani implementaci. Za dvě nejzásadnější výhody hesel tedy považuju schopnost člověka zadat heslo zpaměti a existenci základních mechanismů, které nevyžadují žádný protokol.

Pokud si uživatel heslo nepamatuje a používá ho pouze z disku, první výhodu zcela ztrácí a oproti asymetrické kryptografii tak zůstává pouze snadné použití bez podpory ze strany softwaru. Z toho důvodu se budu v článku zabývat především hesly, která si uživatel skutečně pamatuje a vkládá je pomocí klávesnice.

Ukládání hesel

link

Hlavním tématem diskuze bývá otázka, jak ukládat hesla na straně poskytovatele služby, tedy především zda je ukládat v čitelné, šifrované či hashované podobě.

Čitelná podoba spočívá v tom, že má služba k dispozici přímo uživatelovo heslo. To má několik zcela zásadních výhod, mezi které patří nezávislost na autentizační metodě a jednoduchá obnova hesla, o které bude ještě řeč. Seznam uživatelských hesel je potřeba chránit před vyzrazením, jinak jsou nenávratně kompromitována.

Pro účely článku jsou šifrovaná hesla ekvivalentem čitelných. Liší se jen v tom, že namísto celého seznamu hesel je potřeba chránit před vyzrazením samotný šifrovací klíč.

Hashovaná podoba má naopak zásadní výhodu v tom, že vyzrazení databáze nevede na vyzrazení uživatelova hesla. Cenou za to je nutnost znát množinu autentizačních metod v době ukládání hashovaného hesla do databáze a patřičné přizpůsobení formátu uložení.

Uživatelé

link

Uživatel představuje v IT vždy největší slabinu celého systému. Ale je třeba nezapomínat, že ty systémy existují právě proto, aby je někdo používal, a především, že uživatel jejich provozovatele a tvůrce často živí. Platící zákazník si to často velmi dobře uvědomuje a jedná podle toho. Navíc často není ochotný za bezpečnost připlácet.

Počet hesel k zapamatování

Uživatelé si pamatují jen málo hesel, a tedy při větším počtu služeb potřebují hesla buď uložená, která slouží spíše jako klíče, nebo hesla sdílená mezi více službami, což zpravidla obnáší vyzrazení hesla třetí straně.

Obnova hesel a klíčů

Uživatelé zapamatovaná hesla zapomínají a uložená hesla a klíče z různých důvodů ztrácejí. Podle mých zkušeností se zákazníky mezi nejčastější důvody ztráty uložených klíčů patří pořízení nového počítače, telefonu nebo tabletu, dále jeho reinstalace a neodborný zásah do konfigurace.

O uložených heslech mluví uživatel typicky v minulém čase. Z jeho pohledu byla ta hesla potřeba ke konfiguraci aplikace a teď už neexistují. Z pohledu celého systému jsou to spíše klíče než hesla a budu je tak i nazývat.

Největší problém klíčů (i těch tvořených hesly) je ten, že jsou typicky na uživatele a nikoliv na aplikaci či alespoň stroj. Jsou tedy sdílené mezi uživatelovými aplikacemi na různých strojích a to může způsobit problémy při konfiguraci nového zařízení.

A snad nejhorší ze všeho jsou v tomto ohledu hesla sdílená mezi více uživateli a navíc ještě používaná pro nějakou automatizaci. Typicky se jedná o různá hesla k webhostingům síťovým složkám s výstupy tiskáren, webkamer a podobná zvěrstva, která ale bohužel tam venku existují. Věřím, že mnozí z vás vědí přesně, o čem mluvím.

Máme k dispozici nový stroj a seznam hesel

Moje zkušenost je taková, že uživatelé s naprostou samozřejmostí očekávají, že správci stačí přístup k novému zařízení, aby ho dokázali nakonfigurovat. K tomu správce bohužel potřebuje mít někde (zpravidla na autentizačním serveru) uložené klíče všech uživatelů v čitelné podobě.

Jedná se pochopitelně o nejkritizovanější způsob ukládání hesel, ale zároveň jediný, který s běžným serverovým software naplňuje vcelku pochopitelné představy uživatelů.

Máme k dispozici nový stroj a jeden starý stroj

Často se to řeší tak, že se heslo vydoluje z některého jiného stroje. Osobně to považuju za řešení nouzové a nesystémové, vzhledem k tomu, že funguje jen ve specifických podmínkách a vyžaduje dolování hesel z aplikací, čemuž by se správce určitě rád vyhnul.

Máme k dispozici všechny stroje

Nejčistším řešením je výměna klíče za nový. To funguje i v situaci, kdy se starší zařízení někam ztratilo a klíč mohl být kompromitován. Je k tomu ale potřeba mít k dispozici všechny stroje a především klíč opravdu ve všech aplikacích vyměnit za nový.

Sofistikovanější řešení

Ideální by samozřejmě bylo klíče vůbec nesdílet a párovat službu s každou aplikací nebo strojem zvlášť, případně i za použití asymetrické kryptografie. To vše samozřejmě záleží na schopnostech autentizační služby a případně i jednotlivých služeb na ni navázaných.

Vlastnosti autentizačních mechanismů na bázi hesla

link

Podíváme se na běžné autentizační mechanismy na bází výzvy a odpovědi. Je důležité, aby autentizace byla oboustranná a tedy došlo jak k ověření klienta ze strany serveru, tak i serveru ze strany klienta.

Internetové protokoly často umožňují využití SASL, případně GSSAPI, což jsou frameworky, které odstiňují aplikaci od konkrétních autentizačních mechanismů. Často se kombinují s TLS kvůli zabezpečení komunikačního kanálu a autentizaci asymetrickou kryptografií a s různými mechanismy založenými na heslech, podepsaných ticketech a dalších vzdálených ověřovacích metodách.

Heslo po síti

Nejjednodušší autentizační mechanismy jsou založené na prostém odeslání uživatelského jména a hesla na server. Server pak tuto dvojici přijme nebo odmítne.

Mezi výhody těchto mechanismů patří nezávislost na způsobu uložení hesla na serveru, nízké nároky na implementaci na straně klienta i serveru (například webový formulář).

Jeho hlavními slabinami je naopak právě posílání hesla po síti a absence autentizace serveru. Z těchto dvou důvodů se používá v kombinaci s TLS, které má zajistit jak autentizaci serveru, tak utajení hesla posílaného po síti.

V rámci SASL toto poskytuje mechanismus PLAIN . Ještě existuje SASL mechanismus LOGIN, který se liší tím, že zadává zvlášť uživatele a zvlášť heslo.

HMAC jednorázové hodnoty pomocí hesla

Jak jsem psal v úvodu, z pohledu kryptografie jsem pouhým uživatelem. Kryptografická hashovací funkce je pro mě nevratná operace s jedním vstupem (zprávou), jejímž výstupem je hash předem dané délky. HMAC je pro mě odvozenina z takové hashovací funkce, která pracuje se dvěma vstupy (klíčem a zprávou) která rovněž vrací (stejně dlouhý) hash.

Jestliže server pošle zprávu, která obsahuje náhodná data, aby byla zpráva pokaždé jiná a nepředvídatelná a klient mu vrátí její HMAC za použití hesla jako klíče, může server při znalosti hesla HMAC reprodukovat a ověřit. Zhruba takto funguje SASL mechanismus CRAM-MD5 a stejnou vlastnost poskytuje i SCRAM.

Služba nemusí vůbec znát původní heslo

Autentizační server by neměl mít k dispozici uživatelské heslo, a to především pro to, aby přístup do jeho databáze neznamenal i přístup do jiných služeb, kde si uživatel zvolil stejné heslo. Toho lze docílit tak, že se k přihlášení nepoužívá heslo, ale hash vytvořený z kombinace hesla a hodnoty, která je na různých serverech různá. To například pomocí hodnoty realm nabízí historický SASL mechanismus DIGEST-MD5, který měl být vylepšením CRAM-MD5, a pomocí soli SCRAM.

Osobně to považuju za zásadní vlastnost, kterou je ještě dobré doplnit o registraci zmíněného hashe namísto skutečného hesla.

Služba nemusí znát dostatek údajů pro přihlášení

Údaje, které SCRAM potřebuje držet uložené na serveru, nestačí k přihlášení na ten samý server nebo na server s kopií autentizačních údajů.

Klient nepotřebuje k opětovnému přihlášení původní heslo

SCRAM umožňuje ukládat u klienta namísto původního hesla hash, který je specifický nejen pro daný server, ale dokonce i pro poslední nastavení hesla na serveru.

SCRAM

link

Jak to funguje

Především je SCRAM parametrizovaný jedinou hashovací funkcí, kterou používá jak přímo, tak jako parametrizaci HMAC (hashování s klíčem) a PBKDF2 (hashování s počtem iterací). Při použití SASL tedy člověk nespecifikuje mechanismus SCRAM, ale ideálně SCRAM-SHA-1.

Opakované hashování hesla se solí

Vstupem do SCRAMu je uživatelské heslo v normalizovaném UTF-8. Dále se vygeneruje náhodná sůl, která se k heslu přidá proto, aby stejné heslo při opětovném použití vedlo na zcela odlišný hash a tím i odlišné klíče. Společně s vysokým počtem iterací navíc ztěžuje lámání hesla hrubou silou a slovníkovým útokem.

Sůl a počet iterací jsou veřejné informace, které server nejenom zná, ale i na požádání vydá komukoli, kdo se pokusí o přihlášení na dané uživatelské jméno. Výsledkem opakovaného hashování hesla parametrizovaného solí a počtem iterací je SaltedPassword, se kterým algoritmus dále pracuje.

Klientský a serverový klíč

Pomocí HMAC s klíčem SaltedPassword se ze statických řetězců "Client Key" a "Server Key" vyrobí klíče ClientKey a ServerKey. Klient potřebuje ClientKey aby prokázal svoji identitu a ServerKey, aby ověřil tu serverovou. Server obdobně potřebuje ServerKey, aby prokázal svou identitu, ale jen StoredKey, zahashovanou verzi ClientKey, aby ověřil identitu uživatele. Server si tedy uloží StoredKey a ServerKey pro daného uživatele.

klíče

Autentizace zabezpečeného kanálu

SCRAM nabízí možnost kromě uživatele a serveru volitelně autentizovat zabezpečený kanál (channel binding), ve kterém komunikace probíhá. Takto lze efektivně spojit vlastnosti TLS, SASL a autentizaci pomocí ClientKey a ServerKey do jednoho celku. SASL mechanismus se pak jmenuje SCRAM-SHA-1-PLUS.

Komunikace a ověřování

Při první výměně klient pošle serveru informaci, zda chce použít channel binding formou gs2-header, jméno uživatele a svoji část jednorázové hodnoty cnonce. Server pošle klientovi sůl, počet iterací a doplněnou jednorázovou hodnotou složenou z cnonce a snonce.

Při druhé výměně klient připraví první část zprávy, která obsahuje data pro channel binding (pokud se používá) a zopakuje už známou jednorázovou hodnotu. Spojením obou zpráv předchozí výměny a připravenou částí druhé klientovy zprávy vznikne AuthMessage. Ta obsahuje jednorázové hodnoty cnonce a snonce a tudíž lze použít k ověřování vlastnictví klíčů. Díky tomu, že obsahuje i všechna ostatní vyměňovaná data kromě odvozených ClientProof a ServerSignature, slouží zároveň pro autentizaci celé výměny.

Klient pomocí HMAC s klíčem StoredKey transformuje AuthMessage na ClientSignature, ten XORuje s ClientKey a výsledným ClientProof doplní do zprávy a tu odešle serveru. Server reprodukuje ClientSignature, XORuje s ClientProof a získá ClientKey. Server pomocí hashovací funkce ověří, že ClientKey odpovídá StoredKey a spolu s ClientSignature a ClientProof ho zapomene.

Server pomocí HMAC s klíčem ServerKey transformuje AuthMessage na ServerSignature a ten odešle klientovi, který ho reprodukuje a ověří.

zprávy

Problémy a nedostatky

Vnímám SCRAM jako podstatné zlepšení oproti PLAIN, CRAM-MD5 i DIGEST-MD5. Tudíž v této sekci neočekávejte zásadní vady protokolu, spíše takové obecné postřehy, které SCRAM i do jisté míry přesahují.

Absence standardu pro registraci uživatelů

Zatímco přihlášení uživatelů lze řešit pomocí SASL (případně GSS_API), které poskytuje abstrakci konkrétních autentizačních mechanismů, nevím o ničem podobném v oblasti konfigurace autentizačních dat na serveru. Při použití SCRAM by bylo nanejvýš užitečné poskytovat API pro změnu hesla, které by na server posílalo jen sůl, počet iterací, StoredKey a ServerKey.

Ač jsem nevěděl o obecném standardu, měl jsem za to, že XMPP takovou možnost nabízí. Jenže jsem teď zjistil, že XEP 0077 umí jen přímé posílání jména a hesla a pak už je tu jen draft na správu účtů.

I když ten draft zjevně počítá s mechanismem SCRAM, v příkladech očividně používá pouze StoredKey a ServerKey, ale bez uložení soli a počtu iterací SCRAM nejde používat. Žádná ze specifikací podle všeho ani neuvádí, zda by sůl a počet iterací měl určovat server nebo klient. Já jsem přesvědčen o tom, že by sůl měl (spolu)určovat klient.

Možnost testování existence uživatelských jmen

Specifikace SCRAM explicitně neřeší jak při pokusu o přihlášení zakamuflovat, zda uživatel existuje nebo ne, přitom musí být server schopný pro libovolného uživatele vydat sůl a počet iterací. Sůl asi není problém generovat deterministicky podle uživatelského jména a společné tajné hodnoty. Ale neumím si představit účinnou kamufláž počtu iterací, pokud by byly pro různé existující uživatele různé.

Ovšem udržovat stejný počet iterací pro všechny uživatele jednak znamená, že počet iterací určuje vždy server a jednak to znamená, že server nemůže počet iterací upgradovat najednou a tedy pro upgrade potřebuje získat nové údaje od všech uživatelů. To lze jednoduše řešit jen v případě, že má provozovatel k dispozici původní hesla.

Dopady úniku klíčů ze serveru

Vedle veřejných údajů obsahuje databáze ServerKey, kterým se server autentizuje vůči uživateli, a StoredKey, který se používá pro odvození ClientKey z výměny informací mezi klientem a serverem. Člověk nesmí od autentizace hesly očekávat zázraky a tvrdit, že SCRAM řeší problém s únikem databáze.

SCRAM může jenom zmírnit dopady tím, že neprozrazuje uživatelské heslo a uživatel tedy může jednak pokračovat v jeho používání u jiných služeb a jednak může znovu nastavit stejné heslo i u kompromitované služby.

Navíc data z databáze sama o sobě neumožňují útočníkovi přihlášení, ale potřebuje k tomu ještě navíc odposlechnout autentizaci daného klienta nebo ho přesvědčit k autentizaci vůči útočníkovi. Z obojího plyne, že SCRAM rozhodně není důvod pro nepoužití TLS a jeho možností alespoň omezeně autentizovat server. Rovněž to znamená, že se provozovatel nevyhne ochraně databáze ani odpovídající reakci v případě jejího úniku.

Výchozí konfigurace a downgrade TLS

Všiml jsem si, že mnoho aplikací, které podporují některou z metod, které nevyžadují posílání původního hesla nebo údajů postačujících k přihlášení po síti, nevynucuje ve výchozí konfiguraci TLS pro tyto mechanismy, i když ho vynucuje pro PLAIN mechanismus. Použití bezpečnějšího mechanismu tak může vést na zbytečně permisivní přístup k TLS.

Chápu důvody, proč tomu tak je, ale osobně si myslím, že jak jednou nakonfigurujeme přihlašování například pomocí SCRAM na server, který TLS zjevně podporuje, mělo by být součástí konfigurace účtu i vynucení TLS a nemělo by se odvíjet od výběru autentizačního mechanismu při každém připojování.

Zbytečně ukecaný protokol

Je to jen drobnost. Ale na grafu komunikace mezi klientem a serverem je jasně vidět, že klient v první zprávě posílá jednorázovou hodnotu cnonce a ta se opakuje ve zbylých třech zprávách. Server v odpovědi přidává snonce, které se rovněž ve zbylých dvou zprávách opakuje.

Vzhledem k tomu, že se autentizuje celá AuthMessage, která tak obsahuje třikrát cnonce a dvakrát snonce, mi přijde opakování zbytečné a ani specifikace ho nijak nezdůvodňuje. Mimo psané zdroje jsem se dozvěděl jen to, že je to údajně fajn při debugování, ale ani to mě moc nepřesvědčilo.

Tady už docela vařím z vody, ale nevšiml jsem si, že by channel-binding závisel na snonce, soli nebo počtu iterací, které předává server v první zprávě, takže úplně nevidím důvod, proč není channel-binding součástí první klientovy zprávy. Pak by totiž AuthMessage tvořila přesně celá první výměna. Druhá výměna by pak byla jen o předání ClientProof a ServerSignature. Ale věřím, že mi to v diskuzi někdo vymluví.

Závěrem

link

V rámci možností, které přihlašování uživatelem vybraným zapamatovatelným heslem nabízí, poskytuje autentizační mechanismus SCRAM podstatné zlepšení oproti starším mechanismům a lze ho s výhodou použít jak na serveru, který má k dispozici původní uživatelská hesla, tak na serveru, který ukládá jen StoredKey, ServerKey, sůl a počet iterací.

Stojí za to uvést, že jak původní heslo, tak již zmíněná čtveřice, dávají na výběr mezi mechanismy PLAIN a SCRAM, přičemž původní heslo nabízí další autentizační mechanismy a především provozní výhody v článku popsané. Oproti tomu ukládání obyčejného nebo jiného nekompatibilního hashe SCRAM vyřazuje ze hry.

Rovněž na straně klienta lze ukládat buď původní heslo nebo SaltedKey (případně dvojici ClientKey a ServerKey), pokud uživatel nechce pokaždé zadávat heslo. I tady má původní heslo své výhody, mezi které patří především odolnost vůči vygenerování klíčů s novou solí. To stejné lze samozřejmě podle kontextu interpretovat i jako nevýhodu.

Jestliže uživatel předává provozovateli přímo heslo, je na uvážení provozovatele, zda ho uloží do databáze v původní podobě z důvodů v článku již popsaných, nebo z něj vyrobí klíče pro SCRAM, nebo ho zahashuje jiným způsobem. Nemá valný smysl mu kvůli této volbě dávat peprná jména.

Já osobně bych jako geek u provozovatele nejvíce preferoval API, které umožňuje registrovat klíče pro SCRAM, na druhém místě uložení, které umožní použít SCRAM jako autentizační metodu (mezi jinými i plaintext) a až na úplně posledním místě uložení, které SCRAM neumožňuje (nekompatibilní hash).

Autor se vzdává honoráře ve prospěch spolku OpenAlt.

Odkazy a zdroje

OpenAlt

Další články z této rubriky

V sobotu se uskuteční konference CryptoFest
Pozor na androidové aplikace
Silent Circle představil bezpečný smartphone Blackphone 2
Android je bezpečnější, řada hrozeb však stále přetrvává
Avast varuje před nebezpečnými aplikacemi v Google Play

Diskuse k tomuto článku

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ý.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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í.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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í.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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?
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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: 78 | blog: Jenda | 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: 78 | blog: Jenda | 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: 78 | blog: Jenda | 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: 22 | 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?
Čo Rys, to vrah!
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: 78 | blog: Jenda | 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: 78 | blog: Jenda | 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: 22 | blog: gsnak
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
To im na to nestaci ROT13?
Čo Rys, to vrah!
Heron avatar 11.12.2014 08:38 Heron | skóre: 53 | 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: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
+1
KERNEL ULTRAS video channel >>>
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
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: 34 | 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.
KERNEL ULTRAS video channel >>>
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
Bedňa avatar 11.12.2014 21:49 Bedňa | skóre: 34 | 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 :)
KERNEL ULTRAS video channel >>>
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
Bedňa avatar 12.12.2014 06:34 Bedňa | skóre: 34 | 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.
KERNEL ULTRAS video channel >>>
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.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
4.11.2021 10:11 spam
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
I am hoping that you will continue writing this kind of blog. Thanks for sharing this information Click here
6.11.2021 06:41 spam
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
Awesome! Learned alot thanks so much keep posting more. fencingidahofalls.com
17.11.2021 06:17 spam
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
I really loved it here but are there any recent updates? Thanks affordable dental implants atlanta
17.11.2021 12:11 spam
Rozbalit Rozbalit vše Re: Plaintextová hesla, uživatelé a SCRAM
Odpovědět | Sbalit | Link | Blokovat | Admin
I really loved it here but are there any recent updates? Thanks indoor remodel

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