Безопасность
Хеширование паролей: свободное припоминание
Припоминание сильнее перечитывания. На каждый промпт проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет материал.
Восстанови ключевые механизмы юнита — почему быстрые хеши проигрывают, что делают salt и pepper по отдельности, почему memory-hardness бьёт сырую медленность, как мигрирует work factor и почему нельзя писать своё сравнение — не подглядывая в урок.
- 01Почему быстрый универсальный хеш вроде SHA-256 — неверный инструмент для хранения паролей, даже с salt на пользователя?
- 02В чём разница между salt и pepper и где живёт каждый?
- 03Почему memory-hardness калечит атакующего сильнее, чем простое повышение числа итераций по CPU?
- 04Назови три принятых современных алгоритма с параметрами OWASP и скажи, когда PBKDF2 — правильный выбор.
- 05Что такое ловушка 72 байт у bcrypt, как она вызывала реальные обходы аутентификации и каков правильный фикс?
- 06Как держать work factor актуальным со временем и почему сравнение паролей должно быть constant-time?
Если ты смог восстановить каждый ответ по памяти, у тебя есть хребет юнита: защищаемая атака — офлайн-перебор на полной скорости железа, что делает быстрые хеши неверным инструментом; salt на пользователя (открытый, в строке) убивает rainbow tables, а pepper (секретный, вне БД) защищает от утечки только БД; memory-hardness бьёт сырую медленность, атакуя параллелизм GPU; принятые алгоритмы — Argon2id (предпочтителен), scrypt и bcrypt (а PBKDF2 только под FIPS), каждый с именованными параметрами OWASP; обрезка 72 байт у bcrypt — реальная ловушка; а work factor поднимается по расписанию через rehash-on-login, со сравнением, выполняемым библиотекой за постоянное время, никогда руками.