Portál AbcLinuxu, 3. května 2025 22:55
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.
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.
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 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.
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ě.
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.
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ů.
Č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.
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ý.
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.
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.
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.
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.
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.
Ú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ů.
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.
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.
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.
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.
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.
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ěří.
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í.
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.
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.
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š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í.
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í.
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.
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 10:46
pavlix | skóre: 54
| blog: 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ý.
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?
11.12.2014 15:11
pavlix | skóre: 54
| blog: pavlix
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í.
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.
11.12.2014 16:17
pavlix | skóre: 54
| blog: pavlix
12.12.2014 09:38
pavlix | skóre: 54
| blog: pavlix
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 15:24
pavlix | skóre: 54
| blog: pavlix
ž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.
11.12.2014 10:49
pavlix | skóre: 54
| blog: pavlix
13.12.2014 00:59
Jendа | skóre: 78
| blog: Jenda
| JO70FB
13.12.2014 16:01
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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 16:49
Jendа | skóre: 78
| blog: Jenda
| JO70FB
místo toho, aby se s webem s nedůvěryhodným certifikátem zacházelo úplně stejně, jako s webem na HTTPVypadá 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í
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.
13.12.2014 00:54
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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ě!
13.12.2014 00:57
Jendа | skóre: 78
| blog: Jenda
| JO70FB
11.12.2014 08:38
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
11.12.2014 09:35
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
11.12.2014 09:38
Tadeáš Pelech | skóre: 34
| Malenice
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?
11.12.2014 11:35
pavlix | skóre: 54
| blog: pavlix
11.12.2014 15:18
pavlix | skóre: 54
| blog: pavlix
Ak kazdemu uzivatelovi povolime si nastavit pocet iteracii ako chce onUž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 XMPPJednak 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.
11.12.2014 13:43
$6$8nTNx1O7/Wr3m5SF$d1zHjql7m3ZwVl2761MF8t74jY1.PBYO4P4PE/RjGqhhmdcf8iFnebUhQXqXS9VJ040kD6YJFS8gMY9jIxj5I/ ?
11.12.2014 21:00
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
11.12.2014 21:20
pavlix | skóre: 54
| blog: 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.
11.12.2014 21:49
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
ž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 :)
11.12.2014 23:40
pavlix | skóre: 54
| blog: pavlix
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.ž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.
12.12.2014 06:34
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.