Однажды наш клиент, финтех-стартап, потерял доступ к панели администрирования: злоумышленник перехватил сессию через незащищённый 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)]); } Сравнение алгоритмов:
| Алгоритм | Устойчивость | Скорость хэширования | Рекомендации |
|---|---|---|---|
| bcrypt | Высокая (до 2^24 раундов) | ~100 ms (cost=12) | Хорош для legacy-систем |
| Argon2id | Очень высокая (защита от GPU) | ~150 ms (t=3,m=1GB) | Рекомендован OWASP |
Почему 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 работает быстрее по времени авторизации благодаря отсутствию серверного состояния.
| Подход | Когда использовать |
|---|---|
| Cookie-сессии | Laravel Blade, серверный рендеринг |
| JWT | SPA (React/Vue), мобильные API |
| Sanctum (Laravel) | SPA на том же домене |
| Passport (Laravel) | OAuth2 сервер, сторонние клиенты |
Безопасность формы
-
autocomplete="current-password"— корректный атрибут для менеджеров паролей - CSRF-токен в POST-запросе
- Одинаковое сообщение об ошибке для «нет пользователя» и «неверный пароль» — не раскрываем факт существования аккаунта
- HTTPS обязателен по рекомендациям OWASP
Что входит в работу
- Аудит текущей архитектуры аутентификации и выявление уязвимостей
- Проектирование схемы хэширования, rate limiting, управления сессиями
- Реализация кода с интеграцией выбранных алгоритмов и токенов
- Предоставление документации по архитектуре и инструкции для администраторов
- Обучение команды основам безопасной аутентификации
- Техническая поддержка в течение месяца после деплоя
Наш процесс работы
- Анализ: аудит текущей архитектуры, выявление уязвимостей (типа протокола, алгоритмов, конфигурации сессий).
- Проектирование: выбор стека (Laravel/Firebase Auth), разработка схемы аутентификации, согласование с нагрузочным профилем.
- Реализация: написание кода с интеграцией хэширования, rate limiting, токенов. Unit и integration тесты покрывают критичные сценарии.
- Тестирование: проникновение (pen test) с имитацией атак (brute force, CSRF, session hijacking). Нагрузочное тестирование до 10 000 одновременных запросов.
- Деплой: настройка CI/CD, мониторинг метрик безопасности (количество неудачных входов, блокировки).
Сроки и стоимость
Базовая реализация логина/пароля с rate limiting, сессиями и remember me — от 2 до 5 рабочих дней. Стоимость рассчитывается индивидуально в зависимости от сложности и стека. Средний ущерб от утечки данных по статистике IBM — 4.24 млн долларов, поэтому вложения в безопасную аутентификацию окупаются многократно. Закажите реализацию под ключ — свяжитесь с нами для оценки вашего проекта. Мы гарантируем надёжность и конфиденциальность.
Получите консультацию инженера по безопасности — закажите внедрение системы аутентификации для вашего проекта.