password••••••••Argon2id+salt + cost$argon2id$v=19$m=...$Tk7e...slow, memory-hard, one-way

Хешування пароля

11 хв. читанняКриптографія

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

Повний текст статті подано англійською мовою нижче.

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

Це теорія. Практика варіюється від «працює, як рекламується» до «може бути відкритим текстом», залежно від того, який алгоритм і параметри було вибрано.

Що потрібно для хорошого хешу пароля

  • Односторонній. Знання хешу не повинно розкрити нічого корисного про password.
  • Salted. Кожен користувач має унікальну випадкову сіль, домішану в хеш. Запобігає створенню попередньо обчислених райдужних таблиць і гарантує, що ідентичні паролі створюють різні хеші.
  • Slow. Обчислення одного хешу повинно зайняти значну частку секунди на апаратному забезпеченні зловмисника. Груба сила з мільярдами за секунду — це те, що перемагає швидкі хеші.
  • Пам’ять-hard. Кожен хеш має вимагати значного обсягу оперативної пам’яті, перемагаючи розпаралелювання графічного процесора та ASIC, яке процвітає на невеликій пам’яті для кожного екземпляра. налаштовується вгору, оскільки апаратне забезпечення стає швидшим.

Неправильний вибір

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

  • MD5. Криптографічно зламано з 2004 року. Можливість грубого примусу з десятками мільярдів хешів на секунду на споживчому обладнанні.
  • SHA-1, SHA-256. Швидкі криптографічні хеші, призначені для перевірки цілісності, а не для зберігання паролів. Груба форсування зі швидкістю мільярдів за секунду на графічних процесорах.
  • Зашифровані паролі. Якщо ви можете розшифрувати їх у відкритий текст, зловмисник, який вкраде ключ, теж зможе. Хешування - відповідь; шифрування не є.
  • Plaintext. Все ще трапляється в 2026 році. Кожен злам пароля відкритого тексту є технікою, якій можна запобігти.

Правильний вибір

Три сучасні рекомендовані алгоритми:

  • bcrypt (1999). Регульований коефіцієнт витрат (раунди обчислень). Обмежено 72-байтними паролями. Не потребує пам’яті, тому графічні процесори можуть ефективно атакувати її, але розумна ціна все одно робить атаки дорогими. Широке розгортання, простий у правильному використанні.
  • scrypt (2009). Важка пам'ять. Конфігурована вартість пам'яті, паралелізм і вартість ЦП. Більш складний, ніж bcrypt; іноді неправильно налаштований.
  • Argon2 (переможець конкурсу хешування паролів 2015 р.). Три варіанти: Argon2d (залежний від даних, стійкий до атак GPU, але вразливий до бічних каналів), Argon2i (незалежний від даних, стійкий до бічних каналів), Argon2id (гібридний — рекомендоване значення за замовчуванням). Сучасний, добре перевірений, правильний вибір для нових систем.

OWASP наразі рекомендує Argon2id із принаймні 19 МБ пам’яті, кількістю ітерацій 2 і паралелізмом 1. Для систем, де Argon2 недоступний, прийнятними є bcrypt із вартістю ≥ 10 або scrypt із відповідними параметрами. запасні варіанти.

Що означає «повільний» на практиці

Коефіцієнт вартості 10 у bcrypt означає приблизно 100 мс на хеш на сучасному обладнанні. Для законного користувача, який входить в систему, це непомітно. Для зловмисника, який намагається підібрати 100 мільйонів паролів із витоку бази даних, це 100 мільйонів × 100 мс = 116 днів часу графічного процесора на прохід через розумний список слів. У поєднанні з унікальною сіллю для кожного користувача великі райдужні таблиці марні.

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

Обробка солі

  • Salt призначено для кожного користувача, генерується CSPRNG у користувача створення
  • 16 байт достатньо (128 біт випадковості)
  • Salt зберігається разом із хешем, не є секретом — його завдання полягає в тому, щоб бути унікальним, а не прихованим
  • Більшість сучасних бібліотек хешування (bcrypt, Argon2 виводить у формат рядка PHC) об’єднує алгоритм, параметри, сіль і хеш в єдиний string

Pepper: необов’язковий extra

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

Безпечне оновлення хешів

Коли ви змінюєте параметри або мігруєте алгоритми, ви не можете повторно хешувати без вихідного пароля. Стандартний підхід:

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

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

Що це означає для користувачів

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

Часті запитання

Чому bcrypt обмежений 72 символами?
Історична інформація про впровадження основного шифру Blowfish. Довші вхідні дані скорочуються. Більшість користувачів не помічають; випадкова парольна фраза з 16 символів значно нижча за ліміт. Для систем, яким потрібна необмежена довжина пароля, Argon2 не має такого обмеження.
Чи варто солити й перчити паролі?
Сіль потрібна (і будь-яка авторитетна бібліотека робить це автоматично). Перець є необов’язковим, але цінним для систем високого рівня безпеки. Компроміс: керування перцем як довгостроковим секретом поза базою даних ускладнює роботу. Більшість додатків зберігають сіль + хеш; найбільші зберігають сіль + гашиш + хашиш, отриманий з перцю.
Чи завжди Argon2 кращий за bcrypt?
Для нових систем, так. Argon2 не потребує пам’яті (стійкий до GPU/ASIC), не має обмеження на 72 символи та виграв конкурс хешування паролів з поважних причин. bcrypt все ще прийнятний, якщо Argon2 недоступний або організаційні обмеження віддають перевагу старішому стандарту. Для застарілих систем, які використовують bcrypt із вартістю ≥ 10, терміновість міграції низька.
Скільки часу потрібно для хешування пароля?
OWASP пропонує приблизно 100-500 мс на апаратному забезпеченні сервера. Швидше означає слабше проти зловмисників; повільніше починає впливати на законний досвід входу. Правильне число залежить від вашого трафіку — послуги великого обсягу вибирають нижчу вартість; служби високого рівня безпеки з низькою швидкістю входу в систему можна вибрати вищу.
Чи можу я зберігати зашифровані паролі замість хешованих?
не треба Шифрування оборотне, що означає, що ключ шифрування має бути десь доступним для програми. Якщо базу даних зламано, ключ часто також, і ви фактично зберегли відкритий текст. Справа в незворотності хешування — навіть ваша власна програма не може відновити пароль, що є властивістю безпеки.
Пояснення хешування пароля: чому bcrypt, scrypt і Argon2 важливі