Одного разу наш клієнт, фінтех-стартап, втратив доступ до панелі адміністрування: зловмисник перехопив сесію через незахищений HTTP, і пароль адміністратора зберігався в MD5. Відновлення зайняло дві доби, а витік даних клієнтів призвів до значних компенсацій. Такі інциденти — результат типових помилок: слабке хешування, відсутність 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 робочих днів. Вартість розраховується індивідуально залежно від складності та стеку. Тому вкладення в безпечну аутентифікацію окупаються багаторазово. Замовте реалізацію під ключ — зв'яжіться з нами для оцінки вашого проєкту. Ми гарантуємо надійність і конфіденційність.
Отримайте консультацію інженера з безпеки — замовте впровадження системи аутентифікації для вашого проєкту.