Надёжный способы хранения пароля

Ниже подробное руководство по надёжному хранению паролей. Так как предмет и класс не указаны, подойдёт общий подход средней школы и современным требованиям к безопасности.

1. Основной принцип

• Никогда не храните пароли в явном виде.
• Храните только результат применения надёжной функции хэширования к паролю, с солью и (по желанию) секретным элементом под названием pepper.
• Хэш должен быть «трудным» для подбора: занять разумное время даже на мощном устройстве.

2. Что выбрать для хранения паролей

• Рекомендуется современная функция/алгоритм подстановки ключей (key derivation function, KDF):
  • Argon2id (самый современный и рекомендуемый для новых систем)
  • bcrypt (устойчивый и широко поддерживаемый)
  • scrypt (ещё хороший вариант)
• Встроить в процесс и соль, и параметры работы так, чтобы они повторялись при проверке пароля.

3. Соль и pepper

• Соль (salt): случайная строка, уникальная для каждого пользователя. Длина обычно 16–32 байта. Соль хранится вместе с хэшем.
• Pepper: секретное значение, которое не сохраняется в базе данных. Обычно хранится в конфигурации сервера или в секретном хранилище. Применяется ко всем паролям на входе (например, добавляется к паролю перед хэшированием). Если база данных с хэшами взломана, pepper остаётся секретным фактором. Примечание: pepper не обязателен; его использование усложняет взлом, но требует надёжного хранения секрета.

4. Параметры работы хэширования

• Для Argon2id: задаются memory_cost (память), time_cost (число проходов), parallelism (потоки).
• Для bcrypt: rounds (уровень затрат, например 12).
• Цель: чтобы вычисление хэша занимало на сервере порядка 100–200 мс на вашей аппаратуре. При этом злоумышленник не получает возможность быстро перебором паролей.
• Важно: менять параметры по мере роста мощности оборудования (реха́шивание). При входе новых пользователей можно выбрать более строгие параметры; когда нужно — мигрировать существующие хэши с более низкими параметрами на новые.

5. Как хранить данные Структура базы данных должна сохранять:

• идентификатор пользователя (или логин)
• сам хэш (включая параметры и соль в закодированном виде)
• соль (если алгорит не инкапсулирует её внутри хэша)
• параметры алгоритма/версии (или всё это хранить внутри закодированной строки хэша)
• статус pepper’а (если вы храните отдельный pepper, храните его версию/идентификатор; на практике pepper хранится отдельно от БД и применяется на уровне приложения)

Примерная схема:

• user_id
• password_hash (строка, содержащая соль, параметры и сам хэш; например, в bcrypt/Argon2 это закодированная строка)
• algorithm_version (если нужно поддерживать миграцию)
• salt (если используете отдельную соль)
• pepper_id или no_pepper (если pepper используется)

6. Как проверять пароль

• Получить сохранённый хэш для пользователя.
• Использовать ту же функцию хэширования с теми же параметрами и той же солью.
• Применить pepper, если он используется.
• Сравнить вычисленный хэш с сохранённым. Никаких «обходов» по времени — сравнение должно быть безопасным (constant-time).

7. Рекомендованные практики и советы

• Используйте современный, поддерживаемый алгоритм (Argon2id или bcrypt). Не пишите свою криптографическую схему с нуля.
• Всегда используйте соль. Без соли одинаковые пароли будут давать одинаковые хэши, что облегчает атаки.
• Не храните пароли в базе в явном виде, не шифруйте их «для защиты» простыми шифрами, не пытайтесь «зашифровать» самим способом.
• Защитите окружение: TLS для передачи паролей, минимальные привилегии для сервисов, аудит доступа, регулярные обновления.
• Внедрите MFA (многофакторная аутентификация) для дополнительной защиты.
• Реализуйте безопасную процедуру сброса пароля (одновременная отправка одноразового кода, истечение срока действия, лимит попыток).
• Регулярно проводите аудит безопасности и, если возможно, внешнюю экспертизу кода.
• Для серьёзной защиты можно использовать pepper и хранение его в секретном хранилище (KMS, Vault и т. п.) вне базы данных.

8. Пример реализации (упрощённо) Пример 1: Argon2id (модульная реализация)

• Выбор параметров: memory_cost = 100000 (килобайт), time_cost = 2, parallelism = 4, hash_len = 32
• Генерация соли и вычисление хэша: база сохраняет строку хэша, которая уже содержит соль и параметры (обычно это делает библиотека)
• Проверка пароля: взять сохранённую строку хэша, передать пароль — библиотека сравнит и вернёт результат

Пример 2: bcrypt (устойчивость и простота)

• salt = gensalt(rounds=12)
• hash = hashpw(password, salt)
• В БД сохраняем hash (строка). При входе: compare password с сохранённым hash через checkpw

Пример 3: псевдокод без зависимости от языка

• При регистрации:
  • salt = случайная_строка(16–32 байта)
  • если есть pepper: пароль = пароль + pepper
  • hash = KDF(пароль, salt, параметры)
  • сохранить (пользователь, hash, salt, параметры)
• При входе:
  • взять salt и параметры по пользователю
  • если есть pepper: пароль = введённый пароль + pepper
  • проверить: KDF(пароль, salt, параметры) == сохранённый hash
  • если совпало — авторизовать

9. Быстрые примечания

• Если ваш стек технологий поддерживает встроенный Argon2id или bcrypt, рекомендуется использовать именно их, а не придумывать свой алгоритм.
• Pepper не обязателен, но повышает безопасность в случае утечки БД. При использовании держите pepper в окружении сервера и обновляйте его своевременно.
• Регулярно тестируйте процесс восстановления пароля и работу миграций хэшей при обновлении параметров.

Если хочешь, могу адаптировать рекомендацию под конкретный язык программирования или стек технологий (например, Python+Django/Flask, Node.js, Java, Go) и привести конкретные фрагменты кода с настройками параметров.