Ідея зберігати хеш замість пароля правильна лише наполовину. Звичайний SHA-256 є one-way function, але він навмисно працює дуже швидко. Після викрадення бази атакувальнику не потрібно відновлювати digest у зворотному напрямку: достатньо хешувати популярні слова, витоки й комбінації та шукати збіг. Спеціальне password hashing змінює економіку атаки, роблячи кожну окрему спробу достатньо дорогою.

Після витоку атака відбувається offline

На login endpoint діють rate limits, блокування, MFA та моніторинг. Копія таблиці з хешами прибирає ці обмеження: атакувальник працює на власному hardware, не надсилаючи запитів застосунку. Тому захист залежить від вартості кожного guess і від того, чи можна повторно використати обчислення для багатьох accounts.

Людські паролі мають обмежену entropy. Навіть довга фраза може бути передбачуваною, якщо вона походить із відомого шаблону. One-way властивість не компенсує слабкий input, коли перевірка мільйонів варіантів коштує дешево.

Salt робить однакові паролі різними

Salt є унікальним random value, який алгоритм обробляє разом із паролем. Двоє користувачів з однаковим password отримують різні stored hashes. Це руйнує готові rainbow tables і змушує атакувальника окремо працювати над кожним записом.

Salt не є секретом і зазвичай зберігається поруч із digest. Його важливі властивості — достатня випадковість та унікальність. Сучасні password libraries самі генерують salt і кодують його у standardized output, тому application code не повинен винаходити власний формат.

Password algorithms навмисно витрачають ресурси

Argon2, scrypt, bcrypt і PBKDF2 дозволяють налаштувати computational cost. Argon2 та scrypt також можуть вимагати значний обсяг пам’яті, зменшуючи перевагу спеціалізованого паралельного hardware. Параметри обирають так, щоб звичайний login залишався прийнятним, а масовий перебір був дорогим.

Багаторазовий ручний запуск SHA-256 не є рівноцінною заміною. Reviewed password algorithms мають визначену структуру, параметри й тривалу перевірку спільнотою. Саморобна схема часто містить слабке місце, яке не видно з кількості iterations.

Вартість повинна зростати разом із hardware

Параметри, достатні сьогодні, через кілька років стануть дешевими. Stored representation має містити назву алгоритму, salt і cost settings, щоб система могла перевіряти старі записи та поступово оновлювати їх. Після успішного входу застосунок може rehash password із поточними сильнішими параметрами.

Цей шлях міграції є ще однією причиною використовувати platform password API. Воно зазвичай уміє розпізнати формат, безпечно verify значення та повідомити, чи потрібен rehash.

Pepper додає окремий секрет, але й окремий ризик

Деякі системи додають server-held secret, відомий як pepper. Якщо витікає лише database, атакувальник не має всіх inputs для перевірки guesses. Pepper потрібно зберігати в secret manager окремо від бази та мати реалістичний процес rotation.

Це додатковий layer, а не заміна salt, сильного алгоритму або access control. Втрата pepper може зробити перевірку всіх паролів неможливою, а невдала rotation — заблокувати користувачів, тому operational design має бути пропрацьований заздалегідь.

Сервіс не повинен уміти повернути старий пароль

Якщо support може надіслати користувачу його чинний password, система зберігає його plaintext або reversibly encrypted. Надійна модель лише перевіряє новий input проти hash. У разі втрати використовується reset flow із random, short-lived та single-use token.

Пароль також не повинен потрапляти в logs, analytics, tracing або error reports. Правильний hash у database не виправить витік, що стався раніше в request pipeline.

Login response не має допомагати enumeration

Різні повідомлення або помітно різний час відповіді можуть показати, чи існує username. Системи часто виконують representative password hash навіть для невідомого account і повертають однаково нейтральну помилку. Rate limiting повинен враховувати account, network та ширші abuse signals.

Для comparison потрібно використовувати dedicated verify function із бібліотеки. Ручний parsing digest або звичайне порівняння створює timing і compatibility risks, які вже вирішені у зрілих реалізаціях.

Сильний hash лише купує час після breach

Жоден password hash не робить викрадену базу нешкідливою. Команда повинна знати алгоритм і параметри кожної групи accounts, уміти завершити активні sessions, примусити reset за потреби й пояснити користувачам ризик. Після витоку особливо важливий моніторинг credential stuffing.

MFA, passkeys, breached-password screening та password managers зменшують залежність від людської пам’яті. Проте доки паролі існують, їхнє зберігання залишається окремою security discipline: сучасний algorithm, унікальний salt, достатня вартість і заплановане оновлення.

Параметри потрібно перевіряти на production hardware

Cost settings не варто копіювати зі статті або іншого сервісу. Backend має виміряти типову й пікову тривалість verification на власних машинах, оцінити паралельні logins і залишити запас для навантаження. Надто слабкі параметри здешевлюють attack, а надто важкі можуть перетворити login endpoint на простий denial-of-service target.

Окремі класи пристроїв можуть мати різні обмеження, але server-side storage policy повинна залишатися централізованою. Регулярний benchmark допомагає підвищувати вартість поступово, без раптового погіршення доступності.

Зміна пароля повинна завершувати старі припущення

Після reset або добровільної зміни сервісу часто потрібно invalidate старі sessions, recovery links та remembered-device tokens. Інакше надійно захешований новий password не зупинить доступ через раніше викрадений session cookie.

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

Правила Unicode normalization також мають бути стабільними від реєстрації до входу. Непомітна зміна encoding або обробки пробілів може зробити правильний пароль непридатним, тому application повинна передавати бібліотеці послідовний набір bytes і не виконувати приховане «виправлення» секрету.