Двофакторна автентифікація, або 2FA, захищає акаунт тим, що після пароля вимагає ще один незалежний доказ: код із застосунку, підтвердження на пристрої, апаратний ключ або passkey. Якщо пароль витік чи був введений на фішинговій сторінці, зловмиснику все одно потрібен другий фактор. Але рівень захисту залежить від методу: SMS, TOTP-коди, push, FIDO2-ключі та passkeys не рівноцінні. Дані й документи в цій статті актуальні за брифом станом на 25 вересня 2026 року.
Що таке двофакторна автентифікація простими словами
Двофакторна автентифікація — це вхід, де сервіс перевіряє не лише пароль, а ще один фактор, який складніше вкрасти разом із ним.
Фактори автентифікації зазвичай ділять на три групи:
- Щось, що ви знаєте: пароль, PIN, відповідь на секретне запитання.
- Щось, що ви маєте: телефон, застосунок-генератор кодів, апаратний ключ безпеки.
- Щось, чим ви є: відбиток пальця, Face ID, інша біометрія.
Класична 2FA — це комбінація пароля та другого фактора. Наприклад: ви вводите пароль від пошти, а потім підтверджуєте вхід кодом із застосунку або ключем безпеки. MFA — ширше поняття: воно означає два або більше факторів, тому 2FA є окремим випадком MFA.
Важливий нюанс: біометрія на телефоні зазвичай не надсилається сайту. Вона розблоковує локальний ключ або підтверджує дію на пристрої. Саме тому passkey може виглядати як один крок — торкнутися сенсора чи ввести PIN, — але технічно за ним стоїть криптографічна перевірка пристрою та локальне розблокування.
Як 2FA захищає акаунт після витоку пароля
2FA зменшує ризик злому, бо викрадений пароль перестає бути достатнім для входу.
Типовий сценарій без другого фактора простий: користувач повторно використовує пароль на кількох сайтах, один із них зламують, після чого пароль пробують у пошті, соцмережах, хмарному сховищі або GitHub. Якщо 2FA не ввімкнена, акаунт може бути захоплений одразу після успішного підбору пари логін-пароль.
З другим фактором атака ускладнюється. Зловмиснику вже потрібно отримати SMS або доступ до номера, виманити одноразовий код у реальному часі, змусити користувача натиснути push-підтвердження, мати фізичний ключ безпеки чи пристрій із passkey або обійти процедуру відновлення акаунта.
Це не робить акаунт невразливим. 2FA не лікує заражений пристрій, не захищає від викрадення сесійних cookie і не скасовує потребу в унікальному паролі. Але вона прибирає найнебезпечнішу слабкість: можливість увійти лише за паролем.
Які методи 2FA безпечніші: зведена таблиця вибору
Найсильніший практичний вибір для більшості важливих акаунтів — passkey або FIDO2-ключ, а SMS варто залишати лише як крайній або резервний варіант.
| Метод | Як працює | Стійкість до фішингу | Головний ризик | Коли обирати |
|---|---|---|---|---|
| SMS-код | Сервіс надсилає одноразовий код на номер телефону | Низька | SIM-swap, перехоплення номера, фішинг у реальному часі | Якщо сервіс не дає кращих варіантів |
| TOTP у застосунку | Застосунок генерує код за спільним секретом і часом | Низька або середня | Код можна ввести на підробленому сайті | Добрий мінімум для більшості сервісів, особливо без SMS |
| Push Approve/Deny | На телефон приходить запит підтвердити або відхилити вхід | Низька без додаткової перевірки | MFA fatigue: користувача засипають запитами | Тільки якщо є контроль контексту входу |
| Push із number matching | Користувач вводить у застосунку число, показане на екрані входу | Краще за просте натискання | Шахрай може переконати користувача ввести число | Для корпоративних акаунтів і Microsoft Authenticator |
| Апаратний ключ FIDO2 | Фізичний ключ виконує криптографічну операцію для конкретного домену | Висока | Втрата ключа без резерву | Для пошти, менеджера паролів, GitHub, робочих акаунтів |
| Passkey | Пристрій або менеджер паролів зберігає приватний ключ, вхід підтверджується PIN чи біометрією | Висока | Втрата доступу до пристроїв і резервних методів | Як основний метод для звичайного користувача |
Найважливіша різниця така: коди, які людина вручну вводить на сайті, не прив’язані до домену. Фішингова сторінка може прийняти код і швидко передати його справжньому сервісу. FIDO/WebAuthn працює інакше: криптографічна операція прив’язана до домену, тому ключ не має підтвердити вхід для підробленого сайту.
Це схоже на різницю між простим посиланням і перевіреним адресатом у вебі: в HTML можна створити будь-який анкор, але без перевірки адреси користувач не завжди бачить, куди потрапить. Якщо цікаво, як у вебсторінках працюють посилання, корисним буде матеріал про атрибут href в HTML.
Власний розрахунок: наскільки складно вгадати 6-значний TOTP-код
Типовий 6-значний OTP має 1 000 000 можливих комбінацій, але реальний захист залежить не лише від довжини коду, а й від ліміту спроб і часу дії.
| Умовний сценарій | Кількість випадкових спроб | Ймовірність вгадати один 6-значний код | Скільки 30-секундних вікон покриває такий самий обсяг спроб, якщо пробувати по 1 разу на вікно | Висновок |
|---|---|---|---|---|
| Одна випадкова спроба | 1 | 0,0001% | 1 вікно | Майже марно без інших слабких місць |
| Невелика автоматизована атака | 100 | 0,01% | 100 вікон, тобто приблизно 50 хвилин | Ліміт спроб критично важливий |
| Агресивна атака без нормального rate limiting | 1000 | 0,1% | 1000 вікон, тобто приблизно 8 годин 20 хвилин | Без блокування ризик накопичується |
| Одна година спроб по 1 разу на кожне 30-секундне вікно | 120 | 0,012% | 120 вікон | Навіть повільні атаки потребують обмежень і моніторингу |
Як рахували
Вихідні числа: RFC 6238 описує TOTP і рекомендує типовий інтервал 30 секунд; RFC 4226 наводить 6-значний HOTP як стандартний приклад, тобто простір становить 1 000 000 комбінацій. NIST SP 800-63B-4 згадує 100 спроб як верхню межу для окремих сценаріїв перевірки OTP, але сервіс може встановлювати нижчий ліміт. Джерела вихідних чисел: RFC 6238 про TOTP і NIST SP 800-63B-4.
Формула для грубої оцінки: кількість спроб / 1 000 000 × 100%. Для 100 спроб це 100 / 1 000 000 × 100% = 0,01%. Для 1000 спроб — 0,1%. Кількість TOTP-вікон за годину: 60 хвилин × 60 секунд / 30 секунд = 120 вікон. Якщо робити по одній випадковій спробі на кожне вікно, за годину буде 120 спроб, тобто 0,012%.
Припущення: розрахунок стосується 6-значного коду, рівномірного випадкового вгадування та не враховує ширше вікно синхронізації, блокування, CAPTCHA, ризиковий аналіз, повторну автентифікацію й виявлення аномалій. Це не універсальна модель для кожного сервісу, бо реальні сайти можуть мати іншу кількість цифр, інший часовий допуск і власні ліміти.
Практичний наслідок: сила TOTP не лише в мільйоні комбінацій, а в поєднанні короткого часу життя коду, одноразовості та обмеження спроб. Якщо сервіс дозволяє багато помилкових вводів без затримки або блокування, навіть хороший формат коду стає слабшим.
Чому SMS-2FA краще за нічого, але гірше за застосунок чи ключ
SMS-2FA додає бар’єр після пароля, але переносить частину безпеки на мобільного оператора й номер телефону.
Її головна перевага — доступність. Не потрібно встановлювати окремий застосунок, купувати ключ або розбиратися з passkeys. Якщо сервіс пропонує тільки SMS, вмикати SMS-2FA все одно варто: пароль без другого фактора слабший.
Недоліки принципові:
- SIM-swap. Шахрай може спробувати перевипустити SIM або отримати контроль над номером через соціальну інженерію.
- Фішинг у реальному часі. Підроблений сайт може попросити SMS-код і одразу використати його на справжньому сайті.
- Залежність від доставки. SMS може затриматися або не прийти; для SMS і голосових MFA немає гарантії стабільної доставки повідомлень або дзвінків з одного й того самого номера.
- Компрометація телефона. Якщо пристрій заражений або повідомлення синхронізуються в небезпечне середовище, код може бути викрадений.
Якщо сервіс дозволяє, краще замінити SMS на TOTP, passkey або FIDO2-ключ. SMS можна залишити як резерв, але тоді варто захистити кабінет мобільного оператора, встановити PIN або пароль на обслуговування номера й за можливості обмежити дистанційний перевипуск SIM.
Як працюють TOTP-коди й де їх межа
TOTP-код генерується на пристрої за спільним секретом і часом, тому не потребує SMS або мобільного покриття.
Під час налаштування сервіс показує QR-код або секретний ключ. Застосунок автентифікації зберігає цей секрет і генерує одноразові коди. Типова конфігурація — 6 цифр і 30-секундний інтервал, але це не універсальна вимога для всіх реалізацій.
TOTP добре закриває сценарій, коли пароль витік із бази, а зловмисник пробує увійти. Він не має доступу до секрету в застосунку, тому не знає поточного коду. TOTP також зручний офлайн: код генерується локально, без SMS і без дзвінка.
Слабке місце — фішинг. Якщо людина вводить пароль і TOTP-код на підробленій сторінці, атакувальник може передати їх справжньому сервісу майже миттєво. Тому TOTP варто поєднувати з перевіркою домену, менеджером паролів і обережністю до листів із терміновим входом.
Резервування теж важливе. Якщо телефон втрачено, а секрет TOTP ніде не збережено і резервний пристрій не додано, відновлення може бути складним. Але зберігати QR-код у незахищеній нотатці — погана ідея: це фактично копія другого фактора.
Push-підтвердження: зручно, але не завжди безпечно
Push-автентифікація зручна, проте просте натискання Approve може стати слабким місцем через втому від запитів.
Атака MFA fatigue працює так: зловмисник уже має пароль і багато разів ініціює вхід. На телефон користувача сипляться push-запити. Людина може натиснути підтвердити випадково, з роздратування або думаючи, що це збій сервісу.
Number matching зменшує цей ризик. У Microsoft Authenticator користувач бачить число на сторінці входу та має ввести його в застосунку. За актуальною документацією Microsoft Entra number matching увімкнено для push-повідомлень Authenticator. Водночас є обмеження: number matching не підтримується для push-повідомлень на Apple Watch та Android-пристроях, що носяться; для Microsoft NPS extension підтримка TOTP-сценарію пов’язана з версією 1.2.2216.1 або новішою.
Number matching кращий за просте Approve/Deny, але не робить push повністю фішингостійким. Якщо шахрай переконує людину ввести число з підробленої сторінки або диктує інструкції телефоном, ризик залишається.
Passkeys і FIDO2-ключі: чому це сильніший рівень
Passkeys і FIDO2-ключі сильніші за коди, бо використовують криптографію та прив’язку до домену, а не секрет, який користувач переписує вручну.
Passkey складається з пари ключів: приватний ключ залишається на пристрої, у менеджері паролів або на апаратному ключі, а відкритий ключ зберігається в сервісі. Під час входу сервіс перевіряє криптографічну відповідь. Користувач підтверджує дію локально: PIN, паролем розблокування, відбитком пальця або розпізнаванням обличчя.
FIDO Alliance описує passkeys як облікові дані на основі WebAuthn і CTAP. Вони можуть бути синхронізованими між пристроями, прив’язаними до конкретного пристрою або збереженими на апаратному ключі. Докладніше про підхід описує FIDO Alliance про passkeys.
У Google passkey може замінити пароль і окремий другий крок, бо сервіс одночасно перевіряє наявність пристрою або ключа та локальне розблокування. Тому passkey не завжди виглядає як класична схема «пароль плюс код», але може давати сильніший захист від фішингу.
Trade-off — відновлення. Якщо всі пристрої з passkeys втрачені, а резервні методи не налаштовані, повернути доступ може бути складно. Для критично важливих акаунтів доречна схема з двома апаратними ключами: один щоденний, другий резервний у безпечному місці.
Для розробників passkeys пов’язані з вебстандартами й роботою браузера. Якщо ви паралельно вивчаєте фронтенд, базове розуміння структури сторінок можна підтягнути у статті про основні HTML-теги, а логіку обробки введення — у матеріалі про регулярні вирази в JavaScript.
Як обрати 2FA для свого акаунта
Метод 2FA треба обирати за важливістю акаунта, доступними способами входу та ризиком втрати доступу.
| Ситуація | Основний метод | Резерв | Чому саме так |
|---|---|---|---|
| Звичайна пошта, соцмережі, хмарні сервіси | Passkey | TOTP або другий passkey | Добрий баланс зручності та фішингостійкості |
| Головна пошта, менеджер паролів, робочий акаунт | Апаратний FIDO2-ключ | Другий апаратний ключ | Найкращий контроль фізичного володіння й сильний захист від фішингу |
| GitHub або акаунт розробника | Security key або passkey | TOTP | GitHub класифікує SMS як небезпечний метод для корпоративних політик |
| Сервіс підтримує лише SMS | SMS-2FA | Захищений номер і резервна пошта | Це слабше за інші методи, але краще за один пароль |
| Потрібен доступ без мобільного покриття | TOTP | Резервні коди або додатковий пристрій | Коди генеруються локально й не залежать від доставки SMS |
Якщо сервіс пропонує кілька варіантів, практичний порядок пріоритету такий: passkey, апаратний FIDO2-ключ, TOTP, push із number matching, SMS. Для найважливіших акаунтів не варто зупинятися на одному методі: головний спосіб входу і резерв мають бути різними.
Резервні коди та відновлення доступу
Резервні коди потрібні для входу, коли телефон, застосунок або ключ тимчасово недоступні, але самі вони є довготривалим секретом.
Google дозволяє створити набір із 10 резервних кодів; актуальна довідка описує їх як 8-значні, кожен код використовується один раз, а після створення нового набору старі коди стають неактивними. Це зручно, якщо телефон загублено або застосунок автентифікації недоступний.
Погані місця для зберігання резервних кодів:
- та сама пошта, яку ці коди мають захищати;
- незахищена хмарна нотатка;
- чат без наскрізного контролю доступу;
- фото в галереї разом із документами;
- робочий стіл комп’ютера у відкритому текстовому файлі.
Краще зберігати їх у менеджері паролів, захищеному окремим сильним входом, або офлайн у місці, до якого не має доступу стороння людина. Для акаунтів із підвищеним ризиком варто мати не лише коди, а й другий ключ або другий passkey.
Поширені міфи про двофакторну автентифікацію акаунта
2FA часто переоцінюють або неправильно налаштовують, тому частина ризиків залишається навіть після ввімкнення другого фактора.
| Міф | Що кажуть дані | Практичний висновок |
|---|---|---|
| Якщо є 2FA, акаунт неможливо зламати | 2FA не захищає від викрадення cookie, шкідливого ПЗ, соціальної інженерії та слабкого відновлення доступу | Потрібні унікальні паролі, оновлені пристрої та контроль резервної пошти |
| Усі методи 2FA однаково безпечні | NIST не вважає вручну введені OTP-коди фішингостійкими; FIDO/WebAuthn прив’язує операцію до домену | Для важливих акаунтів обирайте passkey або FIDO2-ключ |
| 6-значний код неможливо вгадати | Є 1 000 000 комбінацій, але без обмеження спроб атака може накопичувати ймовірність | Сервіс має блокувати або сповільнювати повторні спроби |
| Push завжди безпечніший за код | Просте Approve/Deny вразливе до MFA fatigue | Краще використовувати number matching і перевіряти, чи саме ви починали вхід |
| Біометрія сама по собі є 2FA | Біометрія зазвичай лише розблоковує локальний ключ на пристрої | Справжній захист дає комбінація пристрою, ключа та локального підтвердження |
Короткий порядок дій
Найкраща практична схема — ввімкнути passkey або ключ безпеки, додати резерв і прибрати SMS із ролі основного методу, якщо сервіс це дозволяє.
- Перевірте, чи підтримує сервіс passkeys або security keys.
- Для головної пошти й менеджера паролів додайте щонайменше два сильні методи: основний і резервний.
- Якщо доступний лише TOTP, збережіть резервні коди та продумайте відновлення після втрати телефона.
- Якщо доступний лише SMS, увімкніть його, але захистіть номер у мобільного оператора.
- Не підтверджуйте push-запит, якщо ви самі не починали вхід.
- Не вводьте коди на сторінках, відкритих із підозрілих листів або повідомлень.
Підсумок: 2FA варто ввімкнути всюди, де є така можливість, але для важливих акаунтів недостатньо будь-якого другого фактора. Оптимальний вибір для більшості користувачів — passkey плюс резервний TOTP або другий passkey; для критичних акаунтів — два FIDO2-ключі; SMS — лише тоді, коли кращого варіанту немає.