Як додати двофакторну автентифікацію до застосунку

Щоб додати двофакторну автентифікацію (2FA) до застосунку, дайте користувачам прив'язати застосунок-автентифікатор, сканувавши QR-код, попросіть шестизначний код, який він показує після пароля, і створюйте повноцінну сесію на сервері лише після того, як код перевірено. Кожному користувачеві видайте одноразові резервні коди під час увімкнення, обмежте кількість спроб вгадати код і вимагайте пароль разом із чинним кодом, перш ніж 2FA можна буде вимкнути. Якщо ви використовуєте хостований провайдер автентифікації, увімкніть його вбудовану багатофакторну опцію замість створення власної.

Цей посібник проходить через вибір варіантів, точний процес, промпти для AI-конструктора та помилки, через які 2FA виглядає увімкненою, але нічого не робить. Якщо це поняття для вас нове, почніть із що таке двофакторна автентифікація.

Перш ніж почати: потрібен робочий вхід

2FA працює поверх наявного входу. Спершу потрібне одне з двох:

• Власний вхід, де користувачі та хешовані паролі зберігаються в базі даних вашого застосунку.
• Хостований провайдер автентифікації, який керує користувачами за вас.

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

Оберіть другий фактор

TOTP означає одноразовий пароль на основі часу — стандарт (RFC 6238), який використовують застосунки-автентифікатори. Ваш сервер і телефон користувача поділяють секрет; кожен із них генерує той самий короткий код з цього секрету та поточного часу, зазвичай з оновленням кожні 30 секунд. Жодне мережеве з'єднання чи SMS-провайдер не потрібні.

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

Створювати самостійно чи ввімкнути?

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

Спершу визначте політику

Відповідайте на ці питання до того, як писати промпт, бо від них залежить дизайн:

1. Хто має використовувати це? Необов'язково для всіх, обов'язково для адміністраторів і персоналу або обов'язково для всіх. Вимагати це від кожного, хто має адміністративні повноваження, — поширена практика. Див. контроль доступу на основі ролей.
2. Як часто користувачі вводять код знову? Під час кожного входу або раз на пристрій протягом 30 днів («запам'ятати цей пристрій»).
3. Для яких дій потрібна свіжа перевірка? Зміна електронної пошти, реквізитів виплат або вимкнення 2FA — гарні кандидати. Це називається step-up автентифікацією.
4. Який процес на випадок втрати телефона? Резервні коди плюс ручний запасний варіант, який ви готові виконувати.

Покроково: 2FA через TOTP у власному вході

1. Зберігайте правильні поля

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

2. Реєстрація

1. Користувач відкриває налаштування і натискає Увімкнути двофакторну автентифікацію.
2. Сервер генерує новий секрет і повертає його у вигляді QR-коду, а також у текстовому вигляді для тих, хто не може відсканувати.
3. Користувач сканує його в застосунку-автентифікаторі та вводить поточний код.
4. Сервер перевіряє код. Лише якщо він правильний, сервер зберігає секрет і позначає 2FA як увімкнену.
5. Застосунок показує 8–10 резервних кодів один раз і просить користувача їх зберегти.

Крок 4 важливий: увімкнення 2FA до підтвердження коду заблокує того, чий скан не спрацював.

3. Вхід із другим кроком

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

Кожен захищений маршрут і API-ендпоінт має відхиляти стан очікування. Екран 2FA, який лише приховує сторінки в браузері, можна обійти, викликавши API напряму.

4. Обмеження та сповіщення

Шестизначний код має мільйон комбінацій, які можна вгадати без обмежень. Обмежте спроби, блокуйте другий крок на певний час після повторних невдач і надсилайте користувачеві лист, коли це стається. Див. обмеження частоти запитів і надсилання листів із застосунку.

5. Відновлення та вимкнення

• Резервний код працює один раз, а потім видаляється.
• Для вимкнення 2FA потрібні пароль і чинний код або резервний код.
• Повторне створення резервних кодів робить старий набір недійсним.
• Надсилайте користувачеві лист щоразу, коли 2FA вмикається або вимикається.

Промпти для вашого AI-конструктора

Почніть з основного потоку:

Додай необов'язкову двофакторну автентифікацію через застосунки-автентифікатори (TOTP) до нашого наявного входу за email і паролем. Використовуй відому бібліотеку TOTP, не пиши алгоритм сам. У налаштуваннях покажи QR-код і текстовий секрет, а 2FA вмикай лише після того, як користувач введе чинний код. Зберігай секрет зашифрованим і більше ніколи не показуй його після налаштування. Покажи 10 одноразових резервних кодів один раз і зберігай їх у хешованому вигляді.

Потім примусове застосування, де згенерований код найчастіше не дотягує:

Застосовуй 2FA на сервері. Після правильного пароля користувачі з увімкненою 2FA отримують короткочасний стан очікування, а не повноцінну сесію. Кожна захищена сторінка й API-маршрут мають відхиляти стан очікування. Обмеж спроби введення коду до 5, потім блокуй другий крок на 15 хвилин і надішли користувачеві лист.

Потім політика:

Вимагай 2FA для облікових записів адміністраторів: адміністратор без 2FA відправляється на налаштування і не може потрапити на панель, доки їх не завершить. Вимагай пароль і чинний код, щоб вимкнути 2FA або змінити електронну пошту облікового запису. Надсилай користувачеві лист, коли 2FA вмикається або вимикається.

Нарешті попросіть агента пояснити, що він створив:

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

Типові помилки

• Сесія видається після пароля. Найсерйозніша помилка. Якщо повноцінна сесія існує до перевірки коду, 2FA — лише декорація. Перевіряйте, викликаючи захищений API лише після кроку з паролем.
• Немає обмеження спроб. Необмежені спроби роблять код вразливим до перебору.
• Секрети або резервні коди у відкритому тексті. Витік бази даних тоді віддає другий фактор кожного.
• Увімкнення до перевірки. Користувачі, які помилково відсканували код, блокуються під час наступного входу.
• Немає шляху відновлення. Кожен втрачений телефон стає заявкою в підтримку або втраченим клієнтом.
• Легке вимкнення. Якщо викрадена сесія може вимкнути 2FA без коду, захист зник.
• Коди в журналах. Переконайтеся, що коди та секрети ніколи не з'являються в серверних журналах чи повідомленнях про помилки.
• Перевірка лише на сторінці входу. Скидання пароля, вхід за «магічним посиланням» і будь-який вхід через соцмережі теж мають враховувати 2FA, інакше вони стануть способом її обійти.

Чек-лист тестування

• Реєстрація завершується лише після чинного коду
• Вхід із правильним паролем, але без коду не дає доступу до жодної захищеної сторінки чи API
• Невірний код відхиляється; повторні невірні коди запускають блокування і лист
• Код, якому кілька хвилин, відхиляється
• Кожен резервний код працює рівно один раз
• Для вимкнення 2FA потрібні пароль і чинний код
• Скидання пароля не обходить 2FA
• Адміністратори без 2FA не можуть відкрити адмін-сторінки (якщо це вимагається)
• Секрети та резервні коди зашифровані або хешовані в базі даних
• Коди й секрети не з'являються в журналах

Перед запуском також виконайте повний контрольний список безпеки для застосунків, створених за допомогою ШІ.

Додавання 2FA на Mythex

Mythex не містить вбудованої системи входу для кінцевих користувачів вашого застосунку, тож 2FA є частиною того підходу до автентифікації, який ви обираєте: власний вхід за email і паролем з використанням бази даних проєкту або хостований провайдер із підтримкою багатофакторної автентифікації. Ви описуєте потрібне в чаті за промптами, подібними до наведених вище, а ключі провайдера зберігаються в секретах проєкту (через /secrets, налаштування проєкту або картку з секретами, яку показує агент), а не в полі повідомлення. У рецепті документації Додати вхід до застосунку є стартовий промпт, а Безпека для застосунків, які ви створюєте описує звички щодо ключів і дозволів. Після того як агент завершить роботу, пройдіть кожен пункт чек-листа в Preview, перш ніж публікувати.

Запитання