Как да добавите двуфакторно удостоверяване към приложението си
За да добавите двуфакторно удостоверяване (2FA) към приложението си, позволете на потребителите да свържат приложение за удостоверяване, като сканират QR код, и поискайте шестцифрения код, който то показва, след паролата. Създавайте пълна сесия на сървъра едва след като кодът е верен. Дайте на всеки потребител еднократни кодове за възстановяване, когато включи функцията, ограничете колко кода може да познае някой, и изисквайте паролата плюс актуален код, преди 2FA да може да се изключи. Ако използвате хостиран доставчик на автентикация, включете вградената му опция за многофакторно удостоверяване, вместо да строите собствена.
Това ръководство обяснява избора, точния поток, подсказки за AI строител и грешките, които карат 2FA да изглежда налично, но да не прави нищо. Ако концепцията е нова за вас, започнете с какво е двуфакторно удостоверяване.
Преди да започнете: нужен ви е работещ вход
2FA стои върху съществуващ вход. Нужно ви е едно от следните:
- Собствен вход, с потребители и хеширани пароли, съхранени в базата данни на приложението ви.
- Хостиран доставчик на автентикация, който управлява потребителите вместо вас.
Ако още нямате нито едно, започнете с как да добавите вход в приложението си. Останалата част от това ръководство предполага, че стъпката с паролата вече работи.
Изберете втория си фактор
| Метод | Усилие за потребителя | Сигурност | Цена за поддръжка | Добър по подразбиране? |
|---|---|---|---|---|
| Приложение за удостоверяване (TOTP) | Сканиране на QR код веднъж, въвеждане на код при вход | Добра; подлежи на фишинг, ако фалшив сайт поиска кода | Безплатно | Да, за повечето приложения |
| Passkey или ключ за сигурност | Докосване или отпечатък | Най-силна; устойчива на фишинг | Безплатно | Да, ако потребителите ви са готови за него |
| Код по имейл | Проверка на пощата при вход | Силна колкото имейл акаунта | Разходи за изпращане на имейли | Само като резервен вариант |
| SMS код | Чакане на съобщение | Най-слаба; SIM подмяна и фишинг | Такса на съобщение | Само ако потребителите не могат да използват приложение |
TOTP означава time-based one-time password (еднократна парола, базирана на време), стандартът (RFC 6238), който използват приложенията за удостоверяване. Вашият сървър и телефонът на потребителя споделят таен ключ; всеки генерира един и същ кратък код от този ключ и текущото време, обикновено с промяна на всеки 30 секунди. Не е нужна мрежова връзка или SMS доставчик.
Passkeys заместват или допълват паролите с криптографски ключ, съхранен на устройството на потребителя. Те са по-силни, но изискват повече работа, за да ги построите сами, затова много приложения започват с TOTP и добавят passkeys по-късно или ги вземат от доставчик на автентикация.
Да го построите ли или да го включите?
| Подход | Предимства | Недостатъци |
|---|---|---|
| Многофакторно удостоверяване на хостиран доставчик | По-малко код; доставчикът поддържа детайлите за сигурност | Месечна цена при мащаб; зависите от опциите на доставчика |
| Собствен TOTP с библиотека | Пълен контрол; без такса на потребител | Вие отговаряте за граничните случаи: блокировки, възстановяване, съхранение на тайни |
Проверете текущата документация на доставчика си за това кои фактори поддържа и в кои планове. Във всеки случай никога не пишете сами математиката за генериране на кодове; използвайте широко известна библиотека.
Първо определете политиката
Отговорете на тези въпроси, преди да пишете подсказка, защото променят дизайна:
- Кой трябва да го използва? По избор за всички, задължително за администратори и служители или задължително за всички. Задължаването за всеки с административни права е често срещано. Вижте контрол на достъпа на базата на роли.
- Колко често потребителите въвеждат код? При всеки вход или веднъж на устройство за 30 дни („запомни това устройство“).
- Кои действия изискват нова проверка? Смяната на имейла, данните за плащане или изключването на 2FA са добри кандидати. Това се нарича step-up удостоверяване.
- Какъв е процесът при загубен телефон? Кодове за възстановяване и ръчен резервен вариант, който сте готови да поддържате.
Стъпка по стъпка: TOTP 2FA върху собствен вход
1. Съхранявайте правилните полета
Всеки потребител се нуждае от: дали 2FA е включено, TOTP тайната (криптирана в покой, не в обикновен текст), времето, в което е включено, и списък с кодове за възстановяване, съхранени хеширани, както паролите. Добавете място за броене на неуспешните опити.
2. Регистрация
- Потребителят отваря Настройки и натиска Включи двуфакторно удостоверяване.
- Сървърът генерира нова тайна и я връща като QR код, плюс текстовата версия за хората, които не могат да сканират.
- Потребителят я сканира в приложение за удостоверяване и въвежда текущия код.
- Сървърът проверява кода. Само ако е верен, записва тайната и маркира 2FA като включено.
- Приложението показва 8–10 кода за възстановяване веднъж и моли потребителя да ги запази.
Стъпка 4 е важна: включването на 2FA преди потвърждаване на код заключва всеки, чието сканиране не е успяло.
3. Вход с втора стъпка
- Потребителят въвежда имейл и парола. Сървърът ги проверява.
- Ако 2FA е включено, сървърът не създава пълна сесия. Вместо това създава краткотрайно състояние „вторият фактор е в очакване“.
- Приложението показва екрана за код. Сървърът проверява кода, като допуска малък прозорец за отклонение на часовника.
- Едва сега сървърът издава истинската сесия.
Всеки защитен маршрут и API крайна точка трябва да отхвърля състоянието „в очакване“. Екран за 2FA, който само скрива страници в браузъра, може да бъде заобиколен чрез директно извикване на API-то.
4. Ограничения и известия
Шестцифрен код има милион комбинации, което може да се познае без ограничения. Ограничете опитите, заключвайте втората стъпка за известно време след многократни неуспехи и изпращайте имейл на потребителя, когато това се случи. Вижте ограничаване на заявките и изпращане на имейли от приложението ви.
5. Възстановяване и изключване
- Кодът за възстановяване работи веднъж, след което се изтрива.
- Изключването на 2FA изисква паролата и актуален код или код за възстановяване.
- Регенерирането на кодовете за възстановяване анулира стария набор.
- Изпращайте имейл на потребителя всеки път, когато 2FA се включи или изключи.
Подсказки за вашия AI строител
Започнете с основния поток:
Добави незадължително двуфакторно удостоверяване с приложения за удостоверяване (TOTP) към съществуващия ни вход с имейл и парола. Използвай широко известна TOTP библиотека, не пиши алгоритъма сам. В Настройките покажи QR код и текстовата тайна и включвай 2FA едва след като потребителят въведе валиден код. Съхранявай тайната криптирана и никога не я показвай отново след настройката. Покажи 10 еднократни кода за възстановяване веднъж и ги съхрани хеширани.
След това налагането, където генерираният код най-често не стига:
Наложи 2FA на сървъра. След вярна парола потребителите с включено 2FA получават краткотрайно състояние „в очакване“, а не пълна сесия. Всяка защитена страница и API маршрут трябва да отхвърля състоянието „в очакване“. Ограничи опитите за код до 5, след това заключи втората стъпка за 15 минути и изпрати имейл на потребителя.
След това политиката:
Изисквай 2FA за администраторските акаунти: администратор без 2FA се праща към настройката и не може да достигне таблото, докато не я завърши. Изисквай паролата и актуален код, за да изключиш 2FA или да смениш имейла на акаунта. Изпращай имейл на потребителя, когато 2FA се включи или изключи.
Накрая помолете агента да обясни какво е построил:
Изброй всеки маршрут, който проверява за завършен втори фактор, къде се съхраняват TOTP тайната и кодовете за възстановяване и как са защитени.
Чести грешки
- Сесия, издадена след паролата. Най-сериозният проблем. Ако пълната сесия съществува, преди кодът да е проверен, 2FA е само декорация. Тествайте, като извикате защитено API само след стъпката с паролата.
- Без ограничение на опитите. Неограничените опити правят кода податлив на груба сила.
- Тайни или кодове за възстановяване в обикновен текст. Изтичане на базата данни тогава предава вторите фактори на всички.
- Включване преди проверка. Потребителите, които са сканирали грешно, се заключват при следващия вход.
- Няма път за възстановяване. Всеки изгубен телефон става заявка към поддръжката или загубен клиент.
- Лесно изключване. Ако открадната сесия може да изключи 2FA без код, защитата е премахната.
- Кодове и тайни в логове. Уверете се, че кодовете и тайните никога не се появяват в сървърните логове или в съобщенията за грешки.
- Проверка само на страницата за вход. Възстановяването на парола, входът с „магическа връзка“ и всеки вход през социална мрежа също трябва да спазват 2FA, иначе стават начин да се заобиколи.
Списък за тестване
- Регистрацията се завършва само след валиден код
- Вход с вярна парола, но без код, не дава достъп до нито една защитена страница или API
- Грешен код се отхвърля; многократните грешни кодове задействат блокировката и имейл
- Код отпреди няколко минути се отхвърля
- Всеки код за възстановяване работи точно веднъж
- Изключването на 2FA изисква паролата и актуален код
- Възстановяването на парола не заобикаля 2FA
- Администраторите без 2FA не могат да достигнат административните страници (ако е задължително)
- Тайните и кодовете за възстановяване са криптирани или хеширани в базата данни
- В логовете не се появяват кодове или тайни
Изпълнете и пълния контролен списък за сигурност на приложения, изградени с AI преди пускане.
Добавяне на 2FA в Mythex
Mythex не включва вграден вход за крайните потребители на приложението ви, така че 2FA е част от подхода за автентикация, който избирате: собствен вход с имейл и парола, използващ базата данни на проекта, или хостиран доставчик с поддръжка на многофакторно удостоверяване. Описвате какво искате в чата, като използвате подсказки като горните, а ключовете на доставчика отиват в тайните на проекта (през /secrets, настройките на проекта или картата с тайни, която агентът показва), а не в полето за съобщения. Рецептата Добавяне на вход в приложението ви в документацията има стартова подсказка, а Сигурност за приложенията, които строите обхваща навиците около ключовете и правата. След като агентът завърши, тествайте всяка точка от списъка в Preview, преди да публикувате.
Въпроси
Кой е най-лесният начин да добавя двуфакторно удостоверяване към приложение?
Ако използвате хостиран доставчик на автентикация, включете вградената му опция за многофакторно удостоверяване. Обикновено това изисква най-малко код. Ако управлявате собствен вход, добавете кодове от приложение за удостоверяване (TOTP) с известна библиотека, плюс кодове за възстановяване и проверка на сървъра.
Трябва ли да използвам SMS кодове за 2FA?
SMS е по-добре от никакъв втори фактор, но е най-слабата често срещана опция, защото съобщенията могат да се пренасочат чрез SIM подмяна, а кодовете могат да бъдат изманипулирани чрез фишинг. Предлагайте приложение за удостоверяване като основен вариант и passkeys, ако потребителите ви са готови за тях.
Нужна ли ми е база данни, за да добавя 2FA?
Ако управлявате собствен вход, да. Тайната на 2FA на всеки потребител, дали 2FA е включено и хешираните му кодове за възстановяване трябва да се съхраняват някъде, където сървърът ви може да провери. Хостираният доставчик на автентикация ги съхранява вместо вас.
Какво става, ако потребител загуби телефона си?
Влиза с един от еднократните кодове за възстановяване, които сте му показали, когато е включил 2FA, и след това настройва 2FA отново на новото устройство. Без кодове за възстановяване ви трябва ръчна проверка на самоличността, затова решете процеса преди пускане.