Ano ang Two-Factor Authentication? Gabay sa Simpleng Salita
Ang two-factor authentication (2FA) ay login na humihingi ng dalawang magkaibang uri ng patunay na ikaw nga ang sinasabi mong ikaw — karaniwan ay may alam ka, gaya ng password, at may hawak ka, gaya ng telepono mo o security key. Kung nanakaw o nahulaan ng kriminal ang password mo, hindi pa rin siya makakapasok nang walang ikalawang factor. Isa ito sa pinakasimpleng paraan para protektahan ang mga account na mahalaga.
Bakit mahalaga ito kapag gumagawa ka gamit ang AI
Kapag humiling ka sa AI builder ng "login", karaniwang email at password ang makukuha mo. Magandang simula iyon, pero nagagamit muli, napapeke, at nalalabas ang mga password. Kung may mahalagang laman ang app mo — customer records, invoice, admin controls, payment settings — maaaring ilantad ng iisang nanakaw na password ang lahat ng iyon.
Nakakaapekto rin ang 2FA sa mga desisyong maaaring hindi mo pa naiisip sa simula:
- Sino ang dapat gumamit nito. Opsyonal para sa lahat, kinakailangan para sa mga admin, o kinakailangan para sa lahat?
- Aling mga paraan ang susuportahan mo. Codes mula sa app, text messages, passkeys, security keys.
- Ano ang mangyayari kapag na-lock out ang isang tao. Ang nawawalang telepono ang pinakakaraniwang support request para sa anumang app na may 2FA.
- Saan ito ipinatutupad. Dapat mangyari ang pagsusuri sa server. Ang 2FA screen na nagtatago lamang ng page sa browser ay maaaring lampasan.
Hindi mo kailangang buuin mismo ang cryptography — ang mga subok nang library at auth provider ang gumagawa niyon. Pero kailangan mong malaman kung ano ang hihilingin.
Isang pang-araw-araw na halimbawa
Isipin ang safe-deposit box ng bangko. Para mabuksan ito, kailangan mo ng ID mo (isang bagay na tinitingnan ng bangko kung ikaw o alam mo) at ang pisikal na susi (isang bagay na hawak mo). Ang magnanakaw na kinopya ang pirma mo ay wala pa ring susi. Ang magnanakaw na nakuha ang susi ay hindi pa rin makakalampas sa ID check.
Ganito rin ang 2FA. Ang password ang pirma; ang telepono o security key ang pisikal na susi. Hindi sapat ang alinman sa dalawa kung mag-isa.
Ang tatlong uri ng factor
Ang mga security standard, gaya ng digital identity guidelines ng US National Institute of Standards and Technology, ay pinagpapangkat ang mga factor sa tatlong uri:
| Factor | Mga halimbawa |
|---|---|
| Bagay na alam mo | Password, PIN |
| Bagay na hawak mo | Telepono na may authenticator app, security key, device na may hawak na passkey |
| Bagay na ikaw | Fingerprint, mukha — kadalasang ginagamit para i-unlock ang device na siyang gagawa ng aktuwal na pagsusuri |
Ang mahalagang salita ay magkaiba. Ang password kasama ang security question ay dalawang bagay na alam mo, kaya hindi ito tunay na two-factor authentication. Kung iisang leak lang ang maglalantad sa dalawa, isa lamang ang binibilang.
Paghahambing ng karaniwang paraan ng 2FA
| Paraan | Paano ito gumagana | Lakas | Mga tala |
|---|---|---|---|
| SMS code | Tine-text ang code sa numero ng telepono mo | Pinakamahina | Madaling maapektuhan ng SIM swapping at phishing, pero mas mabuti pa rin kaysa walang 2FA |
| Email code | Ine-email sa iyo ang code | Mahina | Kasing-ligtas lamang ng email account |
| Authenticator app (TOTP) | Gumagawa ang app gaya ng Google Authenticator ng bagong 6-digit na code, kadalasan kada 30 segundo | Maganda | Gumagana offline; maaari pa ring mapeke kung hihingin ng pekeng site ang code |
| Push approval | Nagtatanong ang app ng "Ikaw ba ito?" at pinipindot mo ang approve | Maganda | Bantayan ang "approve fatigue", kung saan pumipindot ng oo ang mga user para tumigil ang paulit-ulit na prompt |
| Passkey o security key | Ang cryptographic key sa device ang nagpapatunay na nasa tunay kang site | Pinakamalakas | Lumalaban sa phishing dahil hindi ito tutugon sa kamukhang domain |
Itinuturing ng gabay ng NIST na hindi phishing-resistant ang mga paraang tine-type mo ang code (SMS, email, authenticator apps), at minamarkahan ang pagpapadala ng code sa phone network bilang "restricted". Ang passkeys at hardware security keys, batay sa WebAuthn/FIDO2 standards, ang binibilang nitong phishing-resistant.
Praktikal na aral: ang authenticator app ay malakas at madaling default para sa karamihan ng app, at sulit ialok ang passkeys kung komportable ang mga user mo rito.
Isang halimbawa: 2FA para sa client portal
Ipagpalagay na gumawa ka ng portal kung saan nagbabahagi ang isang maliit na accounting firm ng mga dokumento sa buwis sa kanilang mga kliyente. Ganito gumagana ang maayos na setup ng 2FA, hakbang-hakbang.
Pag-on nito (enrolment). Binuksan ni Priya, isang kliyente, ang Settings at pinindot ang "Turn on two-factor authentication." Gumagawa ang app ng secret at ipinapakita ito bilang QR code. Ini-scan niya ito gamit ang authenticator app niya, na nagsisimulang magpakita ng six-digit na mga code. Ini-type niya pabalik sa portal ang kasalukuyang code para patunayang gumana ang setup. Ipinapakita ng app ang sampung recovery codes at hinihilingang itago ang mga ito sa ligtas na lugar.
Pag-log in pagkatapos.
- Inilagay ni Priya ang email at password niya. Sinusuri ito ng server.
- Sa halip na diretsong papasukin siya, minamarkahan ng server ang session bilang "tama ang password, nakabinbin ang ikalawang factor" at ipinapakita ang code screen.
- Ini-type niya ang code mula sa app niya. Sinusuri ito ng server laban sa nakaimbak na secret niya, na may kaunting palugit para sa clock drift.
- Saka pa lamang gagawa ang server ng buong session at papayagan siyang makita ang mga dokumento.
Ano ang nakikita ng attacker. Kung nalabas ang password ni Priya mula sa ibang site, maiipit ang attacker sa hakbang 3. Binibilang ang bawat maling pagtatangka sa code, at pagkatapos ng ilang maling subok, pansamantalang ila-lock ang account at makakatanggap si Priya ng email.
Pagkawala ng telepono. Gagamitin ni Priya ang isa sa recovery codes niya para mag-log in, ioff at ion muli ang 2FA gamit ang bagong telepono niya, at makakakuha ng bagong recovery codes. Hindi na kailanman magagamit ulit ang nagamit nang code.
Para sa staff. Nakikita ng mga accountant ng firm ang mga file ng bawat kliyente, kaya kinakailangan ng portal ang 2FA para sa staff accounts; hindi nila maabot ang dashboard hangga't hindi sila nakakapag-enroll.
Mga karaniwang termino
| Termino | Ibig sabihin |
|---|---|
| 2FA / MFA | Two-factor / multi-factor authentication: pag-log in gamit ang higit sa isang uri ng patunay. |
| Factor | Isang uri ng patunay: bagay na alam, hawak, o ikaw. |
| TOTP | Time-based one-time password — ang nagbabagong code sa authenticator apps. |
| Shared secret | Ang nakatagong value, na itinatakda sa pamamagitan ng QR code, na ginagamit ng app at ng telepono mo para makagawa ng magkatugmang code. |
| Recovery (backup) codes | Mga code na isang beses lamang gamitin para makapasok kapag nawala mo ang ikalawang factor. |
| Passkey | Credential sa pag-log in na nakaimbak sa device mo at gumagamit ng public-key cryptography sa halip na password. |
| Security key | Maliit na pisikal na device (USB o NFC) na gumagawa ng parehong trabaho ng passkey. |
| SIM swapping | Panlilinlang sa mobile carrier para ilipat ang numero ng isang tao sa bagong SIM, para mapunta sa attacker ang mga text. |
| Phishing | Pekeng site o mensahe na nanlilinlang sa mga tao para ibigay ang password o code. |
| Step-up authentication | Muling paghingi ng ikalawang factor bago ang sensitibong aksyon, gaya ng pagpapalit ng payout details. |
Mga karaniwang pagkakamali at maling akala
- "Ginagawang hindi mahahack ng 2FA ang account." Ginagawa nitong mas mahirap. Maaari pa ring makuha ng phishing sites ang na-type na code sa real time, kaya umiiral ang passkeys.
- Pagsusuri ng code sa browser lamang. Kung naglalabas ng buong session ang server pagkatapos ng password, dekorasyon lamang ang code screen. Dapat tumanggi ang server na magbigay ng access hangga't hindi pumapasa ang ikalawang factor.
- Walang limitasyon sa paghula ng code. Ang six-digit na code ay may isang milyong posibilidad. Kung walang rate limiting at lockouts, maaaring patuloy lang manghula ang attacker.
- Pagkalimot sa recovery. Kapag walang recovery codes, bawat nawalang telepono ay nagiging support ticket, o customer na na-lock out.
- Pag-iingat nang pabaya sa TOTP secret. Dapat naka-encrypt sa database ang shared secret, at hindi na ito ipinapakita pagkatapos ng setup.
- Pagpapahintulot sa mga user na i-off ang 2FA nang walang muling pagkumpirma. Ang pag-disable ng 2FA o pagpapalit ng email ay dapat humingi ng password at kasalukuyang code.
- Ang password kasama ang security question ay binibilang bilang 2FA. Hindi — parehong bagay na alam mo ang dalawa.
Ano ang hihilingin sa iyong AI builder
- "Magdagdag ng opsyonal na two-factor authentication gamit ang authenticator app (TOTP), na may QR code para sa setup at confirmation code bago ito i-on."
- "Magpakita ng sampung single-use recovery codes kapag naka-enable ang 2FA. Itago ang mga ito bilang hash, tulad ng mga password."
- "Ipatupad ang 2FA sa server: walang buong session hangga't hindi pumapasa ang ikalawang factor."
- "Limitahan ang mga pagtatangka sa code at i-lock ang login nang 15 minuto pagkatapos ng paulit-ulit na pagkabigo. Mag-email sa user kapag nangyari ito."
- "Kinakailangan ang 2FA para sa admin accounts."
- "Humingi ng password at kasalukuyang code bago i-disable ang 2FA o palitan ang account email."
- "Gumamit ng kilalang library o ang built-in na 2FA ng auth provider namin — huwag mong isulat mismo ang crypto."
- "Ipaliwanag kung aling paraan ang ginamit mo at kung saan nakaimbak ang mga secret."
Kung gumagamit ka ng hosted auth provider, tingnan kung may 2FA o passkeys na ito na; mas ligtas kadalasan ang pag-on ng built-in na feature kaysa custom na code. Ang hakbang-hakbang na bersyon ay nasa paano magdagdag ng two-factor authentication, at ipinaliliwanag ng ano ang authentication ang mga batayan ng login sa ilalim nito.
Two-factor authentication sa Mythex
Hindi kasama sa Mythex ang built-in na login system para sa mga user ng app mo, kaya bahagi ng 2FA ang anumang auth approach na piliin mo — ang sarili mong email-at-password login na nakasandal sa database ng project, o hosted provider na nag-aalok ng 2FA. Hihilingin mo sa agent na idagdag ito sa chat, at ilalagay ang anumang provider keys sa project secrets sa halip na sa mismong chat. Nasa docs recipe sa pagdaragdag ng login sa iyong app ang starter prompt na maaari mong iangkop, at saklaw ng seguridad para sa mga app na ginagawa mo ang mga gawi sa paligid ng mga key. Bago ilunsad, dumaan sa security checklist para sa mga app na gawa ng AI.
Mga tanong
Ano ang two-factor authentication sa simpleng salita?
Ang two-factor authentication (2FA) ay nangangahulugang dalawang magkaibang uri ng patunay ang kailangan sa pag-log in, karaniwan ay ang password mo at code mula sa telepono mo o security key. Ang magnanakaw na password lamang ang nakuha ay hindi pa rin makakapasok.
Pareho ba ang 2FA at MFA?
Halos oo. Ang multi-factor authentication (MFA) ay nangangahulugang dalawa o higit pang factor; ang two-factor authentication ang pinakakaraniwang kaso na eksaktong dalawa. Sa araw-araw na paggamit, pinagpapalit ang mga terminong ito.
Ligtas ba ang SMS two-factor authentication?
Mas mabuti ito kaysa password lamang, pero ito ang pinakamahinang karaniwang opsyon. Maaaring harangin o ilihis ang text messages sa pamamagitan ng SIM swapping, at maaaring malinlang ang mga tao ng pekeng login page na mag-type ng code. Mas malakas ang authenticator apps, at mas malakas pa ang passkeys o security keys.
Kailangan ba ng app ko ang two-factor authentication?
Kung may hawak na pera, pribadong data, o admin power sa ibang user ang mga account, magandang ideya ang mag-alok ng 2FA, at karaniwan ang paghingi nito sa mga admin. Para sa simpleng hobby app, maaari itong opsyonal o ipagpaliban.
Ano ang mangyayari kung mawala ng user ang telepono niya?
Para diyan ang recovery codes: maikling listahan ng isang beses lamang gamiting backup codes na ipinapakita kapag na-on ang 2FA. Kung wala ang mga ito, karaniwang kailangan ng manual na pagkumpirma ng pagkakakilanlan ng may-ari ng app, kaya planuhin ito bago ilunsad.