Від чого насправді захищає хешування пароля

Коротка версія

Хешування пароля захищає користувачів, коли вашу базу даних паролів викрадено.

Це головне завдання. Не єдина деталь, не вся модель безпеки, але центральна причина, чому ми хешуємо паролі замість зберігати їх напряму.

Правильно захешований пароль важко відновити у зворотному напрямку. Якщо зловмисник отримує копію вашої таблиці користувачів, він не має одразу дізнатися, що пароль Alice — Spring2026!. Натомість він отримує збережений хеш, перевірка якого проти здогадок потребує часу, грошей і обладнання.

Ця різниця важлива. Хешування паролів не призначене для того, щоб саме по собі зробити вхід безпечним. Воно не зупиняє фішинг. Воно не зупиняє спроби перевіряти витеклі паролі через вашу форму входу. Воно не захищає сесійний cookie після входу. Воно виграє час і зменшує шкоду після дуже конкретного збою: сховище ваших верифікаторів паролів стає доступним.

Якщо ви розумієте цю межу, ви ухвалюватимете кращі рішення щодо алгоритмів, факторів складності, скидань, логування та реагування на інциденти.

Що таке хеш пароля

Хеш пароля — це результат односторонньої функції, застосованої до пароля, зазвичай з унікальною сіллю та навмисно повільним алгоритмом хешування паролів.

Коли користувач створює обліковий запис, система має приблизно зробити таке:

1. Отримати пароль через HTTPS.
2. Згенерувати випадкову унікальну сіль.
3. Пропустити пароль і сіль через функцію хешування паролів, таку як Argon2id, bcrypt, scrypt або PBKDF2.
4. Зберегти назву алгоритму, параметри, сіль і отриманий хеш.
5. Відкинути початковий пароль.

Коли користувач входить пізніше, система повторює той самий процес хешування з надісланим паролем і збереженими параметрами. Якщо отриманий хеш збігається зі збереженим хешем, вхід успішний.

Важлива частина: застосунку не потрібно знати початковий пароль. Йому потрібно лише перевірити, що надісланий пароль дає очікуваний результат.

Саме тому зберігання паролів із оборотним шифруванням зазвичай є неправильною моделлю. Якщо ваш застосунок може розшифрувати кожен пароль, то будь-хто, хто вкраде ключ розшифрування, зможе зробити те саме. Паролі зазвичай мають бути неперевірними у зворотному напрямку, а не просто прихованими.

Від чого захищає хешування

1. Негайне розкриття паролів після зламу бази даних

Якщо зловмисник викрадає базу даних із паролями у відкритому вигляді, шкода настає миттєво. Кожен пароль розкрито. Користувачі під загрозою не лише на вашому сайті, а й усюди, де вони повторно використали цей пароль.

Якщо база даних містить добре захешовані паролі, зловмиснику доведеться попрацювати більше. Він має вгадувати можливі паролі, хешувати кожну здогадку з правильною сіллю і параметрами та порівнювати результат.

Для слабких паролів це все ще може бути швидко. Для сильних унікальних паролів це може бути непрактично.

Хешування перетворює катастрофічне розкриття на перегони: чи встигнуть користувачі скинути паролі і чи зможете ви локалізувати інцидент до того, як зловмисники зламають багато з них?

Це не ідеально. Це все одно злам. Але це значно кращий режим відмови.

2. Масові атаки на всю вашу базу користувачів

Солі є ключовою частиною зберігання паролів, бо вони не дають зловмисникам ефективно атакувати багатьох користувачів одночасно за допомогою попередньо обчислених таблиць.

Сіль не є секретною. Вона зберігається поруч із хешем. Її завдання — унікальність.

Якщо два користувачі вибирають однаковий пароль, унікальні солі гарантують, що їхні збережені хеші відрізнятимуться. Це не дає зловмисникам одразу побачити, що багато користувачів мають той самий пароль. Це також запобігає класичним атакам rainbow table, коли зловмисники використовують величезні попередньо обчислені списки відповідностей пароль-хеш.

Без солей один зламаний хеш може розкрити кожного користувача з тим самим паролем. Із солями кожну здогадку пароля потрібно перевіряти окремо для кожного користувача.

3. Швидке офлайн-вгадування

Щойно зловмисники мають базу даних паролів, вони можуть вгадувати офлайн. Це означає, що ваші обмеження частоти входу, CAPTCHA, блокування IP та моніторинг більше не мають значення. Зловмисник може перевіряти здогадки на власному обладнанні.

Саме тут важливий вибір алгоритму.

Хеші загального призначення, такі як SHA-256 і SHA-512, спроєктовані бути швидкими. Це добре для цілісності файлів і цифрових підписів. Це погано для зберігання паролів.

Алгоритми хешування паролів спроєктовані бути повільними, налаштовуваними, а іноді й вимогливими до пам’яті. Argon2id, bcrypt, scrypt і PBKDF2 дають змогу налаштовувати параметри вартості так, щоб кожна здогадка потребувала відчутного часу.

Argon2id широко рекомендують для нових систем, бо його можна налаштувати так, щоб він вимагав і процесорного часу, і пам’яті, що робить масштабний злам на GPU дорожчим. bcrypt залишається поширеним і прийнятним за належного налаштування, хоча має обмеження, зокрема в обробці довжини пароля. PBKDF2 досі використовують у деяких середовищах, керованих вимогами відповідності, особливо там, де потрібні компоненти, валідовані за FIPS.

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

Від чого хешування не захищає

1. Фішинг

Якщо користувач вводить свій пароль на підробленій сторінці входу, хешування на вашому сервері не допоможе. Зловмисник отримує пароль ще до того, як ваша система його побачить.

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

Хешування паролів — це останній рубіж для збережених секретів. Це не захист від того, що користувачів обманом змушують віддати ці секрети.

2. Credential stuffing

Credential stuffing відбувається, коли зловмисники беруть пари імен користувачів і паролів, що витекли з одного сервісу, і пробують їх в іншому.

Ваші хеші паролів можуть бути чудовими, і credential stuffing все одно може спрацювати, якщо користувачі повторно використовують паролі.

Це онлайн-атака на вашу форму входу, а не офлайн-атака на вашу базу даних. Вам потрібні обмеження частоти, виявлення аномалій, перевірки на скомпрометовані паролі, MFA та розумні політики блокування, які не створюють легких можливостей для denial-of-service.

Таке саме практичне мислення застосовується до будь-якої відкритої форми. Якщо ви переглядаєте свою поверхню автентифікації, варто прочитати про те, чому ваша контактна форма — найбільша спам-вразливість; механіки відрізняються, але урок подібний: публічні поля введення потребують контролів проти зловживань, а не лише чистого backend-коду.

3. Паролі, захоплені в логах або аналітиці

Хешування допомагає лише тоді, коли пароль у відкритому вигляді швидко відкидається і нікуди більше не копіюється.

Поширені помилки включають:

• Логування повних тіл запитів під час невдалих спроб входу.
• Надсилання паролів до інструментів моніторингу помилок.
• Захоплення полів паролів у продуктах для відтворення сесій.
• Додавання облікових даних до URL під час погано спроєктованих процесів скидання або міграції.
• Зберігання тимчасових паролів у відкритому вигляді під час імпортів.

Ці помилки повністю обходять хешування паролів. Якщо відкритий текст потрапляє в логи, резервні копії, сховища даних або сторонні інструменти, ваша хеш-функція не має значення.

Ставтеся до полів паролів як до токсичних даних. Редагуйте їх перед логуванням. Виключайте їх з аналітики. Не допускайте їх в URL. Обмежуйте доступ до production-трасувань.

4. Погана безпека сесій

Після входу браузер користувача зазвичай отримує сесійний cookie або токен. Якщо цей токен викрадено, зловмиснику може взагалі не знадобитися пароль.

Хешування паролів не захищає від cross-site scripting, небезпечних cookies, session fixation, слабкої генерації токенів або надто довгого часу життя сесій.

Сесійні cookies заслуговують на окремий перегляд: HttpOnly, Secure, відповідний SameSite, короткоживучі сесії високого ризику та серверна інвалідація після зміни пароля. Ширший ландшафт приватності й браузерів також постійно змінюється, як описано в що змінилося для cookies у 2026 році.

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

Багато захоплень облікових записів починаються не з пароля. Вони починаються з процесу скидання.

Якщо токени скидання передбачувані, довгоживучі, витікають через заголовки referrer або надсилаються на скомпрометовані поштові скриньки, хешування паролів вас не врятує.

Використовуйте токени скидання з високою ентропією, короткі вікна дії, одноразове використання та зрозумілі сповіщення користувачів. Оскільки email часто є каналом відновлення, базова автентифікація домену теж важлива. Якщо ваша команда сприймає DNS-записи як загадковий ритуал, почніть із дружнього до розробників огляду MX, SPF, DKIM і DMARC.

Вибір алгоритму: що використовувати зараз

Для нових застосунків використовуйте Argon2id, якщо ваша платформа добре його підтримує. Це переможець Password Hashing Competition, спроєктований для зберігання паролів, зокрема для стійкості до зламу з інтенсивним використанням GPU.

Розумна сучасна ієрархія виглядає так:

1. Argon2id для нових систем, де він доступний.
2. bcrypt коли Argon2id непрактичний, а підтримка bcrypt зріла.
3. scrypt коли конфігурація з вимогами до пам’яті добре підтримується.
4. PBKDF2 де цього вимагають обмеження платформи або відповідності.

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

Також уникайте вигадування власної політики паролів навколо дрібниць алгоритмів. Користувачі не виграють від контрольного списку з 12 правил складу пароля, якщо він штовхає їх до передбачуваних шаблонів. Довші унікальні паролі, менеджери паролів, перевірка на скомпрометовані паролі та MFA зазвичай важливіші.

Фактори вартості не налаштовують один раз і назавжди

Хешування паролів має параметри. Argon2id має пам’ять, ітерації та паралелізм. bcrypt має фактор вартості. PBKDF2 має кількість ітерацій.

Ці значення слід вибирати на основі вашого production-середовища. Занадто низькі — і зловмисники вгадують дешево. Занадто високі — і ваша система входу стає повільною або вразливою до denial-of-service.

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

Не копіюйте фактор вартості з п’ятирічного допису в блозі. Обладнання змінюється. Бібліотеки змінюються. Ваш трафік змінюється.

Періодично переглядайте параметри й плануйте повторне хешування. Поширений підхід — зберігати алгоритм і параметри з кожним хешем. Після успішного входу, якщо збережені параметри застаріли, повторно захешуйте надісланий пароль з новішою конфігурацією та оновіть запис.

Peppers: корисні, але не заміна

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

На відміну від солі, pepper має залишатися секретним.

Peppers можуть зменшити шкоду, якщо база даних витече, а секрети застосунку — ні. Вони найкорисніші в зрілих середовищах із добрим керуванням ключами. Вони менш корисні, якщо той самий зловмисник може вкрасти і базу даних, і конфігурацію застосунку.

Якщо ви використовуєте pepper, ретельно плануйте ротацію. Його ротація може вимагати, щоб користувачі знову увійшли або скинули паролі, залежно від дизайну. Pepper — це додатковий шар, а не причина послаблювати базові налаштування хешу.

Операційний контрольний список

Якщо ви відповідаєте за реальну систему, практичний контрольний список короткий:

• Зберігайте паролі лише зі стандартним алгоритмом хешування паролів.
• Використовуйте унікальну випадкову сіль для кожного пароля.
• Віддавайте перевагу Argon2id для нових систем.
• Налаштовуйте параметри вартості на обладнанні, подібному до production.
• Зберігайте алгоритм і параметри з кожним хешем.
• Повторно хешуйте під час входу, коли параметри застарівають.
• Ніколи не логуйте паролі й не надсилайте їх до інструментів аналітики.
• Використовуйте TLS усюди, де надсилаються облікові дані.
• Додавайте MFA або passkeys там, де ризик це виправдовує.
• Захищайте процеси скидання так само серйозно, як процеси входу.
• Майте план інциденту для примусових скидань і сповіщення користувачів.

Хешування паролів не гламурне. Це інженерна сантехніка. Але саме така сантехніка визначає, чи стане злам болючим інцидентом, чи катастрофою для всіх користувачів.

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

💡 Спробуйте це: Подивіться, як один і той самий ввід зіставляється з різними алгоритмами за допомогою Hash Generator, який наочно показує різницю між швидкими хешами та хешами рівня паролів.

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

Чесна ментальна модель

Найкращий спосіб думати про хешування паролів такий:

Хешування не захищає пароль, поки користувач його вводить. Воно не захищає обліковий запис після того, як користувач увійшов. Воно не захищає користувачів, які повторно використовують паролі в інтернеті.

Воно захищає збережений верифікатор.

Це звучить вузько, але це надзвичайно важливо. Бази даних витікають. Резервні копії витікають. Staging-системи копіюють. Постачальники отримують доступ, якого не мали б мати. Старі експорти лежать в object storage довше, ніж будь-хто пам’ятає.

Коли це стається, ваш дизайн зберігання паролів стає різницею між тим, що зловмисники отримають паролі, і тим, що зловмисники отримають дорогу задачу на вгадування.

Ось від чого насправді захищає хешування пароля.