Vlákno názorů k článku Neuniklo vám heslo nebo privátní klíč? Zjistíte to v databázích úniků od Milan Keršláger - Teda něco tak blbýho, jako říkat někomu dobrovolně...

Dobře, předpokládejme, že mi přišel zlý JavaScript, který odešle celé heslo v otevřeném tvaru. To samé přece dělá prakticky každý web, ke kterému se přihlašuju, který s tím ovšem posílá ještě přihlašovací jméno. V čem přesně je tedy problém, kdyby se Troy Hunt dozvěděl, že někdo někde na webu nejspíš používá heslo „Gf9VrTd6Dm“?

Problém je to například na budování korpusu pro slovníkový útok. Nebo potvrzení/párování s již známými účty/hesly. Obecně je *absolutní* nesmysl psát heslo kamkoliv jinam, než jen tam, kam patří. Minimálně vzniká (mylný) dojem, "že se to může" nebo "že je to k něčemu dobré".

Jenže heslo správně patří jenom do prohlížeče, prohlížeč by nikdy neměl samotné heslo prozradit, vždy jen jeho hash. Realita je ovšem jiná, zdaleka nejběžnější způsob přihlášení je formulář, odkud se heslo posílá v otevřeném tvaru. Jaký je rozdíl v tom, zda heslo zadám na do formuláře Have I Been Pwned nebo třeba tady na Root.cz? Jak můžu vědět, že Root.cz obratem to heslo nepošle třeba právě do Have I Been Pwned? U Troye Hunta si můžu zkontrolovat ten JavaScript, ale na Root.cz si můžu zkontrolovat akorát to, že se heslo opravdu v otevřeném tvaru odesílá na server, a co se s ním děje tam, nad tím už žádnou kontrolu nemám.

Párování hesla s již známým (tím samým) heslem nedává žádný smysl, nedozvím se nic nového. Na potvrzení hesla v takovéhle databázi nevidím nic nebezpečného – pokud to bylo unikátní heslo, nejpozději v okamžiku, kdy ho zadám do HIBP a dozvím se, že uniklo, ho na původním webu změním. Jako korpus pro slovníkový útok je myslím mnohem užitečnější celá databáze HIBP než hesla sbíraná po jednom přes webový formulář.

Pokud jej budeme považovat za útočníka:

* má další položku do slovníku
* má k ní IP adresu a podobné údaje
* může provozovat i jinou službu, kterou budu používat ze stejné IP (stejného profilu prohlížeče / whatever), která k tomu bude znát moji e-mailovou adresu, username a možná i bude něco tušit o mých zájmech.

Vít Šesták: Jak se tím liší od jakéhokoli jiného webu, kde se používá heslo?

Záleží, o jakém scénáři hovoříme.

a. Pokud všude používám unikátní heslo, pak to určitě je riziko. Na druhou stranu je otázkou, jak moc to má zde smysl – snad pokud by někde leaknulo heslo bez e-mailové adresy.
b. Pokud používám všude stejné heslo, pak je tu „jen“ o jednu službu víc, která ho může znát. Je samozřejmě potenciálně další riziko. Že mohou výhody převážit je věc druhá. Víceméně to je asi scénář, který uvažujete.
c. Nová hesla vytvářím unikátní, ale je tu spousta legacy věcí. To je na zvážení.
d. Věřím, že někdo najde ještě nějaký další scénář mezi A a B, kde v případě nedůvěry v HIBP stojí za zvážení, zda a která hesla tam pouštět přes webinterface.

V úvahu bychom přece měli brát všechny scénáře. Každopádně provozovateli webu, ke kterému patří to heslo, to heslo předávám. Drtivé většině provozovatelů webů přitom věřím méně, než Troy Huntovi. Pokud používám na více místech stejné heslo, to heslo už stejně nejspíš dávno uniklo a v HIBP dávno je, takže když by se ho Hunt dozvěděl přes web, nedozví se nic nového. Pokud je moje heslo unikátní a já si ho přes web HIBP ověřím (a ten web by si heslo ukládal), dozví se jenom to heslo a nic jiného (ano, IP adresu, UA atd.). V čem vidíte to riziko?

Pokud někdo nevěří tomu webu, může použít REST API.

Psal jsem, že předpokládám z nějakého důvodu nedůvěru – reagoval jsem na Vaše tvrzení ve stylu „a i kdyby to posílal v plaintextu“, což je scénář, ve kterém mu moc důvěry nepřisuzujete.

> Pokud používám na více místech stejné heslo, to heslo už stejně nejspíš dávno uniklo a v HIBP dávno je, takže když by se ho Hunt dozvěděl přes web,

Dost možná jen hash. A taky je to otázka množství, pravděpodobnosti atd.

> Pokud je moje heslo unikátní a já si ho přes web HIBP ověřím (a ten web by si heslo ukládal), dozví se jenom to heslo a nic jiného (ano, IP adresu, UA atd.). V čem vidíte to riziko?

Je to další heslo do slovníku. Podle dalšího profilování je určitá šance to spojit s konkrétním uživatelem. V nejjjednodušším případě TH (nebo někdo s ním spolčený) bude provozovat další službu, kde se registrujete, zadáte e-mail nebo něco podobného. To se mimochodem může stát i přímo v rámci HIBP, když tam zadáte e-mail a kontrolujete, jestli náhodou k němu není nějaký kopmpromitovaný účet. Separátní služba je ale méně nápadná.

P.S.: Nemělo to znít, že bych TH vyloženě nevěřil. Jen jsem se zamyslel, co by znamenalo, kdyby…

Vít Šesták: K tomu „co by znamenalo, kdyby“ je ale podle mne potřeba dodat, že to se děje dnes a denně na každém webu, kam se přihlašujete heslem.

V HIBP nejsou žádné hashe z úniků, jsou tam hesla v otevřeném tvaru. Taková, která už v otevřeném tvaru unikla, nebo byla tak slabá, že se podařilo hash „rozlousknout“.

Že je to další heslo do slovníku opět platí u každého webu, kam se nějakým heslem přihlašuju.

Pokud někdo nevěří tomu webu, může použít RESTové API. Nebo si může otevřít vývojářskou konzolu a tam si zkontrolovat, že jediný požadavek, který odešel, bylo opravdu prvních pět písmen hashe hesla. Takže i kdyby tam byl kód, který někdy umí poslat heslo v otevřeném tvaru, zjistil bych, že se odeslalo něco víc, a to jedno heslo bych si změnil.

Podstatné je ale to, že HIBP se nedozví víc, než majitel každého webu, kam se přihlašuju heslem – ve skutečnosti se dozví méně, a je snadné ověřit, že se dozví výrazně méně. Takže stejné námitky, které má někdo vůči HIBP, by měl mít vůči každému webu, kam se přihlašuje jménem a heslem.

Sdělovat/posílal komukoliv hesla/hashe z důvodu sebevětší "důvěryhodnosti" je hovadina.

Notabene - autor toho webu píše takové logické nesmysly, že se nám vysmívá (vlastně vám, kteří mu heslo dáte, resp. věříte že mu ho možná nedáte). Např. že máte ověřovat/posílat korporátní hesla - to vážně chcete začít sbírat ve své síti plain hesla, abyste je mohli hashovat a cosi kamsi posílat? To jako FAKT? Jen kvůli tomu že má COOL REST API? A že se dozvíte nějaké MAGICKÉ číslo, kolikrát je prý kdesi uvedeno? K ČEMU JE TO DOBRÉ?

BTW: Jasně, Office 365 od MS má teď takovou cool funkci, že když řeknete heslo, občas vám řekne: Takové heslo jsme už párkrát viděli, zadejte jiné. Možná takhle by se nasbíraná data dala zpeněžit nebo využít. Ale je to stejně pytlovina (entropii hesla můžete odhadnout bez posílání hashe kamsi sám).

Ono jde o jakýsi kousek hashe, ze kterého nelze určit, co přesně to bylo za heslo, protože na tak malém kousku je dost prostoru pro kolize. Je to jen takový kompromis mezi posláním celého hashe (případně hesla v plaintextu) a stahováním celé databáze, která je mimochodem také k dispozici.

K entropii: Ano, dá se různě odhadovat, ale není to až tak triviální problém. Je heslo 47ET6GECDFKWHT47A­YIJQWKWKI====== bezpečné? Teď už ne, protože jsem jej postnul veřejně. Jakou má entropii:

* Před publikováním mělo entropii 128 bitů, protože jsem jej vytvořil pomocí head -c16 /dev/random | base32.
* Pro toho, kdo nevěděl, jak jsem to heslo využil, mělo ještě větší entropii.
* Pro mě a pro ty, kdo četli tento příspěvek, má to heslo nízkou entropii.

Prakticky jsem už četl o případu, kdy bylo cracknuté „podobné“ heslo, protože jej někdo využil z nějaké přednášky. Taky různý 1337 $p3€ch se může někdy na malém vzorku jevit jako heslo s vyšší entropií než má ve skutečnosti. A sebelepší heslo má malou entropii, pokud unikne z jiné služby.

Přijde mi to tedy jako pěkný doplněk dalších mechanismů kontroly síly hesla.

Milan Keršláger: Hovadina je komukoli posílat/sdělovat hesla. Bohužel na téhle hovadině je založený dnešní web. Mně se to nelíbí, kritizuju to, ale to je asi tak všechno, co s tím můžu dělat. Sám sebe chráním alespoň tím, že různým webům posílám unikátní hesla.

Korporátní hesla nemusíte začít sbírat – to, že klient odešle heslo na server, a tam se zkoumá, jestli splňuje bezpečnostní politiky, se s korporátními hesly dělá naprosto běžně. Kdyby se server nedozvěděl heslo v otevřeném tvaru, nemůže kontrolovat, zda neobsahuje uživatelské jméno, jméno, příjmení, známá slova nebo zda není příliš podobné předchozím padesáti heslům.

Jediný bezpečný způsob zacházení s hesly je takový, že heslo zná jen uživatel a software, kterému uživatel může důvěřovat. Jakmile heslo zná víc než jeden subjekt, je to špatně. Bohužel tenhle špatný způsob se dnes používá v drtivé většině případů. V takové situaci je nejnebezpečnější to, když uživatel používá stejné heslo na více místech. A na to se právě zaměřuje Have I Been Pwned, protože pokud heslo bylo součástí nějakého úniku, určitě není použité poprvé. Když použijete dobré heslo, nemůže se vám stát, že už existuje v databázi uniklých hesel – ta pravděpodobnost, že se dobrým heslem trefíte do hesla někoho jiného je příliš nízká. Přičemž tuhle entropii nijak odhadnout nedokážete, jediná možnost je prohledat ten seznam známých hesel.

Pláčete na špatném hrobě. To, že je naprosto běžné, že heslo nezná jen uživatel, ale předává ho provozovateli nějaké služby, není výmysl Troye Hunta. On na ten problém jenom upozorňuje. Kdyby měly servery uložené jen ServerKey a StoredKey, nebo jen veřejné klíče, žádná databáze uniklých hesel by nemohla vzniknout a Have I Been Pwned by neexistovalo.

Tady nejde o entropii ve smyslu náhodnosti, ale jestli to heslo není zkonstruováno na základě běžného slova (slovo heslo, 1234568, jméno/příjmení uživatele atp).

Vstupovat do autentizačního mechanismu v korporátu (abyste mohl cosi kdesi ověřit) je ještě větší pytlovina. Jen vložením nutného kódu snížíte bezpečnost systému řádově (je pak jednodušší ty hesla doopravdy sbírat). Běžný programátor neví, jak ochránit paměť proti leaknutí původního obsahu, běžně se vyrábí logy (ve kterých budou citlivé informace) atd.

Milan Keršláger: Jenže u hesel jde o entropii ve smyslu náhodnosti. Při louskání hesel hrubou silou jde o to vyzkoušet co nejrychleji co nejvíc nejpravděpodob­nějších hesel. Pokud uživatelé vytváří hesla na základě běžných slov, bude útočník zkoušet hesla vytvořená na základě běžných slov. Pokud budou uživatelé vytvářet hesla podle XKCD 936, budou útočníci hesla k vyzkoušení vytvářet stejným způsobem. Obecně jakékoli známé pravidlo pro tvorbu hesel obrovsky snižuje entropii hesla, protože útočník samozřejmě nebude zkoušet všechna možná hesla, ale právě hesla odpovídající těm známým pravidlům. Proto je mimochodem tak nebezpečná povinná změna hesla po určitém čase, protože to u většiny uživatelů znamená, že si vytvoří velmi jednoduché pravidlo po to heslo. Takže jediná entropie, která se u hesel počítá, je skutečná entropie, náhodnost.

Mechanismy změny hesla v korporátu většinou mají možnost nastavit politiku hesel. Součástí toho bývá i možnost ověřit heslo nějakým externím nástrojem. Např. pro Windows Server jsou to Password Filters, pro OpenLDAP je ppolicy overlay atd. Únik hesla z paměti není potřeba řešit, bavíme se tu o autentizačním serveru – pokud může útočník číst jeho RAM, máte úplně jiný problém, než únik jednoho hesla.

Útočník neútočí na nejsilněji chráněné, nýbrž na nejslaběji chráněné místo. To znamená že buďto máte uhodnutelné heslo (Filip123) nebo je to fuk, jaké si dáte (OsBrnoTrava). Entropie je vám úplně k ničemu, protože když budete mít heslo Kr2!V5PHc$xUd%3, musí si ho uživatel někam napsat (nebo to mít v SuperHyperPas­swordManageru) a tím pádem je absolutní entropie k prdu, protože nepřežije útok Mitnicka (tj. sociální inženýrství) nebo si útočník si přečte logy z pohozené zálohy, kde vy budete mít záznam z komunikace s tím super mega API.

Nechápete totiž, že při plané honbě za SuperHeslem vytvoříte desítky dalších slabých míst.

1. Password manager naopak Mittnicka částečně zalepí – heslo se mi u rhybářů samo nevyplní.
2. Špatné logování a špatně zabezpečené logy nevzniknou použitím silného hesla anu použitím password manageru. Naopak, vhodné použití password manageru omezí dopad na ten jeden web, protože najednou není problém mít unikátní a kvalitní hesla.

OsBrnoTrava je ale také uhodnutelné heslo. Zvlášť pokud útočník ví, že heslo tvoříte vložením názvu města do jiného názvu města. Vzhledem k tomu, že hesla dnes znají minimálně dva subjekty, musí těch silných hesel mít uživatel desítky, takže jediná bezpečná možnost je používat správce hesel. Sice je to drbání se levou rukou za pravým uchem, ale dnes je to nejbezpečnější řešení. Sociální inženýrství s tím nijak nesouvisí, pokud z vás někdo dokáže heslo vylákat, je jedno, zda je to slabé heslo nebo zda mu ho dáte ze správce hesel.

Vaše poznámka o logách komunikace s API Have I Been Pwned je už čirá demagogie. Do toho API se posílá prvních pět znaků hexadecimální reprezentace SHA-1 hashe hesla. Víte, k čemu to útočníkovi bude?

Já nepíšu o žádné honbě za SuperHeslem. Zato vy jste nepopsal ani jedno reálné slabé místo. Zmínil jste akorát sociální inženýrství, které s HIBP nijak nesouvisí, a pak jste si vymyslel nesmysl s logy.

Mimochodem, pořád se bojíte úniku hesla z autentizačního serveru. Což je ale přesně ten problém, o kterém jsem psal – že se autentizační server heslo vůbec dozví. A přesně na tohle je také důvod, proč vůbec může existovat HIBP, a proč upozorňuje právě na to, že vaše heslo zná i provozovatel webu nebo jiné služby, a to heslo tudíž může uniknout. Neustále přehlížíte, že HIBP není příčina, ale následek.

> Že je to další heslo do slovníku opět platí u každého webu, kam se nějakým heslem přihlašuju.

To mi přijde trochu mimo to, co jsem říkal. Pokud heslo používám na jediném webu, pak provozovatel si může heslo uložit do slovníku, ale nebude mu až tak moc platné. Může se s ním maximálně přihlásit na tentýž web a dělat něco, co by nejspíš mohl tak jako tak. Když ho ale sdělím TH, mohl by teoreticky se ho snažit někde zneužít, případně dohledat, ke kterému webu patří. Jenže TH bez toho hesla na ten server přístup nejspíš nemá (i když i to se teoreticky může stát), takže to není totéž.

Vít Šesták: Have I Been Pwned není určen pro unikátní hesla. Pokud používám unikátní hesla, je mi databáze uniklých hesel k ničemu, stačí mi vědět, z jaké služby hesla unikla. Have I Been Pwned cílí na uživatele, kteří používají stejná hesla na více místech.

Psal jsem různé scénáře, protože se to různě opatrní lidné mohou snažit použít. Ironicky, opatrnější lidé s unikátními hesly o HIBP budou spíše vědět než neopatrní. (Jak moc bude kdo ochoten tam zadat svoje heslo – to už je druhá věc.) Otázka je, komu je vlastně vyhledání uniklého hesla určeno:

* Lidé s unikátními silnými hesly nic takového nepotřebují. No, ledaže by uniklo plain heslo bez e-mailové adresy, ale kontrolovat tam pravidelně všechna hesla by taky byl porod.
* Lidé opakovaně používající stejné nebo dost slabé heslo se o to až tak nezajímají a hlavně: těžko jim to radit jako systematické řešení.
* Kromě těchto krajních případů tu mohou být různé „něco mezi“, možná tam to najde větší využití.
* Třeba to má trochu jiný účel – demo nebo šlo o hračku autora. Případně to někoho může přesvědčit, jak velký problém je znovupoužití hesla.

Těžko se mi z toho usuzuje, kdo to vlastně bude používat a čím to bude krmit. Váš předpoklad mi tedy nepřijde až tak samozřejmý.

Záleží, o jakém scénáři hovoříme.

a. Pokud všude používám unikátní heslo, pak to určitě je riziko. Na druhou stranu je otázkou, jak moc to má zde smysl – snad pokud by někde leaknulo heslo bez e-mailové adresy.
b. Pokud používám všude stejné heslo, pak je tu „jen“ o jednu službu víc, která ho může znát. Je samozřejmě potenciálně další riziko. Že mohou výhody převážit je věc druhá. Víceméně to je asi scénář, který uvažujete.
c. Nová hesla vytvářím unikátní, ale je tu spousta legacy věcí. To je na zvážení.
d. Věřím, že někdo najde ještě nějaký další scénář někde mezi A a B, kde v případě nedůvěry v HIBP stojí za zvážení, zda a která hesla tam pouštět přes webinterface.

@Milan Keršláger

Proto uvádím tu variantu s API, používám to přes něj. Napsat si třeba v Pythonu vlastní bezpečné ověřovadlo hesel je na pár minut. A proti odeslání prvních 5 znaků SHA1 snad nemáte nic, ne? :)

To API je mimochodem hrozně fajn i pro password managery, je díky tomu možné jednoduše pro uživatele kontrolovat úniky jeho hesel.