Храните не пароль, а результат специализированного хеширования вместе с солью, алгоритмом и параметрами. Для новой системы предпочтителен Argon2id через проверенную библиотеку. Стоимость подбирают по ресурсам и нагрузке; при входе используют штатную проверку и при необходимости обновляют хеш. У bcrypt лимит 72 байта, а не символа. Соль не секретна; pepper, если применяется, хранится отдельно.
Как безопасно хранить пароли пользователей при локальной аутентификации?
Специализированное парольное хеширование, случайная соль, параметры стоимости и миграция. Почему bcrypt ограничен 72 байтами и не является первым выбором.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Для локальной аутентификации нужно проверить введённый пароль, а не восстановить сохранённый. Поэтому основной механизм — специализированное парольное хеширование, а не открытый текст, обратимое шифрование или быстрый SHA-256 без подходящей схемы.
Для новой системы предпочтителен Argon2id через проверенную библиотеку. Настраиваются память, число проходов и параллелизм; стоимость выбирают с учётом оборудования, допустимой задержки и одновременных попыток входа. Следует ограничивать нагрузку на аутентификацию, чтобы дорогая проверка сама не стала причиной отказа в обслуживании. Рекомендации приведены в OWASP Password Storage.
При создании или смене пароля библиотека должна получать криптографически случайную соль для новой записи. В базе сохраняют результат, соль, идентификатор алгоритма, версию и параметры стоимости; часто они уже объединены в стандартной строке. Соль не требуется прятать. Не генерируйте другую соль для сравнения: штатная функция проверки использует сохранённые параметры.
bcrypt допустим для существующих систем, но имеет ограничение 72 байта, не 72 символа. Например, GenerateFromPassword в Go bcrypt возвращает ошибку для более длинного входа. Нельзя молча обрезать пароль; ошибки обработки и настройки стоимости необходимо учитывать. Значение DefaultCost не заменяет оценку нагрузки.
После успешной проверки можно пересчитать пароль по новой политике и заменить старую запись. При использовании дополнительного pepper его держат вне базы, с управлением доступом и планом замены.
Наконец, ограничивают доступ к базе и резервным копиям, исключают пароли из журналов. Даже качественный хеш не гарантирует невозможность подбора слабого пароля.