Методи
аутентифікації
користувача
Від пароля в базі до passkey у Secure Enclave: як веб-застосунок відповідає на питання «хто ти?» — і чому більшість відповідей уже застаріли.
Аутентифікація ≠ авторизація
Аутентифікація — «Хто ти?»
Підтвердження особи. Виконується один раз на вході, результат — ідентичність користувача.
- Перевіряє: паролі, токени, ключі, біометрію
- Результат: user_id
- Помилка: 401 Unauthorized
Авторизація — «Що тобі можна?»
Перевірка прав на конкретний ресурс. Виконується щоразу, для кожного об'єкта окремо.
- Перевіряє: ролі, політики, власність (RBAC / ABAC / ReBAC)
- Результат: дозвіл або відмова
- Помилка: 403 Forbidden
Чотири категорії доказів
Щось, що ти знаєш
Пароль, PIN, графічний ключ, секретне питання.
- Найдешевше в реалізації
- Найлегше вкрасти
Щось, що ти маєш
Телефон, апаратний ключ, смарт-картка, сертифікат.
- Потребує фізичного доступу
- Можна загубити
Щось, чим ти є
Відбиток, обличчя, райдужка, голос.
- Зручно для користувача
- Не можна «змінити пароль»
Де і як ти дієш
IP, геолокація, відбиток пристрою, поведінка.
- Працює як фонова оцінка ризику
- Самостійно недостатній
Пароль: як зберігати, щоб не зашкодити
Повільний хеш із сіллю
- Argon2id — рекомендація OWASP за замовчуванням
- bcrypt (cost ≥ 12) або scrypt — прийнятні альтернативи
- Сіль — унікальна на кожен запис, генерується CSPRNG
- Порівняння — тільки constant-time
Що ламає систему
- MD5, SHA-1, SHA-256 без солі — підбираються мільярдами/сек
- Зберігання у відкритому вигляді або з оборотним шифруванням
- Обмеження довжини до 12–16 символів
- Примусова ротація кожні 30 днів — веде до Pass1!, Pass2!
// Node.js — реєстрація import argon2 from 'argon2'; const hash = await argon2.hash(password, { type: argon2.argon2id, memoryCost: 19456, // 19 MiB timeCost: 2, parallelism: 1 }); // Вхід const ok = await argon2.verify(hash, password);
Другий фактор: від SMS до YubiKey
SMS / Email OTP
Одноразовий код каналом зв'язку.
- Вразливий до SIM-swap і перехоплення SS7
- Не захищає від фішингу
- Виправданий лише як запасний варіант
TOTP / HOTP
Код із застосунку на основі спільного секрету й часу (RFC 6238).
- Працює офлайн, безкоштовно
- Секрет копіюється при компрометації сервера
- Код можна виманити фішингом
Push-підтвердження
Запит у довіреному застосунку: «Підтвердити вхід?»
- Зручно, показує контекст входу
- Ризик MFA fatigue — спам запитами
- Лікується number matching
FIDO2 / U2F ключі
Апаратний токен (YubiKey, Titan) із криптопарою.
- Прив'язка до домену — фішинг неможливий
- Секрет не залишає пристрій
Смарт-картки, X.509
Клієнтський сертифікат, часто на фізичній картці.
- Банки, держсектор, критична інфраструктура
- Складна інфраструктура PKI
Recovery-коди
Список одноразових кодів на випадок втрати пристрою.
- Обов'язкові до будь-якого MFA
- Зберігаються хешованими, як паролі
Біометрія у вебі працює не так, як здається
Дані не залишають пристрій
Браузер через WebAuthn звертається до платформного автентифікатора. Face ID чи відбиток лише розблоковують локальний приватний ключ — на сервер летить підпис, а не біометрія.
- Сервер ніколи не бачить відбитка
- Витік бази не компрометує біометрію
Чого біометрія не вміє
- Її не можна відкликати чи змінити після витоку
- Хибні спрацювання: FAR / FRR завжди компроміс
- Потребує liveness detection проти фото й дипфейків
- Підпадає під GDPR як особливі категорії даних
- Завантаження селфі на сервер для «розпізнавання» — антипатерн
Сесійні cookie проти JWT
| Критерій | Session cookie | JWT (Bearer) |
|---|---|---|
| Де стан | На сервері (Redis, БД); клієнт має лише ID | У самому токені, підписаний |
| Відкликання | Миттєве — видалили запис | Складне — потрібен denylist або короткий TTL |
| Масштабування | Потрібне спільне сховище | Stateless, зручно для мікросервісів |
| Розмір на запит | Десятки байт | Сотні байт — на кожному запиті |
| Головний ризик | CSRF — лікується SameSite=Lax/Strict + токен | XSS, якщо зберігати в localStorage |
| Термін життя | Довгий, продовжується активністю | Access 5–15 хв + refresh-токен із ротацією |
HTTP-схеми та машинна аутентифікація
| Механізм | Як працює | Де доречно |
|---|---|---|
| Basic Auth | Authorization: Basic base64(login:pass) | Внутрішні сервіси, тільки поверх HTTPS |
| Digest Auth | Хеш-челендж замість передачі пароля | Практично не використовується |
| Bearer token | Authorization: Bearer <token> | Стандарт для REST API та SPA |
| API key | Статичний ключ у заголовку | Сервіс-до-сервісу; не для користувачів |
| HMAC-підпис | Підпис методу, тіла й часу секретом (AWS SigV4) | Платіжні API, захист від replay |
| mTLS | Клієнт і сервер пред'являють сертифікати | Банки, IoT, service mesh |
| Kerberos / SPNEGO | Квитки з домен-контролера | Прозорий вхід у корпоративній мережі |
OAuth 2.0, OIDC і SAML
OAuth 2.0 — це авторизація
Протокол делегування доступу до ресурсів. Він відповідає на питання «що застосунку можна робити від мого імені», а не «хто я».
- Видає access-токен для API
- Сам по собі не підтверджує особу
OpenID Connect
Тонкий шар поверх OAuth 2.0, який додає саме аутентифікацію: id_token у форматі JWT із claims про користувача.
- Основа для «Увійти через Google/Apple/GitHub»
- Discovery через /.well-known
SAML 2.0 · LDAP · AD
XML-based SSO — досі домінує у великих компаніях і держсекторі. LDAP/Active Directory — перевірка облікових даних у каталозі.
- SCIM — автоматичне провізіонування акаунтів
WebAuthn: як це працює
Сервер надсилає випадковий challenge і свій домен (rpId)
Браузер передає запит автентифікатору — телефону, ключу, Secure Enclave
Користувач розблоковує пристрій: відбиток, обличчя або PIN
Пристрій підписує challenge приватним ключем, який його не покидає
Сервер перевіряє підпис збереженим публічним ключем
- Ключ прив'язаний до домену — фішинг технічно неможливий
- На сервері немає секрету, який можна вкрасти
- Passkeys синхронізуються між пристроями через iCloud / Google
- Вхід у два кліки — конверсія зростає
- Потрібен запасний метод для нових і чужих пристроїв
- Складніший сценарій відновлення доступу
- Синхронізовані passkeys залежать від безпеки хмарного акаунта
Magic link, OTP та їхня ціна
Magic link
Одноразове посилання на пошту замість пароля.
- Нема чого вкрасти з бази
- Безпека дорівнює безпеці поштової скриньки
- Ризик: сканери посилань у корпоративній пошті «клікають» першими
OTP як єдиний фактор
Код на пошту або телефон замість пароля.
- Звично для користувачів
- Затримки доставки псують UX
- Вартість SMS і ризик SMS-pumping атак
Прогресивна міграція
Реалістичний шлях для наявного продукту.
- Passkey пропонується як апгрейд після звичайного входу
- Пароль лишається запасним каналом
- Метрика успіху — частка входів без пароля
MFA, step-up і адаптивна перевірка
MFA
Два або більше факторів із різних категорій на вході. Знижує ризик захоплення акаунта на порядки.
Step-up authentication
Додаткове підтвердження лише перед критичною дією: зміна пароля чи email, платіж, видалення акаунта, доступ адміністратора.
Адаптивна / risk-based
Другий фактор вимагається тільки при аномалії: новий пристрій, інша країна, нетипова поведінка, IP із поганою репутацією.
| Метод | Стійкість до фішингу | Зручність | Вартість |
|---|---|---|---|
| Тільки пароль | Немає | Середня | Мінімальна |
| Пароль + SMS | Низька | Середня | SMS-трафік |
| Пароль + TOTP | Часткова | Середня | Мінімальна |
| Passkey / FIDO2 | Повна | Висока | Розробка |
Що зробити обов'язково
- Rate limiting за IP та за акаунтом, експоненційні затримки
- Захист від credential stuffing і password spraying
- Однакова відповідь на неіснуючий логін і невірний пароль — щоб не розкривати список акаунтів
- CAPTCHA або proof-of-work після кількох невдач
- Регенерація ID сесії одразу після входу — проти session fixation
- Ротація refresh-токенів із виявленням повторного використання
- Реальна інвалідація на сервері при logout
- Розрив усіх сесій при зміні пароля
- Список активних пристроїв у профілі користувача
- HTTPS скрізь, HSTS, cookie з Secure + HttpOnly + SameSite
- Токени — ніколи в URL, логах чи localStorage
- Секрети — у сховищі ключів, не в репозиторії
- Скидання пароля — одноразовий токен із коротким TTL
- Лист-сповіщення про вхід із нового пристрою
- Журнал подій аутентифікації для розслідувань
- Відновлення доступу не має бути слабшим за сам вхід
Три тези, які варто забрати з собою
Пароль — не точка, а спадок
Він залишиться ще надовго, але має бути правильно захищений і поступово ставати запасним, а не основним методом.
Не всі MFA рівні
SMS краще за нічого, TOTP краще за SMS, але тільки криптографічна прив'язка до домену робить фішинг неможливим.
Вхід — це лише початок
Broken Access Control досі №1 в OWASP Top 10. Аутентифікація одна на вхід, авторизація — на кожен ресурс окремо.
Passkeys / FIDO2 → TOTP → Push → SMS