Uložit místo hesla SHA-256 působí bezpečně, protože z digestu neexistuje jednoduchá dešifrovací cesta. Útočník ale nemusí nic obracet. Po krádeži databáze hashování opakuje nad slovníky, uniklými hesly a jejich obměnami, dokud nenajde shodu. Obecné kryptografické hashe jsou optimalizované na rychlost, takže moderní hardware zvládne obrovské množství pokusů. Password hashing sleduje opačný cíl: každý odhad má být dostatečně pomalý a nákladný, zatímco legitimní přihlášení zůstane pro uživatele přijatelné.

Po úniku databáze probíhá útok offline

Online formulář lze chránit rate limitem, detekcí anomálií a druhým faktorem. Kopie tabulky s hashi tyto vrstvy obchází. Útočník používá vlastní GPU či specializovaný hardware a aplikace jeho pokusy nevidí. Obrana proto stojí na ceně jednoho guessu a na tom, zda lze práci sdílet mezi účty.

Lidská hesla mají nízkou entropii. Uživatelé volí slova, jména, roky a opakované vzory. Jednosměrná funkce tuto předvídatelnost neodstraní; může pouze učinit každé ověření dražší.

Unikátní sůl ruší společnou předvýpočetní výhodu

Salt je náhodná hodnota vytvořená zvlášť pro každý uložený hash. Algoritmus zpracuje sůl společně s heslem, takže dva uživatelé se stejným heslem dostanou rozdílné výsledky. Útočník nemůže jednou tabulkou porovnat celý dump ani okamžitě poznat sdílená hesla.

Sůl nemusí být tajná. Musí být unikátní, dostatečně dlouhá a generovaná bezpečným zdrojem. Moderní password API ji vytvoří a uloží do standardního encoded formátu spolu s algoritmem a parametry. Vlastní schéma přidává riziko bez užitku.

Algoritmus je záměrně nákladný

Argon2, scrypt, bcrypt a PBKDF2 dovolují nastavit cenu výpočtu. Argon2id a scrypt navíc pracují s významným množstvím paměti, což omezuje výhodu masivně paralelního hardwaru. Parametry se volí podle reálného serveru tak, aby běžné přihlášení mělo přijatelnou latency a hromadné hádání bylo drahé.

Ruční opakování SHA-256 není rovnocennou náhradou. Specializované konstrukce prošly analýzou, mají známý formát a knihovny řeší sůl i bezpečné ověření. Aplikace nemá navrhovat vlastní kryptografický protokol.

Parametry se musí vyvíjet s hardwarem

Náklad považovaný za silný dnes může být za několik let levný. Uložený řetězec proto obsahuje verzi algoritmu a parametry. Aplikace dokáže ověřit starší záznam a po úspěšném přihlášení heslo znovu zahashovat aktuálním nastavením, aniž by znala plaintext před tímto okamžikem.

Platformní API obvykle nabízí funkci typu needsRehash. Migrace může probíhat postupně; účty, které se dlouho nepřihlásily, mohou být při citlivé události vyzvány k resetu.

Pepper přidává oddělené tajemství

Některé systémy kombinují heslo a sůl ještě se serverovým tajemstvím zvaným pepper. Pokud unikne pouze databáze, bez hodnoty uložené v secret manageru je ověřování kandidátů těžší. Pepper však vytváří provozní odpovědnost: musí být dostupný autentizační službě, chráněný a rotovatelný.

Není náhradou za silný password hash, unikátní soli ani kontrolu přístupu k databázi. Jeho ztráta může znemožnit všechna přihlášení a kompromitace vyžaduje promyšlenou migraci.

Heslo se nesmí dát uživateli poslat zpět

Služba, která umí e-mailem sdělit stávající heslo, jej ukládá v plaintextu nebo reverzibilně. Bezpečný systém pouze ověří předloženou hodnotu proti hashi. Zapomenuté heslo řeší reset pomocí náhodného, krátce platného a jednorázového tokenu.

Plaintext nesmí uniknout ani před hashováním. Log requestu, analytics event, debug dump či chybová zpráva mohou obejít veškerou ochranu databáze. Citlivá pole je nutné redigovat v celé cestě požadavku.

Ověření nemá prozrazovat existenci účtu

Rozdílná zpráva nebo výrazně rychlejší odpověď pro neznámý e-mail pomáhá enumeraci uživatelů. Systém může i u neexistujícího účtu provést reprezentativní password hash a vrátit obecnou chybu. Rate limit má kombinovat účet, síť a širší signály, aby útočník nemohl snadno distribuovat pokusy ani trvale zamknout oběť.

Porovnání patří knihovní verify funkci. Ruční parsování encoded hashe a vlastní equality check mohou vytvořit chybu kompatibility nebo timing leak.

Silný hash pouze omezuje škodu po incidentu

Dobré parametry dávají organizaci čas, ale nečiní ukradenou databázi neškodnou. Incidentní plán musí znát používané algoritmy, umět zrušit aktivní relace, vyžádat reset rizikových účtů a jasně informovat uživatele. Po úniku roste také riziko credential stuffing proti jiným službám.

Metriky by měly ukázat zastoupení starých hashů bez exportu samotných hodnot. Tým pak ví, zda migrace postupuje a kolik účtů potřebuje zvláštní postup.

Parametry patří do bezpečnostního auditu

Pouhé jméno Argon2 nebo bcrypt nestačí. Příliš nízký časový, paměťový či work faktor může být na současném hardware levný. Organizace má pravidelně benchmarkovat přihlášení na produkčně podobném stroji, stanovit cílovou latency a sledovat, zda změna kapacity nesnížila ochranu. Konfigurace musí být verzovaná a stejná ve všech instancích. Nouzové snížení ceny kvůli výkonu je bezpečnostní změna, která potřebuje vlastníka, časový limit a následnou nápravu.

Autentizace potřebuje více vrstev

Password hashing nebrání phishingu, malwaru ani opakovanému použití hesla. Vícefaktorová autentizace, passkeys, kontrola známých uniklých hesel, bezpečné relace a upozornění na přihlášení snižují další rizika. Politika má podporovat délku a správce hesel místo častých vynucených změn, které vedou k předvídatelným variantám.

Rozdíl je jednoduchý: rychlý hash efektivně otiskuje data, password hash záměrně zdražuje hádání. Udržovaná knihovna, moderní parametry, automatické soli a plán postupného rehashingu tvoří minimum. Ukládání hesel není běžné volání hash funkce, ale samostatná bezpečnostní disciplína.

Stejná pravidla platí pro administrátorské, servisní i dočasné účty; výjimka v méně viditelné části systému může otevřít stejně hodnotnou cestu k datům.