Rubrika: Technologie & AI Autor: V Délka čtení: ~27 min Prameny a další četba: 22 položek Témata: únik hesel, Have I Been Pwned, Pwned Passwords, k-anonymita, credential stuffing, GDPR, ÚOOÚ SEO / pracovní titulek: Jak zjistit, zda uniklo vaše heslo nebo e-mail?
Jak zjistit, zda uniklo vaše heslo nebo e-mail? Otázka zní jednoduše jen do chvíle, než si všimneme, že neporovnáváme jednu věc. E-mail v úniku není heslo v úniku. Heslo v korpusu není „vaše“ heslo. Nález v indexu není cizí přihlášení. A prázdný výsledek není důkaz, že k úniku nedošlo. Článek proto nehledá tlačítko bezpečí. Hledá, kterou vrstvu právě měříte a co z ní ještě neplyne.
1. Notifikace Have I Been Pwned není zpráva, že se někdo právě přihlásil
Ráno přijde e-mail: vaše adresa se objevila v novém záznamu Have I Been Pwned. Čtenář otevře stránku, vidí název služby a kategorie dat. V hlavě se to spojí do jedné věty: někdo má moje heslo a právě se mi dostává do schránky. Kolega z IT řekne, ať se nepanikaří a nejdřív se oddělí adresa od hesla. Právník připomene správci lhůtu 72 hodin podle GDPR. Bankéř mluví o credential stuffingu na jiných webech. Správce služby říká, že uživatelům poslal oznámení.
Na první pohled jde o jeden únik. Ve skutečnosti každý popisuje jiný problém. Čtenář čte nález jako živou relaci. IT řeší výskyt tajemství v korpusu. Právník mluví o povinnosti správce vůči úřadu a subjektům údajů. Bankéř myslí opakované heslo na jiné službě. Správce řeší, zda jeho incident vytváří riziko, které musí oznámit.
Proto mohou být všichni částečně správně a společné rozhodnutí přesto špatné. Jedna chyba vede k panice a zbytečnému resetu do slabšího hesla. Druhá vede ke klidu z prázdného výsledku a k dalšímu používání stejného hesla na deseti webech. HIBP není alarm o právě probíhajícím přihlášení. Je to index známých souborů a incidentů, s vlastními limity a datem.
2. Jedna adresa má nejméně šest vrstev
Slovo „uniklo“ se používá pro dump z kompromitované služby, paste na webu, stealer log z počítače oběti, stuffingový seznam i notifikaci správce. Tato slova nejsou zaměnitelná. Když je zaměníme, špatně reagujeme: měníme heslo tam, kde problémem bylo opakování jinde, nebo píšeme stížnost tam, kde chybí identifikovatelný správce v režimu GDPR.
Šest vrstev jedné adresy:
- Surovina: dump z kompromitované služby, stealer log, stuffingový seznam nebo paste. Každý typ vzniká jinak.
- Index: Have I Been Pwned, Sentinel, správce hesel nebo interní kontrola služby. Každý index má jiný korpus a jinou latenci.
- Nález: adresa, heslo, nebo pár adresa plus heslo u útočníka. HIBP občanovi adresu a heslo nespojuje.
- Zneužití: credential stuffing na jiných webech, phishing na reset, prodej logu nebo přihlášení do účtu.
- Povinnost správce: článek 33 a 34 GDPR, dokumentace incidentu, ohlášení ÚOOÚ a případné oznámení subjektům [13].
- Reakce držitele účtu: unikátní heslo, změna tam, kde se opakovalo, odolnější druhý faktor, kontrola relací a řešení škody.
Index není surovina. Nález není zneužití. Povinnost správce není povinnost občana. A reakce uživatele má být úměrná vrstvě, kterou právě vidí. Člověk nepotřebuje vědět, jak se stuffing provádí. Potřebuje vědět, proč opakované heslo dává starému dumpu nový život.
Tato vrstevnatost mění i jazyk. „Mám e-mail v úniku“ je správný začátek, ne konec diagnózy. Je třeba doplnit, zda šlo o službu, kterou člověk používal, jaké kategorie dat jsou uvedené, zda tam bylo heslo, zda bylo heslo unikátní a zda se někde opakovalo. Teprve potom přichází reakce. Bez této mezivěty se bezpečnost mění v rituál: kliknout, vyděsit se, změnit něco, uklidnit se.
E-mail v úniku není totéž co heslo v úniku. A heslo v úniku ještě není cizí přihlášení.
— Jiný Kontext
3. Nejlepší reakce je ta, jejíž omyl vás nezamkne venku a neotevře stuffing
Dobrá bezpečnostní reakce není ta nejhlasitější. Je to reakce, která sníží riziko a nevytvoří nové. Zbytečný reset jedné služby je levná chyba. Reset do krátkého, opakovaného nebo zapomenutelného hesla je horší. Zadání plného hesla do náhodného „ověřovače“ je už samotný únik. A klid z prázdného indexu může být drahý, pokud se stejné heslo používá jinde.
| Druh selhání | Jak vypadá | Jak testovat | Co omezí škodu |
|---|---|---|---|
| Falešný poplach | Adresa je v HIBP, ale heslo bylo unikátní a MFA drží | Číst službu a kategorie dat, ne jen slovo breach | Změna jen tam, kde byl důvod |
| Falešný klid | HIBP nic neukáže, ale heslo je stejné na více webech | K-anonymní kontrola hesla a správce hesel | Unikátní hesla a notifikace |
| Únik do checkeru | Plné heslo odejde do neznámé služby | Použít jen oficiální Pwned Passwords nebo správce hesel | Nikdy neposílat tajemství e-mailem |
| Záměna stuffing a phishing | Historický nález se řeší, ale člověk zadá údaj podvodníkovi | Oddělit starý dump od živého kanálu | Ověření mimo odkaz a odolnější MFA |
| Špatný adresát | Stížnost míří na ÚOOÚ bez vztahu ke správci | Ptát se, kdo je správce a co měl udělat | Čl. 34, čl. 77 a doklady |
Tato tabulka nemá nahradit zdravý strach. Má jej zpřesnit. Bezpečí účtu nevzniká z jedné webové odpovědi. Vzniká z toho, že tajemství není opakované, druhý faktor není jen snadno opsatelný kód v každé situaci, relace se dají zkontrolovat a člověk ví, kdy už nejde o index, ale o podezření na cizí vstup.
Reakce má mít i pořadí. Nejdřív se zajišťuje přístup k účtu, aby se člověk sám nezamkl venku. Potom se mění heslo tam, kde je důvod. Potom se kontroluje, zda stejné heslo nežilo jinde. Nakonec se zapínají notifikace a druhý faktor, který dává smysl pro danou službu. Když se pořadí obrátí, může člověk ztratit obnovovací kanál, přepsat heslo variantou starého nebo vyřešit historický index a nechat otevřenou živou relaci.
4. E-mail v indexu není heslo v indexu
Have I Been Pwned odděluje vyhledání e-mailové adresy v breach od služby Pwned Passwords. U adresy člověk vidí služby a kategorie dat. Nevidí své heslo vedle adresy. HIBP ve FAQ vysvětluje, že hesla nejsou ukládána způsobem, který by je spojoval s adresami pro veřejné vyhledávání [4]. To je bezpečnostní hranice služby, ne kosmetický detail.
K 1. září 2026 uváděla domovská stránka HIBP 17 796 310 183 indexovaných účtů a 1 033 pwned webů nebo incidentů [1]. Tato čísla jsou živé čítače globální služby. Měří účty nebo adresy v indexu, ne unikátní lidi a ne počet obětí v Česku. Jedna osoba může mít více adres. Jedna adresa může být ve více incidentech. Jeden incident může obsahovat jen e-mail a jiný širší sadu kategorií.
Praktická otázka proto nezní „jsem hacknutý?“. Zní: která služba je uvedena, jaké kategorie dat se u ní uvádějí a zda jsem tam používal heslo, které se opakovalo i jinde. Pokud ano, problém neleží jen u staré služby. Leží ve všech místech, kde stejné tajemství otevřelo stejné dveře.
Kategorie dat jsou důležité i proto, že e-mail je často jen identifikátor pro další útoky. Sám o sobě nemusí otevřít účet. Může však pomoct přesvědčivému phishingu, resetové komunikaci nebo párování s jiným únikem. Z toho neplyne, že každá nalezená adresa znamená škodu. Plyne z toho, že adresa v indexu má jinou váhu než heslo v korpusu a jinou váhu než potvrzená cizí relace.
5. Heslo v Pwned Passwords není „vaše“ heslo
Pwned Passwords měří výskyt tajemství v korpusu známých uniklých hesel. Když se heslo najde, neznamená to, že služba ví, že patřilo právě vám. Znamená to, že stejné tajemství se někde v korpusu objevilo. Pokud jste ho kdy používali, má být považováno za veřejné a nevhodné pro další použití.
Stránka Pwned Passwords uváděla k 1. září 2026 provoz přes 18 miliard požadavků za měsíc, cache hit přes 99,9 % a 335 edge locations [2]. To měří provoz služby a integrace správců hesel, registračních formulářů a ručních kontrol. Neměří počet nových úniků ani počet lidí, jejichž heslo bylo zneužito.
Rozdíl mezi „heslo se našlo“ a „někdo se přihlásil“ je zásadní. První je stav tajemství. Druhé je událost v konkrétním účtu. Stav tajemství řešíme změnou všude, kde se heslo opakovalo, a novým unikátním heslem. Událost v účtu řešíme relacemi, logy přihlášení, podporou služby a při škodě bankou nebo policií. Jedna vrstva nemá spolknout druhou.
6. Stuffingový seznam není únik jedné firmy
Credential stuffing je zneužití již známých dvojic přihlašovacích údajů proti jiným službám. OWASP jej odlišuje od hrubé síly i od password spraying [17]. Podstatou není hádat jedno heslo dokola. Podstatou je opakování starých tajemství tam, kde lidé používali stejné heslo vícekrát.
Troy Hunt popsal korpus Synthient Credential Stuffing Threat Data přidaný do HIBP v listopadu 2025. Uvádí 1 957 476 021 unikátních e-mailových adres, zhruba 1,3 miliardy unikátních hesel a 625 milionů hesel, která HIBP předtím neviděl [6]. Záznam HIBP k tomuto korpusu jej popisuje jako stuffingová data, ne jako únik jedné firmy [7].
Ve stejném textu se uvádí 32 milionů domén a 394 milionů adres na doméně gmail.com, tedy přibližně 20 % adres v tomto korpusu [6]. To není únik Gmailu. Je to známka, že velká freemailová doména se objevuje v recyklovaných přihlašovacích párech. Kdo toto číslo čte jako kompromitaci Googlu, zaměnil jmenovatel.
Z toho neplyne návod k útoku. Plyne z toho obranné pravidlo: staré heslo se nesmí opakovat. Pokud se opakovalo, mění se všude, kde bylo použité, ne jen u služby uvedené v notifikaci. Nové heslo nemá být varianta starého. Správce hesel není pohodlí navíc. Je to způsob, jak zastavit recyklaci tajemství.
Stuffing také vysvětluje, proč staré úniky nezmizí ze života jen proto, že stará služba zanikla. Hodnota dvojice adresa a heslo neleží pouze v původním webu. Leží v možnosti, že člověk stejné tajemství použil jinde. Obrana proto nespočívá v hledání původního viníka za každou cenu. Spočívá v tom, že se opakování odstraní a budoucí přihlášení se neopírá o stejné tajemství.
7. Stealer log není totéž co únik provozovatele
Stealer log vzniká jinak než únik databáze provozovatele. Malware na zařízení oběti může sebrat uložené přihlašovací údaje, cookies nebo jiné údaje z prostředí uživatele. Kompromitace firmy znamená selhání u správce služby. Oba výsledky mohou skončit ve stejném trhu s údaji. Příčina, odpovědnost a reakce jsou však jiné.
Verizon v doplňku DBIR 2025 uvádí, že kompromitované údaje byly počátečním vektorem u 22 % breach z 9 891 incidentů se známým vektorem, mimo kategorie Error a Misuse [16]. Stejný materiál u 14 742 infostealer zařízení uvádí medián 49 % unikátních hesel napříč službami, což znamená, že v této populaci obětí malware bylo v mediánu 51 % opakovaných hesel [16]. Jde o dataset Verizon, ne o českou populaci a ne o všechny uživatele.
Verizon také uvádí, že v SSO logách tvořil credential stuffing medián 19 % autentizačních pokusů u 2 301 organizací [16]. To je měření v organizacích a logách, ne počet přihlášení do vašeho účtu. Přesto ukazuje mechanismus: opakované heslo mění starý únik v průběžný tlak na jiné služby.
Stealer log přidává ještě jednu poučku. Někdy nestačí změnit heslo u služby, která se objevila v indexu. Pokud byl problém na zařízení, musí člověk řešit zařízení. Aktualizace, odstranění škodlivého softwaru, kontrola prohlížeče a relací patří k jiné vrstvě než e-mailový nález. Tento text nedává postup pro získávání logů ani jejich použití. Jen odděluje příčinu: selhání u provozovatele není totéž co infikované zařízení uživatele.
8. K-anonymita měří prefix. Ne důvěru v náhodný checker
Pwned Passwords používá k-anonymní model vyhledávání. Klient spočítá SHA-1 otisk hesla a odešle jen prvních 5 hex znaků. Možných prefixů je 1 048 576, protože 16^5 [5]. Server vrátí odpovídající suffixy a počty výskytů. Plné heslo neopouští zařízení jako čitelný text ani jako celý hash.
HIBP API v3 popisuje range search a zachování principu částečného dotazu [3]. Server tedy nevidí celé heslo. Vidí jen prefix otisku. To neznamená, že máte posílat heslo kamkoli, kde se objeví slovo „checker“. Znamená to, že existuje konkrétní bezpečnější mechanismus, který používají oficiální Pwned Passwords a někteří správci hesel.
NIST SP 800-63B doporučuje ověřovat zvolená hesla proti seznamům známých kompromitovaných hodnot [8]. To je doporučení pro správnou správu hesel. Není to univerzální česká zákonná povinnost všech správců používat právě HIBP. A není to omluva pro sběr plných hesel do náhodného webového formuláře.
K-anonymita zde plní skromnou roli. Neříká, že heslo je silné. Neříká, že účet je bezpečný. Říká, zda se dané tajemství objevilo v známém korpusu. Slabé, ale zatím neuniklé heslo může být pořád špatná volba. Silné a unikátní heslo, které se jednou dostalo do veřejného korpusu, se má přestat používat. Kontrola úniku je jedna brzda, ne celý bezpečnostní systém.
Jak testovat heslo bez odeslání tajemství
Použijte oficiální Pwned Passwords nebo správce hesel, který kontrolu provádí k-anonymitou. Nezadávejte plné heslo do neznámé stránky, neposílejte jej e-mailem a netestujte cizí kombinace. Účelem je zjistit, zda vaše tajemství už není tajemstvím. Ne ověřit, zda se s cizí kombinací dá někam vstoupit.
9. Sentinel není totéž co Have I Been Pwned
CZ.NIC popsal Sentinel View jako nástroj, který umožňuje zkontrolovat hesla proti datům ze sítě Turris Sentinel a používá princip částečného hashe [18]. Další text CZ.NIC spojuje pravidla pro tvorbu hesla s Turris Sentinel Report [19]. Je to blízká obranná myšlenka: neodesílat celé tajemství, ale porovnat jej s korpusem známých výskytů.
Sentinel však není HIBP. Má jiný zdroj dat, jiný rozsah a jiné poslání. Prázdný výsledek v Sentinel nečistí HIBP. Prázdný HIBP nečistí Sentinel. Ani jeden index neumí slíbit, že heslo nikdy neuniklo nebo že nikdo právě nezkouší přihlášení. Absence nálezu je jen absence nálezu v daném korpusu.
To je důvod, proč se indexy nemají používat jako soutěž autorit. Jeden může zachytit heslo ze svého prostředí, druhý globální veřejný dump, třetí kontrolu uvnitř správce hesel. Rozpor mezi nimi nemusí znamenat chybu. Často znamená jiný zdroj, jiné načasování a jiná pravidla zařazení. Obranný závěr je přitom jednoduchý: nalezené heslo se vyřadí, nenalezené heslo se stejně neopakuje.
Pro českého uživatele je hodnota Sentinelu v tom, že nabízí další obranný pohled bez nutnosti pracovat s útočnými seznamy. Pokud služba hlásí výskyt, heslo se nepoužívá. Pokud nehlásí nic, stejně platí unikátnost hesla a druhý faktor. Bezpečnost se nesmí opřít o jednu prázdnou stránku.
10. Ohlášení ÚOOÚ není stížnost subjektu
Článek 33 GDPR říká, že správce ohlásí porušení zabezpečení osobních údajů dozorovému úřadu pokud možno do 72 hodin od okamžiku, kdy se o něm dozvěděl, ledaže je nepravděpodobné, že by porušení mělo za následek riziko pro práva a svobody fyzických osob [13]. ÚOOÚ k tomu má vlastní informace a formulář [11]. Tato lhůta je povinnost správce. Ne občana.
ÚOOÚ ve výroční zprávě za rok 2024 uvádí 336 ohlášení porušení zabezpečení osobních údajů [9]. Ve výroční zprávě za rok 2025 uvádí 392 ohlášení, nejvyšší počet od účinnosti GDPR [10]. Tato čísla měří ohlášení správců českému dozorovému úřadu. Neměří počet uniklých hesel občanů, počet záznamů v HIBP ani velikost konkrétních dumpů.
Stížnost subjektu je jiná věc. ÚOOÚ ve zprávě za rok 2025 uvádí 3 854 podání, z toho 2 514 stížností a 1 340 podnětů, o 68 % více než v roce 2024 [10]. Jde o mix agend GDPR, ne jen úniky hesel. Stížnost podle článku 77 vyžaduje vztah k určitému správci a u ÚOOÚ autentizovaný postup [12] [13]. Nález v HIBP sám o sobě nemusí říkat, komu a co lze vytýkat.
11. Oznámení subjektům není totéž co index HIBP
Článek 34 GDPR upravuje oznámení porušení zabezpečení osobních údajů subjektu údajů, pokud je pravděpodobné, že porušení bude mít za následek vysoké riziko pro práva a svobody fyzických osob [13]. EDPB a původní WP29 k tomu vydaly pokyny WP250 [14]. Toto oznámení přichází od správce. Má říci, co se stalo, jaké údaje se týkají člověka a co má dělat.
HIBP je jiná instituce v uvozovkách i bez uvozovek. Indexuje známé veřejně uniklé soubory a incidenty. Může ukázat adresu v dávném dumpu. Nemusí mít neveřejný incident, který správce oznámil subjektům. A může mít historický záznam, k němuž už správce nekomunikuje. Být v jednom neznamená být v druhém.
Před stížností na ÚOOÚ
Nejdřív položte tři otázky. Kdo je správce? Jaká povinnost měla být porušena? Jaký doklad máte: oznámení, komunikaci, odmítnutí žádosti, nebo jen veřejný index? Článek 78 odst. 2 GDPR pracuje s informováním stěžovatele o pokroku nebo výsledku stížnosti do tří měsíců [13]. Není to lhůta pro výmaz z HIBP.
12. Nález v indexu není důkaz cizího přihlášení. Prázdný výsledek není čistý účet
HIBP FAQ výslovně pracuje s limitem absence důkazu: absence of evidence is not evidence of absence [4]. Když adresa není nalezena, nevíme, že nikdy neunikla. Víme jen, že není v daném indexu. Když nalezena je, nevíme, že se někdo právě přihlásil. Víme, že se objevila v známém souboru nebo incidentu.
Tato dvojí negace je nepříjemná, ale osvobozující. Nedává jistotu, ale brání špatnému závěru. Nález vede ke kontrole, ne k panice. Prázdný výsledek vede k zachování dobrých návyků, ne k opakování hesel. Index není strážce relací. Nevidí aktuální přihlášení do banky, e-mailu nebo sociální sítě.
Pokud existuje podezření na cizí přihlášení, mění se postup. Kontrolují se relace, přihlášená zařízení, pravidla přeposílání pošty, změny hesla, druhý faktor a upozornění služby. Při škodě nebo pokusu o finanční zneužití se řeší banka, provozovatel služby a podle okolností policie. To už není článek o indexu úniků.
Stejně opatrně se má číst i upozornění správce hesel. Když správce hesel oznámí, že heslo je kompromitované, většinou neříká, že někdo otevřel konkrétní účet. Říká, že tajemství odpovídá známé kompromitované hodnotě nebo záznamu v monitorované službě. Je to důvod k výměně tajemství a odstranění reuse. Není to samo o sobě důkaz škody.
Prázdný výsledek není čistý účet. Nález není právě probíhající přihlášení.
— Jiný Kontext
13. MFA snižuje stuffing. Nezastaví phishing, kam heslo sami zadáte
Druhý faktor snižuje dopad opakovaného hesla. Pokud útočník zná starou dvojici e-mail a heslo, druhý faktor může zabránit přihlášení. To je důvod, proč má MFA smysl i po letech starých úniků. Není to však neprůstřelný štít proti každému kanálu.
Phishing, při kterém člověk sám zadá heslo a další kód do podvodného rozhraní, je jiný mechanismus než historický výskyt hesla v korpusu. Tento text nepopisuje techniky obcházení ani útok v reálném čase. Stačí distinkce: HIBP ukazuje historický nález ve známých datech. Phishing je živý kanál, který může obejít dobrý návyk, pokud člověk sleduje špatný odkaz.
Z toho plyne střízlivé pravidlo. Po nálezu se řeší heslo, reuse a MFA. Při podezřelém odkazu se řeší ověření mimo odkaz, přímé zadání adresy služby a kontakt přes známý kanál. Jedna obrana nenahrazuje druhou. Heslo v Pwned Passwords není důkaz phishingu, ale opakované heslo phishingu zlevňuje následky.
14. Citlivý breach není totéž co veřejně vyhledatelný dump
HIBP rozlišuje citlivé breach, které nejsou veřejně vyhledatelné bez ověření vlastnictví schránky. FAQ uvádělo k 1. září 2026 celkem 87 sensitive breaches a 2 retired breaches [4]. To měří klasifikaci uvnitř HIBP, ne citlivost každého skutečného úniku na světě.
Důvod je prostý. Některé incidenty samy prozrazují citlivou informaci už tím, že člověk ve službě byl. Veřejná odpověď „ano, tato adresa je v tomto incidentu“ by mohla způsobit novou újmu. Proto má služba režim, kde je nutné ověřit vlastnictví schránky. Index tedy není jen databáze. Je to i rozhodnutí, co se smí ukázat komu.
Stejné FAQ uvádí plus-aliasing přibližně u 0,03 % adres a vysvětluje, že služba jej plně nerespektuje [4]. Malé číslo může mít velký praktický dopad. Pokud člověk používá adresu typu jmeno+sluzba@domena, nález nebo nenález se může číst špatně. Opět nejde o čistý účet. Jde o technické pravidlo indexu.
15. ENISA šedesát procent phishingu není český podíl uniklých hesel
ENISA v Threat Landscape 2025 uvádí, že phishing tvořil přibližně 60 % pozorovaných případů jako intrusion vector v období od 1. července 2024 do 30. června 2025 [15]. Současně materiál uvádí, že 77 % incidentů v datasetu tvořily DDoS a u průniků se 8,9 % týkalo credential theft [15]. Tato čísla mají různé jmenovatele.
Právě proto se nesmějí sčítat do věty o českých heslech. ENISA měří evropskou hrozbovou krajinu a kategorie incidentů ve svém datasetu. HIBP měří známé breach a adresy v indexu. ÚOOÚ měří ohlášení správců a stížnosti. Verizon měří své incidenty a organizace. Každé číslo může být pravdivé a přesto nepoužitelné pro jiný závěr.
NÚKIB může být užitečný kontext pro české organizace, ale počet incidentů ve zprávě o stavu kybernetické bezpečnosti není proxy pro počet občanů s heslem v HIBP [21]. Europol zase popisuje trh s kompromitovanými účty a kriminalitu kolem nich [22]. To pomáhá porozumět motivaci útočníků. Není to návod a není to individuální audit schránky.
16. Krátký test expozice neslibuje bezpečí
Smyslem testu je zjistit expozici, ne získat cizí údaje a ne zkoušet, zda jde účet prolomit. To musí zůstat viditelné i v drobných krocích. Vlastní e-mail se kontroluje na oficiálním HIBP. Vlastní heslo se kontroluje přes Pwned Passwords nebo správce hesel s k-anonymitou. Cizí kombinace se nezkouší. Stuffingové seznamy se nestahují.
Tři testy nálezu
První test je adresa. Zadejte vlastní e-mail do oficiálního HIBP a čtěte výsledky po službách a kategoriích dat. Nehledejte pocit „jsem hacknutý“. Hledejte, zda šlo o e-mail, telefon, hash hesla, profilové údaje nebo jinou kategorii. Notifikace nastavujte jen pro vlastní schránku.
Druhý test je heslo. Ověřte jej jen k-anonymitou. Pokud se najde v korpusu, považujte jej za veřejné. Změňte ho všude, kde se opakovalo, a nepoužívejte variantu starého hesla. Tato věta není útok. Je to uzavření stuffingové cesty.
Třetí test je účet. Pokud služba ukazuje cizí relace, neznámá zařízení, změny nastavení nebo finanční škodu, HIBP už není hlavní nástroj. Jde o provoz účtu. Změna hesla, odhlášení relací, kontrola druhého faktoru, kontakt se službou a při škodě banka nebo policie mají přednost před dalším hledáním v indexu.
Volitelně lze přidat Sentinel View jako jiný korpus [18]. Pokud přijde oznámení od správce podle článku 34 GDPR, postupujte podle něj. Pokud správce nekomunikuje nebo porušuje práva, řeší se stížnost podle článku 77, ne žádost, aby ÚOOÚ vymazal veřejný index [12] [13].
Výsledek testu si zapište ve třech sloupcích: adresa, heslo, účet. U adresy patří služba a kategorie dat. U hesla patří rozhodnutí, kde se opakovalo a kde se mění. U účtu patří relace, druhý faktor a neznámé změny. Tato tabulka není efektní. Je však lepší než neurčitá věta „uniklo mi to“, protože u každého řádku ukazuje jiný krok.
17. Otázka nezní, zda to uniklo. Zní, kterou vrstvu měříte
Bezpečí účtu není vlastnost indexu. Index může být užitečný a přesto omezený. Ukáže známý výskyt adresy nebo hesla. Neodblokuje účet, nesmaže data z internetu, nepotvrdí živé přihlášení a nedokáže dokázat, že nic neuniklo. To není slabina jedné služby. Je to hranice měřené vrstvy.
Skrytým nákladem slova „únik“ je ztráta rozlišení. Když e-mail v breach, heslo v korpusu, stuffingový seznam, stealer log, oznámení správce a cizí relace spadnou do jedné věty, reakce se stane náhodnou. Jednou přestřelí. Podruhé mine. A někdy otevře přesně tu cestu, kterou měla zavřít.
Rozlišení pomáhá i tehdy, když se nic nenašlo. Prázdný výsledek neosvobozuje od správy hesel. Jen říká, že daný index nemá odpovídající záznam. Unikátní heslo, správce hesel, smysluplný druhý faktor a kontrola relací zůstávají pravidlem i bez červeného varování. Bezpečnost nemá čekat na nález.
Stejně tak nález nemá určovat jedinou emoci. Má určit další krok. Adresa vede ke čtení kategorií dat. Heslo vede ke změně tajemství. Oznámení správce vede k jeho instrukcím. Relace vede k ochraně účtu. Kdo tyto kroky oddělí, nemusí hádat, zda má být v klidu, nebo v panice.
Správná otázka proto nezní jen: „Uniklo mi heslo?“ Správná otázka zní: „Kterou vrstvu jsem právě změřil: známý dump, otisk hesla, stuffingový seznam, ohlášení správce, nebo cizí relaci, a co z ní ještě neplyne?“ Teprve potom má smysl měnit heslo, číst oznámení, kontrolovat relace nebo podávat stížnost. Ne proto, že panika je slabost. Protože nepřesná reakce je další riziko.
Dobrá odpověď tedy není „všechno je v pořádku“ ani „všechno je ztracené“. Dobrá odpověď je menší a přesnější. E-mail v indexu se čte jako stopa ve známém souboru. Heslo v Pwned Passwords se čte jako tajemství, které už není vhodné používat. Stuffingový seznam se čte jako varování před opakováním. Oznámení správce se čte jako právní a praktická instrukce k určitému incidentu. A cizí relace se řeší jako provoz účtu, ne jako další vyhledávání na webu.
Z toho neplyne, že indexy nemají cenu. Plyne z toho, že cenu mají jen tehdy, když se k nim váže správná vrstva a správný krok. Have I Been Pwned, Sentinel View nebo oznámení ÚOOÚ pak přestanou být jedním červeným tlačítkem. Stanou se mapou. Mapa není zámek. Ale bez mapy se zámek mění naslepo.
Související texty této řady
- Jak poznat podvodný e-mail, SMS nebo telefonát? — kanál útoku vs. index úniku.
- Co je digitální stopa… — HIBP je jedna vrstva, ne celý internet.