Uložiť SHA-256 namiesto hesla vyzerá bezpečne, pretože digest nemožno jednoducho dešifrovať. Útočník však nič neobracia. Po krádeži databázy hashujú slovníky, uniknuté heslá a ich obmeny, kým nenájdu zhodu. Všeobecné hash funkcie sú zámerne rýchle, čo je výborné pre súbory a nebezpečné pre heslá. Password hashing robí každý guess drahým.

Offline útok obchádza login ochrany

Rate limit, CAPTCHA a MFA chránia online endpoint. Kópia databázy umožní útočníkovi používať vlastný hardware bez kontaktu so službou.

Ľudské heslá majú nízku entropiu. Ochranu určuje cena každého kandidáta a nemožnosť zdieľať prácu medzi účtami.

Unikátna soľ ruší spoločný prepočet

Salt je náhodná hodnota pre každý účet. Dve rovnaké heslá potom vytvoria rozdielny stored hash a rainbow table nemožno použiť na celú databázu.

Soľ nemusí byť tajná. Moderná knižnica ju generuje a uloží spolu s algoritmom a parametrami v encoded formáte.

Password algoritmus je zámerne nákladný

Argon2id, scrypt, bcrypt a PBKDF2 umožňujú nastaviť work factor. Memory-hard algoritmus znižuje výhodu masívne paralelného GPU hardwaru.

Ručné opakovanie SHA-256 nie je rovnocenné reviewed konštrukcii. Platformové API rieši formát, soľ a bezpečné verify.

Parametre sa vyvíjajú s hardwarom

Stored string nesie algorithm version a cost. Po úspešnom login-e možno heslo rehashovať silnejším nastavením bez samostatnej migrácie plaintextu.

Funkcia needsRehash umožní postupný upgrade. Dlho neaktívne účty môžu pri citlivej udalosti potrebovať reset.

Pepper je oddelené tajomstvo

Server môže pridať secret uložený mimo databázy. Samotný dump potom nestačí na guessing. Pepper však potrebuje secret manager, dostupnosť a rotation plan.

Nenahrádza silný algoritmus ani soli. Jeho strata môže znemožniť overenie všetkých účtov.

Heslo nesmie byť obnoviteľné

Služba, ktorá vie poslať existujúce heslo, ho drží v plaintext alebo reverzibilne. Bezpečný systém iba overuje a pri zabudnutí vytvorí krátko platný jednorazový reset token.

Plaintext nesmie uniknúť do logu, analytics, error reportu ani support nástroja pred hashovaním.

Login nemá prezrádzať existenciu účtu

Odlišná správa alebo výrazne kratší čas pre neznámy e-mail pomáha enumerácii. Systém môže vykonať reprezentatívny hash aj pri neexistujúcom účte a vrátiť všeobecnú chybu.

Rate limit kombinuje účet, sieť a širšie abuse signály bez trvalého lockoutu obete.

Cost parameter patrí do auditu

Názov Argon2 nestačí, ak memory a time cost zostali príliš nízke. Tím pravidelne benchmarkuje produkčne podobný hardware a určuje cieľovú login latency.

Núdzové zníženie ceny kvôli výkonu je bezpečnostná zmena s vlastníkom a termínom návratu.

Breach response sa pripravuje vopred

Silný hash kupuje čas, nerobí ukradnutú databázu neškodnou. Organizácia musí poznať algoritmy účtov, zrušiť sessions, vynútiť reset podľa rizika a informovať používateľov.

Po incidente rastie credential stuffing. Monitoring má sledovať neobvyklé pokusy bez exportu stored hashov.

Autentizácia potrebuje ďalšie vrstvy

Hashing nezastaví phishing, malware ani reused password. MFA, passkeys, breached-password screening, bezpečné sessions a upozornenia pokrývajú ďalšie hrozby.

Politika podporuje dĺžku a password managers namiesto častých zmien, ktoré vedú k predvídateľným variantom.

Servisný účet nie je výnimka

Administrátorské a dočasné účty potrebujú rovnakú ochranu. Secret vložený do deployment scriptu alebo zdieľaný medzi prostrediami obíde kvalitný hash.

Rýchly hash fingerprintuje dáta; password hash bráni guessing. Udržovaná knižnica, moderný cost, soli a upgrade plan tvoria základ špecializovanej disciplíny.

Password policy musí rátať aj s maximálnou dĺžkou vstupu. Extrémne veľké heslo môže pri memory-hard algoritme vytvoriť nečakanú spotrebu ešte pred rate limitom, no príliš krátky limit poškodí password managers. Knižnica má dostať bytes v jednom definovanom Unicode encodingu a aplikácia nesmie potichu meniť case alebo whitespace, ktoré používateľ považuje za súčasť secretu. Zmena normalizácie po rokoch by spôsobila, že existujúce heslá prestanú fungovať. Všetky tieto pravidlá preto patria do stabilného autentizačného kontraktu a regresných testov.

Rovnaké bezpečnostné pravidlá musia vždy konzistentne používať web, mobilná aplikácia aj administratívne rozhranie.

Migrácia z legacy hashu potrebuje bezpečný checkpoint

Ak databáza obsahuje MD5, SHA-1 alebo slabý bcrypt cost, aplikácia nemá plaintext na hromadný rehash. Pri ďalšom úspešnom prihlásení však pozná správne heslo v pamäti a môže ho okamžite uložiť moderným algoritmom. Stored format musí prezradiť, ktorú verify funkciu použiť.

Starý verifier zostáva dostupný iba pre existujúce záznamy a nesmie vytvárať nové. Metrika ukazuje počet zostávajúcich účtov. Po stanovenej dobe môžu neaktívne účty vyžadovať reset, aby legacy cesta nezostala otvorená navždy.

Password hashing ovplyvňuje kapacitu login služby

Vyšší memory cost zvyšuje obranu, ale súbežné login-y môžu vyčerpať RAM. Benchmark preto sleduje nielen latency jedného requestu, ale bezpečnú concurrency, container limits a správanie pri abuse. Rate limit chráni aj vlastné zdroje.

Hashing možno vykonávať v oddelenom worker pool-e, aby neblokoval event loop. Queue však nesmie vytvoriť timing rozdiel medzi existujúcim a neexistujúcim účtom. Prevádzkový návrh je súčasťou bezpečnosti algoritmu.

Reset token sa neukladá ako heslo, ale potrebuje ochranu

Náhodný reset token má vysokú entropiu a krátku platnosť, takže server môže uložiť jeho rýchly kryptografický hash a pri použití ho porovnať. Na rozdiel od ľudského hesla nie je guessable zo slovníka. Token sa po prvom použití zneplatní.

Purpose, account a expiry musia byť pevne viazané. Únik databázy nemá poskytnúť priamo použiteľné tokeny a úspešný reset má zrušiť staré sessions podľa rizika produktu.