Хэширование паролей (bcrypt, Argon2)
Тема дорожной карты · Backend разработчик
Безопасность паролей — это совокупность бэкенд-практик, обеспечивающих хранение, передачу и валидацию паролей пользователей таким образом, чтобы предотвратить их утечку даже при компрометации базы данных. Пароли нельзя хранить в открытом виде или шифровать обратимыми алгоритмами; вместо этого они должны хэшироваться медленным адаптивным алгоритмом, предназначенным для хранения паролей: bcrypt (work factor ≥ 12), Argon2id (рекомендованный OWASP вариант) или scrypt — все они автоматически включают соль на пользователя, нейтрализуя атаки по радужным таблицам. В Node.js пакет bcrypt предоставляет bcrypt.hash(password, 12) и bcrypt.compare(input, hash), тогда как в Python библиотека passlib с CryptContext и схемой argon2 обеспечивает те же абстракции. Безопасность паролей охватывает и безопасность передачи — учётные данные должны передаваться только через TLS (HTTPS), никогда в строках запроса URL, — а также политику ввода: минимальная длина (NIST SP 800-63B рекомендует не менее 8 символов, допускайте до 64 и более), проверка по базам утёкших паролей через k-Anonymity API HaveIBeenPwned, и блокировка аккаунта или экспоненциальная задержка после повторных неудачных попыток. Многофакторная аутентификация (TOTP через speakeasy или pyotp, WebAuthn/FIDO2) существенно усиливает безопасность паролей, гарантируя, что одного утёкшего хэша недостаточно для захвата аккаунта.
Как это работает
Хэширование паролей (bcrypt, Argon2) включает аутентификацию (кто вы?) и авторизацию (что можете?). Современная auth: OAuth 2.0 + OpenID Connect для делегированной identity, session-куки для традиционных веб-приложений, JWT для stateless distributed-систем. Пароли всегда хешируйте через bcrypt или argon2id. CSRF-защита на state-changing endpoints; CORS осознанно (не * в production). Авторизация: RBAC (роли), ABAC (атрибуты), policy engines (OPA, Casbin). MFA/2FA для любой привилегированной операции.
Когда применять
Session-куки — для монолитных веб-приложений (HttpOnly + Secure + SameSite=Lax): проще, отзываемо, server-side state. JWT — только когда реально нужна stateless distributed-валидация; иначе session безопаснее. Identity отдавайте провайдеру (Yandex ID, Keycloak, Auth0, Authentik) — DIY identity = место утечек. Rate-limit на auth-endpoints с первого дня.
Типичные ошибки
Ловушки Хэширование паролей (bcrypt, Argon2): пароли через MD5/SHA1/SHA256 (быстро, brute-force-friendly — используйте argon2id); JWT-секрет в клиентском коде или git-history; JWT без expiry или revocation list (потерянный девайс = пожизненный доступ к аккаунту); своя крипта (используйте библиотеки); admin-endpoints без auth "потому что internal" (внутренняя сеть не граница безопасности). Регулярные auth-аудиты.