Реализация восстановления пароля на сайте: безопасный флоу

Проблема: типичные ошибки при реализации восстановления пароля

Стандартный флоу Forgot Password кажется простым: пользователь вводит email, получает ссылку, задаёт новый пароль. Но на практике разработчики допускают ошибки, которые приводят к уязвимостям: раскрытие факта регистрации, подбор токена, перебор rate limit. Мы настраиваем флоу на Laravel с использованием встроенного Password Broker: токен генерируется, хэшируется bcrypt и сохраняется в таблице password_resets с TTL 60 минут. Ответ на запрос восстановления одинаков для существующего и несуществующего email — злоумышленник не узнает, зарегистрирован ли пользователь. OWASP рекомендует bcrypt для хэширования токенов, и мы следуем этой практике.

Как работает флоу восстановления?

Пользователь отправляет POST-запрос на /forgot-password со своим email. Сервер создаёт токен, хэширует его и сохраняет в БД. Затем на email отправляется письмо со ссылкой вида https://example.com/reset-password?token=...&email=.... Пользователь переходит по ссылке, видит форму для нового пароля. После отправки POST /reset-password сервер верифицирует токен (сравнивает bcrypt-хэш), обновляет пароль и удаляет токен. Все активные сессии пользователя инвалидируются.

Какие уязвимости скрывает стандартная реализация?

Хранение токена в plaintext — реализация восстановления пароля

Если токен хранится в открытом виде, при утечке БД злоумышленник может сразу восстановить пароль любого пользователя. Мы используем bcrypt-хэш — даже скомпрометированная база не раскроет токены. bcrypt специально спроектирован для хэширования паролей: он медленный и включает соль. MD5 и SHA-1/2 позволяют перебрать миллионы комбинаций в секунду, а bcrypt замедляет перебор в 1000 раз, делая атаку непрактичной.

Отсутствие rate limiting

Без ограничения числа запросов злоумышленник может забросать сервер запросами на сброс, вызывая нагрузку на почтовый сервер. Мы устанавливаем лимит: не более 3 запросов в час с одного email или IP.

Одинаковый ответ для существующего и несуществующего email

Многие возвращают разные ошибки ("email не найден" vs "письмо отправлено"), что позволяет атакующему перебрать базу email. Наше решение всегда отвечает одинаково: "Если email зарегистрирован, письмо отправлено".

Почему bcrypt, а не MD5/SHA?

bcrypt специально спроектирован для хэширования паролей: он медленный и включает соль. MD5 и SHA-1/2 — быстрые хэши, которые позволяют злоумышленнику перебрать миллионы комбинаций в секунду. Bcrypt же замедляет перебор в 1000 раз и более, делая атаку непрактичной. Это значит, что наш подход с bcrypt в 1000 раз безопаснее хранения токена в открытом виде.

Как мы реализуем восстановление пароля под ключ

Мы используем Laravel Password Broker, который предоставляет готовые методы для генерации, проверки и удаления токенов. Пример контроллера:

use Illuminate\Support\Facades\Password;

class ForgotPasswordController extends Controller
{
    public function __invoke(Request $request)
    {
        $request->validate(['email' => 'required|email']);
        
        $status = Password::sendResetLink($request->only('email'));
        
        return $status === Password::RESET_LINK_SENT
            ? back()->with(['status' => __($status)])
            : back()->withErrors(['email' => __($status)]);
    }
}

Для сброса пароля используем Password::reset().

Хранение токенов: таблица password_resets с полями email, token (bcrypt), created_at. Токен живёт 60 минут, после чего удаляется через cron или garbage collection. Пример таблицы:

Благодаря bcrypt даже при утечке БД токены не расшифровать — это в 1000 раз безопаснее plaintext.

Типичные ошибки при реализации

• Хранение токена в plaintext
• Отсутствие rate limiting
• Разные ответы для существующих/несуществующих email
• Отсутствие инвалидации сессий после смены пароля
• Слишком долгий TTL токена (больше 1 часа)

Сравнение подходов для надёжности

Наш подход — оптимальный баланс безопасности и простоты поддержки. JWT с коротким TTL требует дополнительной инфраструктуры и не защищает от утечки токена, если секретный ключ скомпрометирован. Сертифицированные инженеры гарантируют качество реализации.

Процесс работы

1. Анализ текущей системы аутентификации и выявление рисков.
2. Проектирование флоу: endpoints, валидация, rate limiting.
3. Реализация контроллеров, миграции, кастомного шаблона письма.
4. Тестирование: unit-тесты на сброс и восстановление, интеграционные тесты на rate limiting.
5. Деплой и мониторинг.

Сроки и что входит

Обычно реализация занимает 1–2 рабочих дня. Входит:

• Кастомный контроллер и маршруты
• Миграция для таблицы password_resets
• Кастомный шаблон письма (HTML+текст)
• Rate limiting (3 запроса/час на email)
• Инвалидация сессий при смене пароля
• Тесты и документация

Мы имеем многолетний опыт и выполнили более 30 проектов по аутентификации. Получите консультацию — оценим ваш проект бесплатно. Закажите внедрение безопасного восстановления пароля под ключ — свяжитесь с нами.

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует, что payload не изменён. Без проверки подписи — это просто base64-encoded JSON, который любой может подделать.

Ошибки, которые видим в коде регулярно:

Хранение в localStorage. localStorage доступен любому JS на странице — XSS атака читает токен и отправляет на сервер злоумышленника. Access token в памяти (переменная модуля), refresh token в httpOnly cookie — правильная схема.

Долгоживущие access-токены. Access token на 7 дней без возможности отзыва. Утёк — 7 дней доступа. Стандарт: 15 минут для access token, 30 дней для refresh token с ротацией. При каждом использовании refresh token выдаётся новый, старый инвалидируется — если старый кто-то использует повторно, это детектируется как Token Reuse Attack, вся семья токенов отзывается.

Хранение секретных данных в payload. JWT payload не зашифрован, только подписан — его видно в base64. Пароли, платёжные данные, личная информация — не в JWT.

Алгоритм RS256 (асимметричный) предпочтительнее HS256 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, который добавляет id_token с данными пользователя.

Authorization Code Flow с PKCE — единственный правильный flow для браузерных SPA и мобильных приложений. Implicit Flow устарел и небезопасен. PKCE (Proof Key for Code Exchange) защищает от перехвата authorization code.

Реализация OAuth сервера: не пишем с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Laravel Passport или Laravel Sanctum для серверных приложений. NextAuth.js для Next.js — поддерживает 50+ провайдеров из коробки.

Для B2B продуктов с корпоративными клиентами — SAML 2.0 SSO. Корпоративные IT-отделы часто требуют его вместо OAuth. @boxyhq/saml-jackson — node.js библиотека для SAML → OAuth2 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

Для большинства веб-приложений сессии проще и безопаснее. JWT имеет смысл для API, потребляемых из мобильного приложения, и для микросервисной архитектуры.

RBAC и политики доступа

Role-Based Access Control — у пользователя есть роли, у ролей — права. Простая реализация: user → roles → permissions. Но как только появляется ресурсная авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и права, кэширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов: пользователя, ресурса, окружения. Нужен когда правила доступа сложные: «менеджер может просматривать заказы своего региона, если заказ создан более 24 часов назад». Casbin — популярная cross-language библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ определяется графом отношений: «пользователь X является участником команды Y, которая имеет доступ к проекту Z». OpenFGA — open source реализация от Okta.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Самая распространённая уязвимость API по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Небезопасный CORS: Access-Control-Allow-Origin: * на API с авторизацией по cookie — credentials не передаются с wildcard origin, но если кто-то сделал Allow-Credentials: true + Allow-Origin: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.