Před čím vás hashování hesla skutečně chrání

Stručná verze

Hashování hesla chrání uživatele ve chvíli, kdy je vaše databáze hesel odcizena.

To je jeho hlavní úkol. Ne jediný detail, ne celý bezpečnostní model, ale hlavní důvod, proč hesla hashujeme místo toho, abychom je ukládali přímo.

Správně zahashované heslo je obtížné převést zpět. Pokud útočník získá kopii vaší tabulky uživatelů, neměl by se okamžitě dozvědět, že Alicino heslo je Spring2026!. Místo toho získá uložený hash, jehož ověřování proti tipům stojí čas, peníze a hardware.

Na tomto rozdílu záleží. Hashování hesel nemá samo o sobě zajistit bezpečné přihlašování. Nezastaví phishing. Nezastaví někoho, kdo zkouší uniklá hesla ve vašem přihlašovacím formuláři. Neochrání session cookie po přihlášení. Kupuje čas a snižuje škody po velmi konkrétním selhání: úložiště vašich ověřovačů hesel se stane dostupným.

Když tuto hranici pochopíte, budete dělat lepší rozhodnutí o algoritmech, pracovních faktorech, resetech, logování a reakci na incidenty.

Co je hash hesla

Hash hesla je výstup jednosměrné funkce aplikované na heslo, obvykle s unikátní solí a záměrně pomalým algoritmem pro hashování hesel.

Když si uživatel vytváří účet, systém by měl zhruba provést toto:

1. Přijmout heslo přes HTTPS.
2. Vygenerovat náhodnou, unikátní sůl.
3. Spustit heslo a sůl přes funkci pro hashování hesel, například Argon2id, bcrypt, scrypt nebo PBKDF2.
4. Uložit název algoritmu, parametry, sůl a výsledný hash.
5. Zahodit původní heslo.

Když se uživatel později přihlašuje, systém zopakuje stejný proces hashování s odeslaným heslem a uloženými parametry. Pokud se výsledný hash shoduje s uloženým hashem, přihlášení uspěje.

Důležité je toto: aplikace nemusí znát původní heslo. Potřebuje pouze ověřit, že odeslané heslo vytvoří očekávaný výsledek.

Proto je ukládání hesel pomocí reverzibilního šifrování obvykle špatný model. Pokud vaše aplikace dokáže dešifrovat každé heslo, pak totéž dokáže kdokoli, kdo ukradne dešifrovací klíč. Hesla by normálně měla být zpětně neověřitelná, ne pouze skrytá.

Před čím vás hashování chrání

1. Okamžité odhalení hesel po prolomení databáze

Pokud útočník ukradne databázi obsahující hesla v prostém textu, škoda je okamžitá. Každé heslo je odhaleno. Uživatelé jsou v ohrožení nejen na vašem webu, ale všude, kde stejné heslo znovu použili.

Pokud databáze obsahuje dobře zahashovaná hesla, útočník má více práce. Musí hádat kandidátní hesla, každý tip zahashovat se správnou solí a parametry a porovnat výsledek.

U slabých hesel to stále může být rychlé. U silných unikátních hesel to může být nepraktické.

Hashování mění katastrofické odhalení v závod: stihnou si uživatelé resetovat hesla a dokážete incident omezit dříve, než útočníci prolomí mnoho z nich?

Není to dokonalé. Stále jde o únik. Ale je to dramaticky lepší způsob selhání.

2. Hromadné útoky proti celé uživatelské základně

Soli jsou klíčovou součástí ukládání hesel, protože útočníkům brání efektivně útočit na mnoho uživatelů najednou pomocí předpočítaných tabulek.

Sůl není tajná. Ukládá se vedle hashe. Jejím úkolem je jedinečnost.

Pokud si dva uživatelé zvolí stejné heslo, unikátní soli zajistí, že jejich uložené hashe budou odlišné. To útočníkům brání na první pohled vidět, že mnoho uživatelů sdílí stejné heslo. Zároveň to brání klasickým útokům pomocí rainbow tables, kdy útočníci používají obrovské předpočítané seznamy mapování hesel na hashe.

Bez solí může jeden prolomený hash odhalit každého uživatele se stejným heslem. Se solemi musí být každý tip hesla testován zvlášť pro každého uživatele.

3. Rychlé offline hádání

Jakmile útočníci mají databázi hesel, mohou hádat offline. To znamená, že vaše limity rychlosti přihlašování, CAPTCHA, blokování IP adres a monitoring už nehrají roli. Útočník může testovat tipy na vlastním hardwaru.

Právě zde záleží na volbě algoritmu.

Obecné hashovací funkce jako SHA-256 a SHA-512 jsou navrženy tak, aby byly rychlé. To je dobré pro integritu souborů a digitální podpisy. Je to špatné pro ukládání hesel.

Algoritmy pro hashování hesel jsou navrženy tak, aby byly pomalé, laditelné a někdy paměťově náročné. Argon2id, bcrypt, scrypt a PBKDF2 umožňují nastavovat nákladové parametry tak, aby každý tip vyžadoval nezanedbatelný čas.

Argon2id se široce doporučuje pro nové systémy, protože jej lze nakonfigurovat tak, aby vyžadoval čas CPU i paměť, což zdražuje rozsáhlé prolamování na GPU. bcrypt zůstává běžný a přijatelný, pokud je dobře nakonfigurovaný, i když má omezení, například při zpracování délky hesla. PBKDF2 se stále používá v některých prostředích řízených compliance požadavky, zejména tam, kde jsou vyžadovány komponenty validované podle FIPS.

Princip je jednoduchý: legitimní přihlášení ponechat přijatelně rychlá a miliardy tipů udělat drahé.

Před čím vás hashování nechrání

1. Phishing

Pokud uživatel zadá své heslo na falešné přihlašovací stránce, hashování na vašem serveru nepomůže. Útočník získá heslo dříve, než ho váš systém vůbec uvidí.

Obrany jsou zde jiné: vícefaktorové ověřování, passkeys, vzdělávání uživatelů, doménová hygiena, ověřování odolné proti phishingu a pečlivě navržené procesy resetu hesla.

Hashování hesel je záložní ochrana pro uložená tajemství. Není to obrana proti tomu, aby byli uživatelé oklamáni a tato tajemství prozradili.

2. Credential stuffing

Credential stuffing nastává, když útočníci vezmou dvojice uživatelských jmen a hesel uniklé z jedné služby a zkoušejí je v jiné.

Vaše hashe hesel mohou být výborné, a credential stuffing přesto může fungovat, pokud uživatelé hesla znovu používají.

Jde o online útok proti vašemu přihlašovacímu formuláři, ne o offline útok proti vaší databázi. Potřebujete limity rychlosti, detekci anomálií, kontroly proti databázím prolomených hesel, MFA a rozumné zásady uzamykání účtů, které nevytvářejí snadné příležitosti k denial-of-service.

Stejné praktické uvažování platí pro každý veřejně dostupný formulář. Pokud revidujete svou autentizační plochu, stojí za to přečíst si, proč je váš kontaktní formulář vaší největší spamovou slabinou; mechanika se liší, ale poučení je podobné: veřejné vstupy potřebují ochrany proti zneužití, nejen čistý backendový kód.

3. Hesla zachycená v logách nebo analytice

Hashování pomáhá jen tehdy, pokud je heslo v prostém textu rychle zahozeno a nikdy se nezkopíruje jinam.

Mezi běžná selhání patří:

• Logování celých těl požadavků při neúspěšných pokusech o přihlášení.
• Odesílání hesel do nástrojů pro monitoring chyb.
• Zachytávání polí s hesly v produktech pro přehrávání relací.
• Vkládání přihlašovacích údajů do URL během špatně navržených resetovacích nebo migračních toků.
• Ukládání dočasných hesel v prostém textu při importech.

Tyto chyby hashování hesel zcela obcházejí. Pokud se prostý text dostane do logů, záloh, datových skladů nebo nástrojů třetích stran, vaše hashovací funkce je irelevantní.

Zacházejte s poli pro hesla jako s toxickými daty. Redigujte je před logováním. Vyřaďte je z analytiky. Nedávejte je do URL. Omezte, kdo má přístup k produkčním trasám a stopám.

4. Špatné zabezpečení relací

Po přihlášení prohlížeč uživatele obvykle obdrží session cookie nebo token. Pokud je tento token ukraden, útočník heslo vůbec nemusí potřebovat.

Hashování hesel nechrání před cross-site scriptingem, nezabezpečenými cookies, session fixation, slabým generováním tokenů ani příliš dlouhou životností relací.

Session cookies si zaslouží vlastní kontrolu: HttpOnly, Secure, vhodné SameSite, krátkodobé vysoce rizikové relace a serverové zneplatnění při změnách hesla. Širší oblast soukromí a prohlížečů se také dál posouvá, jak popisuje článek co se změnilo u cookies v roce 2026.

5. Slabý reset hesla a obnova účtu

Mnoho převzetí účtu nezačíná heslem. Začíná procesem resetu.

Pokud jsou resetovací tokeny předvídatelné, dlouho platné, unikají přes hlavičky referrer nebo jsou posílány na kompromitované e-mailové účty, hashování hesel vás nezachrání.

Používejte resetovací tokeny s vysokou entropií, krátká okna platnosti, jednorázové použití a jasná upozornění pro uživatele. Protože e-mail je často kanálem obnovy, záleží i na základním ověřování domény. Pokud váš tým považuje DNS záznamy za tajemný obřad, začněte vývojářsky přívětivou prohlídkou MX, SPF, DKIM a DMARC.

Volba algoritmu: co používat dnes

Pro nové aplikace používejte Argon2id, pokud ho vaše platforma dobře podporuje. Je vítězem Password Hashing Competition a je navržen pro ukládání hesel, včetně odolnosti proti prolamování silně využívajícímu GPU.

Rozumná moderní hierarchie vypadá takto:

1. Argon2id pro nové systémy, kde je dostupný.
2. bcrypt tam, kde Argon2id není praktický a podpora bcrypt je vyspělá.
3. scrypt tam, kde je dobře podporována paměťově náročná konfigurace.
4. PBKDF2 tam, kde to vyžaduje platforma nebo compliance omezení.

Vyhněte se prostému SHA-256, SHA-512, MD5 nebo vlastní kombinaci typu sha256(password + salt). Rychlé hashe nejsou funkce pro ukládání hesel. Chytré vlastní konstrukce bývají horší než nudné standardní.

Také nevymýšlejte vlastní politiku hesel založenou na drobnostech algoritmů. Uživatelé nemají užitek z kontrolního seznamu 12 pravidel pro skladbu hesla, pokud je tlačí k předvídatelným vzorcům. Delší unikátní hesla, správci hesel, kontrola proti prolomeným heslům a MFA obvykle znamenají víc.

Nákladové faktory nejsou nastav a zapomeň

Hashování hesel má parametry. Argon2id má paměť, iterace a paralelismus. bcrypt má nákladový faktor. PBKDF2 má počet iterací.

Tyto hodnoty by měly být zvoleny podle vašeho produkčního prostředí. Příliš nízké a útočníci hádají levně. Příliš vysoké a váš přihlašovací systém se zpomalí nebo bude zranitelný vůči denial-of-service.

Praktický cíl často leží v rozsahu desítek až několika stovek milisekund na jedno ověření hesla na vašich skutečných serverech, podle provozu a rizika. Vysoce zabezpečené systémy mohou zvolit více. Systémy pro masové spotřebitele mohou potřebovat pečlivé plánování kapacity.

Nekopírujte nákladový faktor z pět let starého blogového článku. Hardware se mění. Knihovny se mění. Váš provoz se mění.

Parametry pravidelně revidujte a plánujte rehashování. Běžný vzor je ukládat algoritmus a parametry s každým hashem. Při úspěšném přihlášení, pokud jsou uložené parametry zastaralé, zahashujte odeslané heslo znovu s novější konfigurací a aktualizujte záznam.

Peppers: užitečné, ale ne náhrada

Pepper je tajná hodnota přidaná do procesu hashování hesla a uložená odděleně od databáze, často ve správci tajemství nebo hardwarovém bezpečnostním modulu.

Na rozdíl od soli musí pepper zůstat tajný.

Peppers mohou snížit škody, pokud unikne databáze, ale ne aplikační tajemství. Nejužitečnější jsou ve vyspělých prostředích s dobrou správou klíčů. Méně užitečné jsou, pokud tentýž útočník dokáže ukrást databázi i konfiguraci aplikace.

Pokud pepper používáte, pečlivě naplánujte rotaci. Podle návrhu může rotace vyžadovat, aby se uživatelé znovu přihlásili nebo resetovali hesla. Pepper je dodatečná vrstva, ne důvod oslabit základní nastavení hashe.

Provozní kontrolní seznam

Pokud jste odpovědní za skutečný systém, praktický kontrolní seznam je krátký:

• Ukládejte hesla pouze pomocí standardního algoritmu pro hashování hesel.
• Používejte pro každé heslo unikátní náhodnou sůl.
• U nových systémů preferujte Argon2id.
• Laďte nákladové parametry na hardwaru podobném produkci.
• Ukládejte algoritmus a parametry s každým hashem.
• Rehashujte při přihlášení, když parametry zastarají.
• Nikdy nelogujte hesla ani je neposílejte do analytických nástrojů.
• Používejte TLS všude, kde se odesílají přihlašovací údaje.
• Přidejte MFA nebo passkeys tam, kde to riziko ospravedlňuje.
• Chraňte resetovací toky stejně vážně jako přihlašovací toky.
• Mějte plán incidentu pro vynucené resety a informování uživatelů.

Hashování hesel není okázalé. Je to instalatérství. Ale právě takové instalatérství rozhoduje o tom, zda se únik stane bolestivým incidentem, nebo katastrofou pro všechny uživatele.

<!-- tool-cta:start -->

💡 Vyzkoušejte toto: Podívejte se, jak se stejný vstup mapuje na různé algoritmy pomocí Hash Generator, který názorně ukazuje rozdíl mezi rychlými hashi a hashi na úrovni hesel.

<!-- tool-cta:end -->

Poctivý mentální model

Nejlepší způsob, jak o hashování hesel přemýšlet, je tento:

Hashování nechrání heslo ve chvíli, kdy ho uživatel píše. Nechrání účet poté, co je uživatel přihlášen. Nechrání uživatele, kteří znovu používají hesla napříč webem.

Chrání uložený ověřovač.

To zní úzce, ale je to mimořádně důležité. Databáze unikají. Zálohy unikají. Stagingové systémy se kopírují. Dodavatelé získávají přístup, který by neměli mít. Staré exporty leží v object storage déle, než si kdokoli pamatuje.

Když se to stane, návrh vašeho ukládání hesel rozhodne o rozdílu mezi tím, zda útočníci dostanou hesla, nebo drahý problém hádání.

Přesně před tím vás hashování hesla skutečně chrání.