Реализация безопасной аутентификации по логину и паролю

Однажды наш клиент, финтех-стартап, потерял доступ к панели администрирования: злоумышленник перехватил сессию через незащищённый HTTP, и пароль администратора хранился в MD5. Восстановление заняло двое суток, а утечка данных клиентов обошлась в 2 млн рублей компенсаций. Такие инциденты — результат типовых ошибок: слабое хэширование, отсутствие rate limiting и неправильное управление сессиями. Мы разрабатываем систему входа с многоуровневой защитой, предотвращающую атаки на авторизацию. Наш опыт — 10+ лет в веб-безопасности, 50+ проектов для fintech, medtech и e-commerce, где данные — главный актив.

Какие угрозы мы закрываем?

• Брутфорс: автоматизированный перебор паролей. Без rate limiting злоумышленник может отправить 10 000 запросов в час. Мы ограничиваем до 5 попыток в минуту с одного IP, после 10 неудач — блокировка на 15 минут.
• Слабое хэширование: MD5/SHA-1 без соли взламываются за секунды на GPU. Мы используем bcrypt (cost=12) или Argon2id (t=3, m=1GB) — оба устойчивы к радужным таблицам и parallel-атакам.
• Межсайтовая подделка запроса (CSRF): каждая форма входа защищена токеном. Laravel генерирует CSRF-токен автоматически при @csrf.
• Перехват сессии: только HTTPS, Set-Cookie с флагами Secure, HttpOnly и SameSite=Lax.

Как мы защищаем пароль при хранении?

Пароль никогда не хранится в открытом виде. Используем bcrypt с cost factor ≥ 12 или Argon2id. Нельзя применять устаревшие алгоритмы вроде MD5 или SHA-1 без соли: они взламываются за минуты на обычном GPU. Bcrypt намеренно медленный: cost=12 даёт время хэширования около 100 мс, что сильно затрудняет брутфорс. Argon2id — победитель конкурса PHC, устойчив к атакам по времени и параллельным вычислениям.

// Laravel
$hash = Hash::make($password); // bcrypt, cost=12 по умолчанию

// Верификация
if (!Hash::check($request->password, $user->password)) {
    throw new AuthenticationException();
}

// Проверка необходимости rehash (при смене cost factor)
if (Hash::needsRehash($user->password)) {
    $user->update(['password' => Hash::make($password)]);
}

Сравнение алгоритмов:

Почему rate limiting необходим?

Без ограничения числа попыток злоумышленник может перебрать миллионы комбинаций за день. Мы внедряем rate limiting на уровне приложения и веб-сервера. Настройка в Laravel:

// Laravel — через RateLimiter
RateLimiter::for('login', function (Request $request) {
    return Limit::perMinute(5)->by($request->ip())
        ->response(fn() => response()->json([
            'message' => 'Слишком много попыток. Повторите через 60 секунд.'
        ], 429));
});

// Дополнительно — блокировка по email+IP на 15 минут после 10 неудачных попыток

Такая мера предотвращает брутфорс-атаки и снижает нагрузку на сервер. Мы также добавляем защиту через капчу после 3 неудачных попыток. Рекомендации OWASP подтверждают эффективность такого подхода.

Как мы реализуем Remember me?

Функция «Запомнить меня» требует осторожного подхода. Нельзя просто хранить токен в plain text. Мы генерируем 60-символьный случайный токен, сохраняем его SHA-256 хеш в БД с датой истечения 30 дней.

// Создание долгоживущего токена
if ($request->boolean('remember')) {
    $token = Str::random(60);
    $user->update([
        'remember_token' => hash('sha256', $token),
        'remember_token_expires_at' => now()->addDays(30),
    ]);
    Cookie::queue('remember_token', $token, 60 * 24 * 30, secure: true, httpOnly: true);
}

Токен привязывается к IP и User-Agent — при смене параметров сессия сбрасывается.

JWT vs сессии: что лучше и когда?

Для серверного рендеринга (SSR, MPA) — стандартные cookie-сессии. Для SPA и мобильных клиентов — JWT (access + refresh). JWT в SPA работает быстрее по времени авторизации благодаря отсутствию серверного состояния.

Безопасность формы

• autocomplete="current-password" — корректный атрибут для менеджеров паролей
• CSRF-токен в POST-запросе
• Одинаковое сообщение об ошибке для «нет пользователя» и «неверный пароль» — не раскрываем факт существования аккаунта
• HTTPS обязателен по рекомендациям OWASP

Что входит в работу

• Аудит текущей архитектуры аутентификации и выявление уязвимостей
• Проектирование схемы хэширования, rate limiting, управления сессиями
• Реализация кода с интеграцией выбранных алгоритмов и токенов
• Предоставление документации по архитектуре и инструкции для администраторов
• Обучение команды основам безопасной аутентификации
• Техническая поддержка в течение месяца после деплоя

Наш процесс работы

1. Анализ: аудит текущей архитектуры, выявление уязвимостей (типа протокола, алгоритмов, конфигурации сессий).
2. Проектирование: выбор стека (Laravel/Firebase Auth), разработка схемы аутентификации, согласование с нагрузочным профилем.
3. Реализация: написание кода с интеграцией хэширования, rate limiting, токенов. Unit и integration тесты покрывают критичные сценарии.
4. Тестирование: проникновение (pen test) с имитацией атак (brute force, CSRF, session hijacking). Нагрузочное тестирование до 10 000 одновременных запросов.
5. Деплой: настройка CI/CD, мониторинг метрик безопасности (количество неудачных входов, блокировки).

Сроки и стоимость

Базовая реализация логина/пароля с rate limiting, сессиями и remember me — от 2 до 5 рабочих дней. Стоимость рассчитывается индивидуально в зависимости от сложности и стека. Средний ущерб от утечки данных по статистике IBM — 4.24 млн долларов, поэтому вложения в безопасную аутентификацию окупаются многократно. Закажите реализацию под ключ — свяжитесь с нами для оценки вашего проекта. Мы гарантируем надёжность и конфиденциальность.

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

Аутентификация и авторизация: 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 недель.