Безопасность
Хеширование паролей: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Каждый отражает реальное решение — что отправить в код регистрации, как читать утечку, какую ручку покрутить — а не определение для заучивания.
Убедись, что связываешь модель угроз (офлайн-перебор), защиты (медленный + с salt + memory-hard), именованные параметры и production-ловушки — тот синтез, к которому вёл урок.
Таблица users утекла, пароли хранились как sha256(salt + password), salt уникален на пользователя. Насколько всё плохо?
Коллега предлагает и salt, и pepper. Где живёт каждый и зачем оба?
Почему memory-hardness (Argon2id, scrypt) важнее против реального атакующего, чем просто сырая медленность по CPU (например, PBKDF2 с большим числом итераций)?
Нужно хранить пароли в новом коде без FIPS-ограничений. Какой выбор и параметры?
Отчёт об обходе аутентификации: две разные длинные парольные фразы пускают в один аккаунт, обе хранятся через bcrypt. Корневая причина?
Твои параметры Argon2id настроены в 2020 на ~250 мс. Спустя годы ревью их помечает. Какова стандартная миграция и как сравнивать хеши при входе?
Сквозная линия — одна модель угроз и один стек защиты. Атака — офлайн-перебор: утёкшая колонка хешей гоняется на полной скорости железа (~22 миллиарда SHA-256/с на GPU), что делает любой быстрый хеш неверным инструментом. Защита — медленный + с salt + memory-hard: salt на пользователя (не секретный, рядом с хешем) убивает rainbow tables, проверенный KDF с именованными параметрами (Argon2id m=19 MiB/t=2/p=1 предпочтителен, bcrypt cost 10+ или scrypt N=2^17 приемлемы, PBKDF2 только под FIPS), опциональный pepper вне БД, work factor, поднимаемый по расписанию через rehash-on-login, и constant-time verify библиотеки вместо самопального сравнения. Следи за ловушкой обрезки 72 байт в bcrypt.