awesome-everything EN
↑ Обратно к восхождению

Безопасность

Хеширование паролей: построй миграционно-безопасное хранилище auth

Суть Практический проект — построй слой хранения паролей на Argon2id с миграцией rehash-on-login, внешним pepper и timing-safe verify, затем докажи каждое свойство тестами и бенчмарком.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбите
◷ 220 min

Читать про хеширование паролей — не то же, что отправить хранилище auth, переживающее утечку и десятилетие железа. Построй небольшой слой учётных данных, засей его намеренно слабой legacy-схемой, затем мигрируй на Argon2id прозрачно — доказывая каждое свойство тестами и бенчмарком, а не утверждениями.

Цель

Преврати модель юнита в рабочее, миграционно-безопасное хранилище паролей: проверенный memory-hard KDF с настроенными параметрами, внешний pepper, constant-time verify и путь rehash-on-login, обновляющий и legacy-хеши, и устаревшие work factor без принудительных сбросов.

Проект
0 из 7
Цель

Построй модуль хранения паролей (Go, Node или твой стек), который хеширует через Argon2id с параметрами OWASP, peppers вне БД, проверяет за постоянное время и прозрачно мигрирует legacy и устаревшие хеши при входе — затем докажи каждое свойство автоматическими тестами и бенчмарком настройки.

Требования
Критерии приёмки
  • Набор тестов, доказывающий: одинаковые пароли дают разные хеши (salt работает); неверный пароль не проходит; верный пароль проходит; и verify корректно диспетчеризуется по строкам sha256, bcrypt и Argon2id.
  • Тест миграции: вход legacy-пользователя (sha256 и bcrypt) обновляет хранимый хеш до Argon2id на месте, и последующий вход проходит против нового хеша — без сброса пароля.
  • Тест pepper, показывающий, что хеш, созданный с pepper, не проходит verify после смены или удаления pepper, демонстрируя defense-in-depth через внешний секрет.
  • Вывод бенчмарка (числа, не оценки), показывающий задержку одного хеша в целевом диапазоне при выбранных параметрах Argon2id, плюс абзац о том, как ты будешь поднимать work factor по мере улучшения железа.
Senior-стретч
  • Добавь runbook реагирования на утечку: ротация pepper, форсирование rehash при следующем входе и (раз хеши медленные + с salt + с pepper) решение, нужен ли вообще принудительный сброс — с записанным обоснованием.
  • Добавь шаг самокалибровки параметров Argon2id, измеряющий пропускную способность хоста при старте и подбирающий memory/time cost под целевую задержку автоматически, логируя выбранные значения.
  • Добавь крошечную демонстрацию стоимости взлома: захешируй небольшой словарь под sha256 vs Argon2id и сообщи разницу по wall-clock на N попыток, делая разрыв пропускной способности наглядным.
  • Подключи защиту от denial-of-service на стороне входа: ограничь число одновременных Argon2id-хешей (каждый стоит 19 MiB), чтобы поток попыток входа не исчерпал память, и покажи, что лимит держится под всплеском.
Итог

Это цикл за каждым реальным хранилищем auth: хешируй проверенным memory-hard KDF с именованными параметрами OWASP, держи pepper вне базы ради defense-in-depth, проверяй за постоянное время и мигрируй legacy-схемы и устаревшие work factor прозрачно при входе, чтобы таблица обновляла себя сама без принудительных сбросов — охраняя по пути ловушку 72 байт у bcrypt. Доказательство каждого свойства тестами и бенчмарком на небольшом хранилище делает production-версию мышечной памятью и даёт ответ на день утечки до самой утечки.

Продолжить восхождение ↑Управление секретами: почему ключ в git — это уже взлом
хоткеи развернуть
поиск
K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources2
expand
  1. 01
  2. 02

Trademarks belong to their respective owners. Editorial reference only.