Ниже — сжатая, но полноценная сводка практик и рекомендаций по безопасному хранению паролей и аутентификации. Числа и параметры указаны в KaTeX.
1) Основы хранения паролей
- Хешируйте пароли обязательно (не шифруйте просто симметрично). Используйте адаптивные (slow) и memory‑hard алгоритмы.
- Всегда уникальная соль для каждой записи: соль длиной, например, $16$ байт, хранится рядом с хешем.
- Не используйте быстрые хеши (MD5, SHA‑1, SHA‑256 без KDF) для паролей.
- Сравнение хешей — в константное время.
2) Соли и «pepper»
- Соль: уникальная per‑user соль $16$ байт, хранится в БД.
- Pepper: серверный секрет (не в БД), опционально для защиты от компрометации БД; если используете — считайте её дополнительным входом к KDF и храните отдельно (HSM/secret manager).
3) Алгоритмы: что и когда выбирать
- Argon2id (рекомендуется для новых систем) — memory‑hard, защищает от GPU/ASIC:
- Рекомендуемые параметры: память $=65536$ KiB (то есть ~$64$ MiB), время $=3$, параллелизм $=1\dots 4$, длина вывода $=32$ байта.
- Выбор: когда можно контролировать рабочую нагрузку сервера и цель — максимальная защита против современных атак.
- PBKDF2‑HMAC‑SHA256 — широкая совместимость, аппаратно ускоряемый, годится если нужно совместимость/соответствие:
- Итерации: минимум $100000$ (реально — подбирать по времени).
- Выбор: когда требуется стандартизованное поведение, FIPS/legacy support или интеграция с оборудованием.
- bcrypt — устойчивая опция, хорошая совместимость, но не memory‑hard:
- Cost factor (work factor): например $12$.
- Выбор: если уже используется в проекте или нужна простота; для новых проектов предпочтительнее Argon2id.
- Не храните «хешированные» пароли вида HMAC(secret, password) вместо KDF — это не заменяет адаптивный KDF.
4) Параметры и тестирование
- Подберите параметры, чтобы хеширование занимало ощутимо (но приемлемо) время: например $100$—$500$ мс на целевом оборудовании.
- Регулярно пересматривайте параметры с ростом мощности атакующих.
- Храните метаданные алгоритма/параметров вместе с хешем, чтобы можно было менять алгоритм и ре‑хешировать.
5) Миграция старых хешей
- Ре‑хешируйте при следующем входе пользователя: если формат/параметры устарели, после успешной аутентификации вычислите новый хеш и сохраните.
- Отмечайте алгоритм (например, Argon2id vs bcrypt) в записи пользователя.
6) Многоуровневая аутентификация (MFA) и слоёвость
- MFA обязательно для критичных аккаунтов (админы, финансы, доступ к данным): TOTP, push‑approval, U2F/WebAuthn (аппаратные ключи).
- Рекомендации:
- TOTP: $6$ цифр, шаг $=30$ секунд.
- WebAuthn: предпочтительный метод для phishing‑resistant MFA (штука с аппаратными ключами).
- Слойность: пароль (что-то, что вы знаете) + второй фактор (что-то, что вы имеете/есть), с постепенным усилением для чувствительных операций (step‑up auth).
7) OAuth 2.0 / OpenID Connect — когда использовать
- Используйте OAuth2/OIDC когда:
- Нужно SSO/делегирование аутентификации (логин через Google, Microsoft и т.п.).
- Нужна централизованная идентификация и федерация (enterprise SSO).
- Клиентам нужно получать токены доступа/идентификации.
- Предупреждения:
- OAuth2 — протокол авторизации; OIDC добавляет идентификацию (ID token).
- Для публичных клиентов (SPA, мобильные) всегда использовать PKCE.
- Храните refresh token безопасно; используйте короткие access token (например время жизни $=$ $15$ минут) и безопасное обновление.
- Проверяйте подпись, audience, issuer, expiry при работе с JWT/ID‑token.
8) Сессионная и токен‑безопасность
- Access token lifetime: например $15$ минут; refresh token lifetime — в зависимости от риска (например $14$ дней) и с ротацией/отзывом.
- Сессии: HttpOnly, Secure, SameSite cookie; ограничение длины сессии и инвалидация при смене пароля.
9) Дополнительные меры
- Rate limiting, блокировки/экспоненциальная задержка и мониторинг попыток входа.
- Проверка пароля на компрометацию (Have I Been Pwned API/к‑безопасный k‑anonymity).
- Логирование аутентификаций и аномалий, alerting.
- Политика паролей: не навязывать экзотические требования; лучше поддерживать минимальную длину (рекомендуемая минимум $12$ символов) и encourage passphrases/manager.
- Рассмотрите passwordless (magic links + device bound keys, WebAuthn) для повышения безопасности и UX.
10) Итогно‑практическое правило выбора
- Новый проект с современной безопасностью: Argon2id + соль $16$ байт + optional pepper + MFA (WebAuthn/TOTP).
- Нужна совместимость/FIPS: PBKDF2 с высоким количеством итераций.
- Унаследованные системы с bcrypt — можно оставить, но планировать миграцию на Argon2id.
- Для SSO/федерации/логина через провайдеров — OAuth2 + OIDC с PKCE, короткими токенами и безопасной обработкой refresh.
Если нужно — могу дать конкретные команды/пример использования Argon2/PBKDF2 в вашем стеке (язык/фреймворк).