Безпечна аутентифікація за логіном і паролем

Одного разу наш клієнт, фінтех-стартап, втратив доступ до панелі адміністрування: зловмисник перехопив сесію через незахищений 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)]);
}

Порівняння алгоритмів:

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

Отримайте консультацію інженера з безпеки — замовте впровадження системи аутентифікації для вашого проєкту.

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

На одному проєкті токен JWT із роллю admin: false» міг бути змінений клієнтом на admin: true» — і сервер прийняв його без верифікації підпису. Ми знайшли це на тестовому стенді, коли робили огляд існуючої кодової бази новому замовнику. Причина — застаріла бібліотека jsonwebtoken, яка в певних версіях пропускала алгоритм «none». Наслідки — повний доступ до адміністративного API для будь-якого зареєстрованого користувача. Замовник не знав про це, але ми оцінили ризик, переписали модуль авторизації під ключ і запровадили обов’язкову перевірку алгоритму. Тепер подібних інцидентів немає. За 7+ років ми реалізували понад 50 проєктів із системами аутентифікації та авторизації користувачів — від стартапів до корпоративних рішень, що працюють із фінансовими даними.

Чому JWT не варто зберігати в localStorage?

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 (симетричний) у мікросервісній архітектурі: сервіси можуть верифікувати токен публічним ключем, не маючи доступу до секрету для його створення.

Як обрати між сесіями та токенами?

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

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

Для більшості веб-додатків сесії простіші та безпечніші. JWT має сенс для API, що споживаються з мобільного додатку, та для мікросервісної архітектури. Оцініть ваш сценарій — ми допоможемо обрати правильний підхід.

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 адаптера.

RBAC, ABAC, ReBAC — що і коли застосовувати

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.

Як ми це робимо: кейс із впровадження 2FA

Проєкт — платіжний шлюз для маркетплейсу. Потрібно було захистити доступ до операцій виводу коштів. Ми спроєктували систему:

• Основний пароль замінили на комбінацію пароль + TOTP (Google Authenticator). Використали otplib (Node.js) для генерації та верифікації кодів.
• Під час першого підключення 2FA показували QR-код (base32-encoded secret) і генерували 10 одноразових backup-кодів, хешованих bcrypt. Відображали коди лише один раз.
• Secret для TOTP зберігали у зашифрованому вигляді в базі даних (AES-256-GCM, ключ у AWS KMS).
• На стороні фронтенду інтегрували @simplewebauthn/browser для passkeys — біометрична аутентифікація як альтернатива паролю. Публічний ключ зберігали на сервері, private key на пристрої користувача.
• Результат: час на логін зріс на 5 секунд, але кількість зламаних акаунтів упала до нуля за пів року роботи. Гарантія безпеки — на рівні OWASP ASVS Level 2.

Також варто зазначити, що TOTP значно надійніше за SMS-верифікацію через SIM-swapping, тому для фінансових даних ми рекомендуємо TOTP або апаратні ключі.

Типові вразливості, які ми знаходимо

• 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: * — це діра.

Penetration testing обов’язковий для продуктів з фінансовими даними або персональними даними користувачів. Ми проводимо аудит коду й інфраструктури на етапі приймання.

Що входить у роботу

Ми передаємо замовнику:

• Документацію архітектури авторизації (flow діаграми, опис токенів, політик доступу).
• Репозиторій із вихідним кодом, покритий unit- та integration-тестами.
• Конфігурацію для CI/CD (GitHub Actions/ GitLab CI) із перевірками безпеки.
• Доступи до середовищ (staging, production) із правами адміністратора.
• Інструкцію з експлуатації та супроводу.
• Підтримку після впровадження — 2 тижні безкоштовних консультацій.

Терміни та вартість

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

Вартість розраховується індивідуально залежно від обсягу та складності. Замовте консультацію — оцінимо ваш проєкт безкоштовно. Отримайте гарантію безпеки вашої авторизації користувачів.