Що таке двофакторна автентифікація? Простий посібник

Двофакторна автентифікація (2FA) — це вхід, який вимагає два різні види підтвердження того, що ви — це ви: зазвичай щось, що ви знаєте, наприклад пароль, і щось, що у вас є, наприклад телефон або ключ безпеки. Якщо злочинець вкрав або вгадав ваш пароль, він усе одно не зможе увійти без другого фактора. Це один із найпростіших способів захистити важливі облікові записи.

Чому це важливо, коли ви створюєте з ШІ

Коли ви просите у ШІ-конструктора «вхід», зазвичай отримуєте email і пароль. Це непоганий початок, але паролі повторно використовують, на них ловлять на фішинг і вони витікають. Якщо ваш застосунок зберігає щось цінне — записи клієнтів, рахунки, адміністративні функції, налаштування оплати, — один викрадений пароль може відкрити все це.

2FA також впливає на рішення, про які ви, можливо, спочатку не думаєте:

• Хто має її використовувати. Необов’язково для всіх, обов’язково для адміністраторів чи обов’язково для всіх?
• Які методи ви підтримуєте. Коди з застосунку, текстові повідомлення, passkey, ключі безпеки.
• Що відбувається, коли людину заблоковано. Втрачені телефони — найпоширеніший запит до підтримки для будь-якого застосунку з 2FA.
• Де вона застосовується. Перевірка має відбуватися на сервері. Екран 2FA, який лише ховає сторінку в браузері, можна обійти.

Вам не потрібно самим створювати криптографію — перевірені бібліотеки та провайдери автентифікації роблять це за вас. Але знати, що саме просити, потрібно.

Повсякденна аналогія

Уявіть банківську скриньку в сейфі. Щоб її відкрити, потрібні ваш документ (те, що банк перевіряє: ви є або знаєте) і фізичний ключ (те, що ви маєте). Злодій, який скопіював ваш підпис, усе одно не має ключа. Злодій, який вкрав ключ, усе одно не пройде перевірку документа.

2FA працює так само. Пароль — це підпис; телефон або ключ безпеки — це фізичний ключ. Кожного з них окремо недостатньо.

Три види факторів

Стандарти безпеки, наприклад рекомендації Національного інституту стандартів і технологій США щодо цифрової ідентичності, поділяють фактори на три види:

Ключове слово — різні. Пароль плюс контрольне питання — це два речі, які ви знаєте, тож це не справжня двофакторна автентифікація. Якщо один витік може розкрити обидва, це рахується лише як один фактор.

Порівняння поширених методів 2FA

Рекомендації NIST вважають методи, де ви вводите код (SMS, email, застосунки-автентифікатори), такими, що не стійкі до фішингу, а надсилання кодів через телефонну мережу позначають як «обмежене». Стійкими до фішингу вважаються passkey та апаратні ключі безпеки на основі стандартів WebAuthn/FIDO2.

Практичний висновок: застосунок-автентифікатор — сильний і простий вибір за замовчуванням для більшості застосунків, а passkey варто пропонувати, якщо ваші користувачі звикли до них.

Приклад: 2FA для клієнтського порталу

Наприклад, ви створили портал, де невелика бухгалтерська фірма ділиться з клієнтами податковими документами. Ось як працює розумне налаштування 2FA, крок за кроком.

Увімкнення (реєстрація). Пріті, клієнтка, відкриває Налаштування і натискає «Увімкнути двофакторну автентифікацію». Застосунок генерує секрет і показує його у вигляді QR-коду. Вона сканує його своїм застосунком-автентифікатором, який починає показувати шестизначні коди. Вона вводить поточний код назад у портал, щоб підтвердити, що налаштування працює. Застосунок показує десять кодів відновлення і просить зберегти їх у безпечному місці.

Вхід після цього.

1. Пріті вводить email і пароль. Сервер їх перевіряє.
2. Замість того щоб одразу впустити її, сервер позначає сесію як «пароль підтверджено, очікується другий фактор» і показує екран коду.
3. Вона вводить код із застосунку. Сервер перевіряє його проти збереженого секрету, враховуючи невелике відхилення годинника.
4. Лише тепер сервер створює повну сесію і дозволяє переглядати документи.

Що бачить зловмисник. Якщо пароль Пріті витік з іншого сайту, зловмисник застряє на кроці 3. Кожна невдала спроба коду враховується, і після кількох помилкових спроб обліковий запис тимчасово блокується, а Пріті отримує лист.

Втрата телефона. Пріті входить за одним зі своїх кодів відновлення, вимикає і знову вмикає 2FA з новим телефоном і отримує нові коди відновлення. Використаний код уже ніколи не можна буде застосувати знову.

Для співробітників. Бухгалтери фірми можуть бачити файли кожного клієнта, тому портал вимагає 2FA для співробітників; вони не мають доступу до панелі, доки не зареєструються.

Пояснення поширених термінів

Поширені помилки та хибні уявлення

• «2FA робить обліковий запис недоступним для злому». Вона робить злом значно складнішим. Фішингові сайти все одно можуть перехопити введені коди в реальному часі, тому й існують passkey.
• Перевірка коду лише в браузері. Якщо сервер видає повну сесію після пароля, екран коду — лише декорація. Сервер має відмовляти в доступі, доки другий фактор не пройдено.
• Немає обмеження на спроби вгадати код. Шестизначний код має мільйон варіантів. Без обмеження частоти запитів і блокувань зловмисник може просто продовжувати вгадувати.
• Забута процедура відновлення. Без кодів відновлення кожен втрачений телефон стає запитом до підтримки або заблокованим клієнтом.
• Необережне зберігання секрету TOTP. Спільний секрет має бути зашифрований у базі даних і ніколи не показуватися знову після налаштування.
• Дозвіл користувачам вимикати 2FA без повторної перевірки. Вимкнення 2FA або зміна email має вимагати пароль і поточний код.
• Пароль плюс контрольне питання вважаються 2FA. Це не так — обидва є тим, що ви знаєте.

Що попросити у вашого ШІ-конструктора

• «Додай необов’язкову двофакторну автентифікацію через застосунок-автентифікатор (TOTP) з QR-кодом для налаштування і кодом підтвердження перед увімкненням.»
• «Під час увімкнення 2FA покажи десять одноразових кодів відновлення. Зберігай їх у хешованому вигляді, як паролі.»
• «Застосовуй 2FA на сервері: повна сесія не створюється, доки другий фактор не пройдено.»
• «Обмеж кількість спроб коду і блокуй вхід на 15 хвилин після повторних помилок. Надсилай користувачеві лист, коли це відбувається.»
• «Вимагай 2FA для облікових записів адміністраторів.»
• «Проси пароль і поточний код перед вимкненням 2FA або зміною email облікового запису.»
• «Використовуй відому бібліотеку або вбудовану 2FA нашого провайдера автентифікації — не пиши криптографію самостійно.»
• «Поясни, який метод ти використав і де зберігаються секрети.»

Якщо ви використовуєте хмарного провайдера автентифікації, перевірте, чи він уже пропонує 2FA або passkey; увімкнення вбудованої функції зазвичай безпечніше, ніж власний код. Покроковий варіант є в як додати двофакторну автентифікацію, а що таке автентифікація пояснює основи входу, на яких вона базується.

Двофакторна автентифікація в Mythex

Mythex не включає вбудованої системи входу для користувачів вашого застосунку, тож 2FA є частиною того підходу до автентифікації, який ви обираєте — чи це ваш власний вхід через email і пароль на основі бази даних проєкту, чи хмарний провайдер, що пропонує 2FA. Ви просите агента додати її в чаті, а ключі провайдерів зберігаються в секретах проєкту, а не в самому чаті. Рецепт у документації щодо додавання входу до застосунку містить стартовий запит, який можна адаптувати, а безпека для застосунків, які ви створюєте описує звички щодо ключів. Перед запуском пройдіть чек-лист безпеки для застосунків, створених за допомогою ШІ.

Запитання