Paano Magdagdag ng Two-Factor Authentication sa Iyong App
Para magdagdag ng two-factor authentication (2FA) sa app mo, hayaang ikabit ng mga user ang isang authenticator app sa pamamagitan ng pag-scan ng QR code, humingi ng anim na digit na code na ipinapakita nito pagkatapos ng password, at gumawa lang ng buong session sa server kapag tama ang code na iyon. Bigyan ang bawat user ng single-use na recovery codes kapag in-on nila ito, limitahan kung ilang code ang puwedeng hulaan ng isang tao, at hingin ang password kasama ang kasalukuyang code bago ma-off ang 2FA. Kung gumagamit ka ng hosted na auth provider, i-on ang built-in nitong multi-factor option sa halip na gumawa ng sarili.
Ipinapakita ng gabay na ito ang mga pagpipilian, ang eksaktong daloy, mga prompt na maibibigay mo sa AI builder, at ang mga pagkakamaling nagpapamukha sa 2FA na naroon pero walang silbi. Kung bago pa sa iyo ang konsepto, magsimula sa ano ang two-factor authentication.
Bago magsimula: kailangan mo ng gumaganang login
Nakapatong ang 2FA sa umiiral na sign-in. Kailangan mo muna ng isa sa mga ito:
- Sarili mong login, na may mga user at hashed na password na nakaimbak sa database ng app mo.
- Isang hosted na auth provider na namamahala ng mga user para sa iyo.
Kung wala ka pang alinman, magsimula sa paano magdagdag ng login sa app mo. Ipinapalagay ng natitirang bahagi ng gabay na ito na gumagana na ang hakbang ng password.
Piliin ang pangalawang factor mo
| Paraan | Pagsisikap ng user | Seguridad | Gastos sa pagpapatakbo | Magandang default? |
|---|---|---|---|---|
| Authenticator app (TOTP) | I-scan ang QR code minsan, mag-type ng code sa pag-login | Maganda; maaaring ma-phish kung hihingin ng pekeng site ang code | Libre | Oo, para sa karamihan ng app |
| Passkey o security key | I-tap o gamitin ang fingerprint | Pinakamalakas; lumalaban sa phishing | Libre | Oo, kung komportable ang mga user mo rito |
| Email code | Tingnan ang inbox sa pag-login | Kasing lakas lang ng email account | Gastos sa pagpapadala ng email | Bilang fallback lamang |
| SMS code | Maghintay ng text | Pinakamahina; SIM swapping at phishing | Bayad kada mensahe | Kung hindi talaga makagamit ng app ang mga user |
Ang TOTP ay nangangahulugang time-based one-time password, ang pamantayan (RFC 6238) na ginagamit ng mga authenticator app. Nagbabahagi ang server mo at ang telepono ng user ng isang secret; kapwa sila gumagawa ng parehong maikling code mula sa secret at sa kasalukuyang oras, karaniwang nagbabago kada 30 segundo. Walang kailangang network connection o SMS provider.
Ang passkeys ay pumapalit o sumusuporta sa password gamit ang cryptographic key na nakaimbak sa device ng user. Mas malakas ang mga ito pero mas maraming trabahong buuin nang mag-isa, kaya maraming app ang nagsisimula sa TOTP at nagdadagdag ng passkeys sa susunod, o kinukuha ang mga ito mula sa auth provider.
Buuin ito o i-on lang?
| Paraan | Mga kalamangan | Mga kahinaan |
|---|---|---|
| MFA ng hosted na auth provider | Mas kaunting code; pinapanatili ng provider ang mga detalye ng seguridad | Buwanang gastos kapag malaki na; nakadepende ka sa mga opsyon ng provider |
| Sarili mong TOTP gamit ang library | Buong kontrol; walang bayad kada user | Ikaw ang may-ari ng mga kaso sa gilid: lockout, recovery, pag-iimbak ng secret |
Tingnan sa kasalukuyang dokumentasyon ng provider mo kung aling mga factor ang sinusuportahan nito at sa aling mga plan. Alinman ang piliin, huwag kailanman isulat nang mag-isa ang math ng pagbuo ng code; gumamit ng malawakang ginagamit na library.
Pagpasyahan muna ang patakaran
Sagutin ang mga ito bago mag-prompt, dahil binabago nila ang disenyo:
- Sino ang dapat gumamit nito? Opsyonal para sa lahat, kinakailangan para sa mga admin at staff, o kinakailangan para sa lahat. Karaniwan ang pagiging kinakailangan para sa sinumang may admin na kapangyarihan. Tingnan ang role-based access control.
- Gaano kadalas kailangang mag-type muli ng code ang user? Sa bawat login, o minsan kada device sa loob ng 30 araw ("tandaan ang device na ito").
- Anong mga aksyon ang nangangailangan ng bagong pagkumpirma? Ang pagpapalit ng email, detalye ng payout, o pag-off ng 2FA ay magagandang kandidato. Tinatawag itong step-up authentication.
- Ano ang proseso kapag nawala ang telepono? Recovery codes, kasama ang manu-manong fallback na handa mong patakbuhin.
Hakbang-hakbang: TOTP 2FA sa sarili mong login
1. I-store ang tamang field
Kailangan ng bawat user: kung naka-on ang 2FA, ang TOTP secret (naka-encrypt sa pag-iimbak, hindi plain text), ang oras kung kailan ito in-on, at listahan ng recovery codes na naka-hash, tulad ng mga password. Magdagdag ng lugar para bilangin ang mga nabigong pagsubok.
2. Pag-enroll
- Binubuksan ng user ang Settings at ini-click ang Turn on two-factor authentication.
- Gumagawa ang server ng bagong secret at ibinabalik ito bilang QR code, kasama ang text na bersyon para sa mga hindi makapag-scan.
- Ini-scan ito ng user sa authenticator app at tina-type ang kasalukuyang code.
- Sinusuri ng server ang code. Kung tama lang ito, saka lang nito ise-save ang secret at mamarkahang naka-enable ang 2FA.
- Ipinapakita ng app ang 8–10 recovery codes nang minsan lang at hinihiling sa user na i-save ang mga ito.
Mahalaga ang hakbang 4: ang pag-on ng 2FA bago kumpirmahin ang code ay mai-lolock out ang sinumang nabigo ang scan.
3. Login na may pangalawang hakbang
- Isinusumite ng user ang email at password. Sinusuri ng server ang mga ito.
- Kung naka-enable ang 2FA, hindi gumagawa ang server ng buong session. Sa halip, gumagawa ito ng panandaliang estadong "naghihintay ng pangalawang factor".
- Ipinapakita ng app ang screen ng code. Sinusuri ng server ang code, na nagbibigay ng maliit na palugit para sa pag-anod ng orasan.
- Doon lang nag-iisyu ang server ng tunay na session.
Dapat tanggihan ng bawat protektadong route at API endpoint ang estadong naghihintay. Ang 2FA screen na nagtatago lang ng mga page sa browser ay malalampasan sa pamamagitan ng direktang pagtawag sa API.
4. Mga limitasyon at alerto
Ang anim na digit na code ay may isang milyong kombinasyon, na mahuhulaan kung walang limitasyon. Limitahan ang mga pagsubok, i-lock ang pangalawang hakbang sa loob ng isang panahon pagkatapos ng paulit-ulit na pagkabigo, at mag-email sa user kapag nangyari ito. Tingnan ang rate limiting at pagpapadala ng email mula sa app mo.
5. Recovery at pag-off
- Gumagana nang isang beses ang recovery code, tapos binubura.
- Ang pag-off ng 2FA ay nangangailangan ng password at ng kasalukuyang code o recovery code.
- Ang pag-regenerate ng recovery codes ay nagpapawalang-bisa sa lumang set.
- Mag-email sa user tuwing naka-on o naka-off ang 2FA.
Mga prompt na ibibigay sa AI builder mo
Magsimula sa pangunahing daloy:
Magdagdag ng opsyonal na two-factor authentication gamit ang authenticator apps (TOTP) sa kasalukuyang email at password login. Gumamit ng kilalang TOTP library, huwag isulat nang mag-isa ang algorithm. Sa Settings, ipakita ang QR code at ang text na secret, at i-enable lang ang 2FA pagkatapos mag-type ng wastong code ang user. I-store ang secret na naka-encrypt at huwag na itong ipakitang muli pagkatapos ng setup. Ipakita ang 10 single-use na recovery codes nang minsan at i-store ang mga ito na naka-hash.
Pagkatapos, ang enforcement, na kung saan pinakamadalas magkulang ang generated code:
Ipatupad ang 2FA sa server. Pagkatapos ng tamang password, ang mga user na may naka-enable na 2FA ay makakakuha ng panandaliang estadong naghihintay, hindi buong session. Dapat tanggihan ng bawat protektadong page at API route ang estadong naghihintay. Limitahan sa 5 ang mga pagsubok ng code, tapos i-lock ang pangalawang hakbang sa loob ng 15 minuto at mag-email sa user.
Pagkatapos, ang patakaran:
Kailanganin ang 2FA para sa mga admin account: ang admin na walang 2FA ay ipapadala sa setup at hindi makakapasok sa dashboard hangga't hindi ito tapos. Kailanganin ang password at kasalukuyang code para i-off ang 2FA o palitan ang email ng account. Mag-email sa user kapag naka-enable o naka-disable ang 2FA.
Sa huli, hilingin sa agent na ipaliwanag ang ginawa nito:
Ilista ang bawat route na tumitingin kung kumpleto na ang pangalawang factor, kung saan iniimbak ang TOTP secret at recovery codes, at kung paano ito pinoprotektahan.
Mga karaniwang pagkakamali
- Session na inisyu pagkatapos ng password. Ang pinakamalubhang bug. Kapag may buong session na bago pa suriin ang code, dekorasyon lang ang 2FA. Subukan sa pamamagitan ng pagtawag sa protektadong API pagkatapos lang ng hakbang ng password.
- Walang limitasyon sa pagsubok. Ang walang limitasyong hula ay ginagawang mabubuksan sa brute-force ang code.
- Plain-text na secret o recovery codes. Kapag tumagas ang database, naibibigay na ang second factor ng lahat.
- Pag-on bago beripikahin. Nalo-lock out ang mga user na nagkamali sa scan kapag nag-login sila sa susunod.
- Walang landas ng recovery. Bawat nawalang telepono ay nagiging support ticket o nawawalang customer.
- Madaling pag-off. Kung ang ninakaw na session ay makapag-o-off ng 2FA nang walang code, nawala na ang proteksyon.
- Mga code sa log. Tiyaking hindi kailanman lumalabas ang mga code at secret sa server log o error message.
- Pag-check lang sa login page. Ang password reset, "magic link" na sign-in at anumang social login ay dapat ding sumunod sa 2FA, kung hindi ay nagiging paraan ang mga ito para lampasan ito.
Checklist sa pagsubok
- Natatapos lang ang enrolment pagkatapos ng wastong code
- Ang login na may tamang password pero walang code ay walang access sa anumang protektadong page o API
- Tinatanggihan ang maling code; ang paulit-ulit na maling code ay nagti-trigger ng lockout at email
- Tinatanggihan ang code na ilang minuto na ang nakalipas
- Gumagana nang isang beses ang bawat recovery code
- Ang pag-off ng 2FA ay nangangailangan ng password at kasalukuyang code
- Hindi nalalampasan ng password reset ang 2FA
- Hindi maaabot ng mga admin na walang 2FA ang mga admin page (kung kinakailangan)
- Naka-encrypt o naka-hash ang mga secret at recovery codes sa database
- Walang lumalabas na code o secret sa mga log
Patakbuhin din ang buong security checklist para sa mga app na ginawa gamit ang AI bago mag-launch.
Pagdaragdag ng 2FA sa Mythex
Wala kang makukuhang built-in na sistema ng login para sa mga end user ng app mo sa Mythex, kaya bahagi ang 2FA ng anumang auth approach na pipiliin mo: sarili mong email-and-password login gamit ang database ng project, o isang hosted na provider na may multi-factor support. Inilalarawan mo ang gusto mo sa chat gamit ang mga prompt na tulad ng nasa itaas, at ang anumang provider key ay nasa project secrets (sa pamamagitan ng /secrets, project settings o secrets card na ipinapakita ng agent) at hindi sa message box. Ang docs recipe na Magdagdag ng login sa app mo ay may starter prompt, at sakop ng Security para sa mga app na ginawa mo ang mga gawi tungkol sa keys at permiso. Pagkatapos tapusin ng agent, subukan ang bawat item sa checklist sa Preview bago mag-publish.
Mga tanong
Ano ang pinakamadaling paraan para magdagdag ng two-factor authentication sa app?
Kung gumagamit ka ng hosted na auth provider, i-on ang built-in nitong multi-factor option; kadalasan ito ang pinakakaunting code. Kung sarili mo ang login, magdagdag ng authenticator-app codes (TOTP) gamit ang kilalang library, kasama ang recovery codes at server-side na check.
Dapat ba akong gumamit ng SMS codes para sa 2FA?
Mas mabuti ang SMS kaysa walang pangalawang factor, pero ito ang pinakamahinang karaniwang opsyon dahil maaaring ilihis ang mga text sa pamamagitan ng SIM swapping at maaaring ma-phish ang mga code. Mag-alok ng authenticator app bilang default, at passkeys kung handa na ang mga user mo para dito.
Kailangan ko ba ng database para magdagdag ng 2FA?
Kung sarili mo ang login, oo. Kailangang may lugar na mahahanap ng server mo ang 2FA secret ng bawat user, kung naka-on ang 2FA, at ang hashed nilang recovery codes. Iniimbak ito para sa iyo ng hosted na auth provider.
Ano ang mangyayari kapag nawala ng user ang telepono niya?
Mag-sign in siya gamit ang isa sa mga single-use na recovery code na ipinakita mo noong i-on niya ang 2FA, tapos i-set up muli ang 2FA sa bagong device. Kapag walang recovery codes, kailangan mo ng manu-manong pagkumpirma ng pagkakakilanlan, kaya pagpasyahan ang prosesong iyon bago mag-launch.