От какво всъщност ви предпазва хеширането на парола

Кратката версия

Хеширането на парола защитава потребителите, когато базата ви данни с пароли бъде открадната.

Това е основната му задача. Не единственият детайл, не целият модел за сигурност, а централната причина да хешираме пароли, вместо да ги съхраняваме директно.

Правилно хешираната парола е трудна за обръщане. Ако нападател получи копие от таблицата ви с потребители, той не би трябвало веднага да разбере, че паролата на Alice е Spring2026!. Вместо това получава съхранен хеш, чието проверяване срещу предположения изисква време, пари и хардуер.

Тази разлика е важна. Хеширането на пароли не е предназначено само по себе си да направи вписването сигурно. То не спира фишинг. Не спира някого да пробва изтекли пароли във формата ви за вход. Не защитава session cookie след вход. То печели време и намалява вредата след много конкретен провал: съхранението на вашите верификатори на пароли става достъпно.

Ако разбирате тази граница, ще вземате по-добри решения за алгоритми, work factors, нулирания, логване и реакция при инциденти.

Какво е хеш на парола

Хешът на парола е изходът от еднопосочна функция, приложена към парола, обикновено с уникална salt стойност и умишлено бавен алгоритъм за хеширане на пароли.

Когато потребител създава акаунт, системата трябва приблизително да направи следното:

1. Да получи паролата през HTTPS.
2. Да генерира случайна, уникална salt стойност.
3. Да прекара паролата и salt стойността през функция за хеширане на пароли като Argon2id, bcrypt, scrypt или PBKDF2.
4. Да съхрани името на алгоритъма, параметрите, salt стойността и получения хеш.
5. Да изхвърли оригиналната парола.

Когато потребителят по-късно се впише, системата повтаря същия процес на хеширане с подадената парола и съхранените параметри. Ако полученият хеш съвпада със съхранения хеш, входът е успешен.

Важната част: приложението няма нужда да знае оригиналната парола. Трябва само да провери, че подадената парола произвежда очаквания резултат.

Затова съхраняването на пароли с обратимо криптиране обикновено е грешният модел. Ако приложението ви може да декриптира всяка парола, тогава всеки, който открадне ключа за декриптиране, може да направи същото. Паролите обикновено трябва да са непроверими в обратна посока, а не просто скрити.

От какво ви защитава хеширането

1. Незабавно разкриване на пароли след пробив в база данни

Ако нападател открадне база данни, съдържаща пароли в чист текст, щетата е мигновена. Всяка парола е разкрита. Потребителите са изложени на риск не само във вашия сайт, а навсякъде, където са използвали повторно тази парола.

Ако базата данни съдържа добре хеширани пароли, нападателят има повече работа. Той трябва да отгатва кандидат-пароли, да хешира всяко предположение с правилната salt стойност и параметри и да сравнява резултата.

За слаби пароли това все още може да е бързо. За силни уникални пароли може да е непрактично.

Хеширането превръща катастрофално разкриване в надпревара: могат ли потребителите да сменят паролите си и можете ли да овладеете инцидента, преди нападателите да разбият много от тях?

Това не е перфектно. Все още е пробив. Но е драматично по-добър режим на отказ.

2. Масови атаки срещу цялата ви потребителска база

Salt стойностите са ключова част от съхранението на пароли, защото пречат на нападателите ефективно да атакуват много потребители наведнъж с предварително изчислени таблици.

Salt стойността не е тайна. Тя се съхранява заедно с хеша. Нейната задача е уникалност.

Ако двама потребители изберат една и съща парола, уникалните salt стойности гарантират, че съхранените им хешове се различават. Това пречи на нападателите с един поглед да видят, че много потребители споделят една и съща парола. Също така предотвратява класическите атаки с rainbow tables, при които нападателите използват огромни предварително изчислени списъци със съответствия парола-към-хеш.

Без salt стойности един разбит хеш може да разкрие всеки потребител със същата парола. Със salt стойности всяко предположение за парола трябва да се тества отделно за всеки потребител.

3. Бързо офлайн отгатване

След като нападателите имат база данни с пароли, те могат да отгатват офлайн. Това означава, че ограниченията на честотата за вход, CAPTCHA, блокирането по IP и мониторингът вече нямат значение. Нападателят може да тества предположения на собствен хардуер.

Тук изборът на алгоритъм има значение.

Хешове с общо предназначение като SHA-256 и SHA-512 са проектирани да бъдат бързи. Това е добро за целостта на файлове и цифрови подписи. Лошо е за съхранение на пароли.

Алгоритмите за хеширане на пароли са проектирани да бъдат бавни, настройваеми и понякога memory-hard. Argon2id, bcrypt, scrypt и PBKDF2 ви позволяват да настройвате cost параметри, така че всяко предположение да отнема осезаемо време.

Argon2id е широко препоръчван за нови системи, защото може да бъде конфигуриран да изисква както CPU време, така и памет, което оскъпява мащабното разбиване с GPU. bcrypt остава разпространен и приемлив, когато е добре конфигуриран, макар че има ограничения, например при обработката на дължината на паролата. PBKDF2 все още се използва в някои среди, водени от изисквания за съответствие, особено там, където са необходими FIPS-валидирани компоненти.

Принципът е прост: направете легитимните входове приемливо бързи, а милиардите предположения — скъпи.

От какво хеширането не ви защитава

1. Фишинг

Ако потребител въведе паролата си във фалшива страница за вход, хеширането на вашия сървър не помага. Нападателят получава паролата, преди вашата система изобщо да я види.

Защитите тук са различни: многофакторна автентикация, passkeys, обучение на потребителите, хигиена на домейните, устойчива на фишинг автентикация и внимателни потоци за нулиране на парола.

Хеширането на пароли е предпазна мрежа за съхранени тайни. То не е защита срещу това потребителите да бъдат подмамени да предадат тези тайни.

2. Credential stuffing

Credential stuffing се случва, когато нападателите вземат двойки потребителско име и парола, изтекли от една услуга, и ги пробват в друга.

Вашите хешове на пароли може да са отлични и credential stuffing пак да работи, ако потребителите използват повторно пароли.

Това е онлайн атака срещу формата ви за вход, а не офлайн атака срещу базата ви данни. Нужни са ви ограничаване на честотата, откриване на аномалии, проверки за компрометирани пароли, MFA и разумни политики за заключване, които не създават лесни възможности за denial-of-service.

Същото практично мислене важи за всяка изложена форма. Ако преглеждате повърхността си за автентикация, струва си да прочетете защо формата ви за контакт е най-големият ви риск за spam; механизмите се различават, но урокът е сходен: публичните входове имат нужда от контроли срещу злоупотреба, не само от чист backend код.

3. Пароли, записани в логове или analytics

Хеширането помага само ако паролата в чист текст бъде изхвърлена бързо и никога не бъде копирана другаде.

Чести провали включват:

• Логване на пълни тела на заявки при неуспешни опити за вход.
• Изпращане на пароли към инструменти за мониторинг на грешки.
• Заснемане на полета за пароли в продукти за session replay.
• Включване на credentials в URL адреси при лошо проектирани потоци за нулиране или миграция.
• Съхраняване на временни пароли в чист текст по време на импорти.

Тези грешки напълно заобикалят хеширането на пароли. Ако чистият текст попадне в логове, backups, data warehouses или инструменти на трети страни, хеш функцията ви е без значение.

Отнасяйте се към полетата за пароли като към токсични данни. Редактирайте ги преди логване. Изключвайте ги от analytics. Дръжте ги извън URL адреси. Ограничете кой има достъп до production traces.

4. Лоша сигурност на сесиите

След вход браузърът на потребителя обикновено получава session cookie или token. Ако този token бъде откраднат, нападателят може изобщо да няма нужда от паролата.

Хеширането на пароли не защитава срещу cross-site scripting, несигурни cookies, session fixation, слабо генериране на tokens или прекалено дълъг живот на сесиите.

Session cookies заслужават собствен преглед: HttpOnly, Secure, подходящ SameSite, краткотрайни високорискови сесии и сървърна инвалидирация при промяна на парола. По-широкият контекст на privacy и браузърите също продължава да се променя, както е разгледано в какво се промени за cookies през 2026.

5. Слабо нулиране на пароли и възстановяване на акаунти

Много превземания на акаунти не започват с паролата. Те започват с потока за нулиране.

Ако reset tokens са предвидими, дългоживеещи, изтичат през referrer headers или се изпращат към компрометирани email акаунти, хеширането на пароли няма да ви спаси.

Използвайте reset tokens с висока ентропия, кратки прозорци на валидност, еднократна употреба и ясни известия към потребителя. Тъй като email често е каналът за възстановяване, базовата автентикация на домейна също има значение. Ако екипът ви третира DNS records като мистериозен ритуал, започнете с удобен за разработчици преглед на MX, SPF, DKIM и DMARC.

Изборът на алгоритъм: какво да използвате сега

За нови приложения използвайте Argon2id, ако платформата ви го поддържа добре. Той е победителят в Password Hashing Competition и е проектиран за съхранение на пароли, включително устойчивост срещу разбиване с много GPU ресурси.

Разумна съвременна йерархия изглежда така:

1. Argon2id за нови системи, където е наличен.
2. bcrypt когато Argon2id не е практичен и поддръжката на bcrypt е зряла.
3. scrypt когато memory-hard конфигурацията е добре поддържана.
4. PBKDF2 когато се изисква от платформата или ограничения за съответствие.

Избягвайте обикновени SHA-256, SHA-512, MD5 или самоделна комбинация като sha256(password + salt). Бързите хешове не са функции за съхранение на пароли. Умните персонализирани конструкции обикновено са по-лоши от скучните стандартни.

Също така избягвайте да измисляте собствена политика за пароли около алгоритмични подробности. Потребителите не печелят от списък с 12 правила за състав на парола, ако той ги тласка към предвидими модели. По-дългите уникални пароли, password managers, проверката за компрометирани пароли и MFA обикновено са по-важни.

Cost factors не са настройка „задай и забрави“

Хеширането на пароли има параметри. Argon2id има памет, итерации и паралелизъм. bcrypt има cost factor. PBKDF2 има брой итерации.

Тези стойности трябва да се избират според вашата production среда. Твърде ниски — и нападателите отгатват евтино. Твърде високи — и системата ви за вход става бавна или уязвима към denial-of-service.

Практична цел често е в диапазона от десетки до няколкостотин милисекунди за проверка на парола на реалните ви сървъри, в зависимост от трафика и риска. Системи с висока сигурност може да изберат повече. Системи в потребителски мащаб може да се нуждаят от внимателно планиране на капацитета.

Не копирайте cost factor от петгодишна blog публикация. Хардуерът се променя. Библиотеките се променят. Трафикът ви се променя.

Преглеждайте параметрите периодично и планирайте rehashing. Често срещан модел е да се съхраняват алгоритъмът и параметрите с всеки хеш. При успешен вход, ако съхранените параметри са остарели, хеширайте отново подадената парола с по-новата конфигурация и обновете записа.

Peppers: полезни, но не заместител

Pepper е тайна стойност, добавена към процеса на хеширане на парола и съхранявана отделно от базата данни, често в secrets manager или hardware security module.

За разлика от salt, pepper трябва да остане таен.

Peppers могат да намалят щетите, ако базата данни изтече, но application secrets не изтекат. Те са най-полезни в зрели среди с добро управление на ключове. По-малко полезни са, ако същият нападател може да открадне както базата данни, така и конфигурацията на приложението.

Ако използвате pepper, планирайте ротацията внимателно. Ротирането му може да изисква потребителите да влязат отново или да нулират паролите си, в зависимост от дизайна. Pepper е допълнителен слой, а не причина да отслабвате основните настройки на хеша.

Оперативният checklist

Ако отговаряте за реална система, практичният checklist е кратък:

• Съхранявайте пароли само със стандартен алгоритъм за хеширане на пароли.
• Използвайте уникална случайна salt стойност за всяка парола.
• Предпочитайте Argon2id за нови реализации.
• Настройвайте cost параметрите на хардуер, подобен на production.
• Съхранявайте алгоритъма и параметрите с всеки хеш.
• Rehash при вход, когато параметрите остареят.
• Никога не логвайте пароли и не ги изпращайте към analytics tools.
• Използвайте TLS навсякъде, където се подават credentials.
• Добавяйте MFA или passkeys там, където рискът го оправдава.
• Защитавайте reset flows толкова сериозно, колкото login flows.
• Имайте план за инциденти за принудителни нулирания и уведомяване на потребителите.

Хеширането на пароли не е бляскаво. То е инфраструктурна „водопроводна“ работа. Но е от онзи тип инфраструктура, която определя дали един пробив ще се превърне в болезнен инцидент или в бедствие за всички потребители.

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

💡 Опитайте това: Вижте как един и същ вход се съпоставя с различни алгоритми с Hash Generator, който прави разликата между бързите хешове и тези от клас за пароли осезаема.

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

Честният мисловен модел

Най-добрият начин да мислите за хеширането на пароли е този:

Хеширането не защитава паролата, докато потребителят я въвежда. Не защитава акаунта, след като потребителят е влязъл. Не защитава потребители, които използват повторно пароли в мрежата.

То защитава съхранения верификатор.

Това звучи тясно, но е изключително важно. Бази данни изтичат. Backups изтичат. Staging системи се копират. Доставчици получават достъп, който не би трябвало да имат. Стари exports стоят в object storage по-дълго, отколкото някой помни.

Когато това се случи, дизайнът ви за съхранение на пароли става разликата между това нападателите да получат пароли и това да получат скъп проблем за отгатване.

Това е, от което хеширането на парола всъщност ви предпазва.