अपने ऐप में Two-Factor Authentication कैसे जोड़ें

अपने ऐप में two-factor authentication (2FA) जोड़ने के लिए, users को QR code स्कैन करके एक authenticator app जोड़ने दें, पासवर्ड के बाद उसका दिखाया छह अंकों का code माँगें, और पूरा session तभी सर्वर पर बनाएँ जब वह code सही निकले। जब कोई इसे चालू करे तो हर user को single-use recovery codes दें, कोई कितने codes अनुमान से आज़मा सकता है, इसकी सीमा रखें, और 2FA बंद करने से पहले पासवर्ड के साथ एक मौजूदा code भी माँगें। अगर आप hosted auth provider इस्तेमाल करते हैं, तो अपना कुछ बनाने की बजाय उसका built-in multi-factor विकल्प चालू करें।

यह गाइड विकल्पों, ठीक प्रवाह, AI builder को दिए जा सकने वाले prompts, और उन गलतियों को समझाती है जिनसे 2FA दिखता तो है पर कुछ करता नहीं। अगर यह अवधारणा नई है, तो two-factor authentication क्या है से शुरू करें।

शुरू करने से पहले: आपको एक काम करने वाला login चाहिए

2FA किसी मौजूदा sign-in के ऊपर बैठता है। इनमें से एक पहले चाहिए:

• आपका अपना login, जिसमें users और hashed passwords आपके ऐप के database में रहते हैं।
• एक hosted auth provider, जो users को आपके लिए संभालता है।

अगर इनमें से कुछ भी अभी नहीं है, तो अपने ऐप में login कैसे जोड़ें से शुरू करें। इस गाइड का बाकी हिस्सा मानकर चलता है कि पासवर्ड वाला चरण पहले से काम करता है।

दूसरा factor चुनें

TOTP का मतलब है time-based one-time password, यानी वह मानक (RFC 6238) जिसे authenticator apps इस्तेमाल करते हैं। आपका सर्वर और user का फ़ोन एक secret साझा करते हैं; दोनों उसी secret और मौजूदा समय से एक ही छोटा code बनाते हैं, जो आमतौर पर हर 30 सेकंड में बदलता है। इसके लिए न network connection चाहिए, न SMS provider।

Passkeys पासवर्ड की जगह या उसके साथ user के डिवाइस पर रखी एक cryptographic key इस्तेमाल करते हैं। ये ज़्यादा मज़बूत हैं पर खुद बनाने में ज़्यादा काम लगता है, इसलिए कई ऐप्स TOTP से शुरू करते हैं और passkeys बाद में जोड़ते हैं, या उन्हें auth provider से लेते हैं।

खुद बनाएँ या चालू करें?

यह देखने के लिए अपने provider का मौजूदा documentation जाँचें कि वह कौन से factors सपोर्ट करता है और किस plan पर। दोनों ही सूरतों में code generation का गणित खुद कभी न लिखें; किसी व्यापक रूप से इस्तेमाल होने वाली library का इस्तेमाल करें।

पहले नीति तय करें

Prompt देने से पहले ये सवाल तय करें, क्योंकि ये डिज़ाइन बदल देते हैं:

1. इसे कौन इस्तेमाल करेगा? सबके लिए वैकल्पिक, admins और staff के लिए अनिवार्य, या सबके लिए अनिवार्य। जिसके पास admin अधिकार हों उसके लिए इसे अनिवार्य करना आम है। देखें role-based access control।
2. Users कितनी बार code दोबारा डालेंगे? हर login पर, या हर डिवाइस पर 30 दिन के लिए एक बार ("इस डिवाइस को याद रखें")।
3. किन कार्यों के लिए ताज़ा जाँच चाहिए? Email बदलना, भुगतान का विवरण, या 2FA बंद करना अच्छे उदाहरण हैं। इसे step-up authentication कहते हैं।
4. फ़ोन खोने की प्रक्रिया क्या है? Recovery codes, और साथ में एक मैनुअल fallback जिसे आप चलाने को तैयार हों।

चरण दर चरण: अपने login पर TOTP 2FA

1. सही fields सहेजें

हर user को चाहिए: 2FA चालू है या नहीं, TOTP secret (storage में encrypted, plain text नहीं), चालू होने का समय, और recovery codes की एक सूची जो पासवर्ड की तरह hashed रूप में सहेजी जाए। विफल प्रयासों की गिनती रखने की जगह भी जोड़ें।

2. नामांकन

1. User Settings खोलता है और Turn on two-factor authentication पर क्लिक करता है।
2. सर्वर एक नया secret बनाता है और उसे QR code के रूप में लौटाता है, साथ में उन लोगों के लिए text version जो स्कैन नहीं कर सकते।
3. User उसे authenticator app में स्कैन करता है और मौजूदा code टाइप करता है।
4. सर्वर code जाँचता है। केवल सही होने पर वह secret सहेजता है और 2FA को चालू मार्क करता है।
5. ऐप 8–10 recovery codes एक बार दिखाता है और user से उन्हें सहेजने को कहता है।

चरण 4 अहम है: code की पुष्टि से पहले 2FA चालू करने से जिसका स्कैन विफल हुआ उसका login हमेशा के लिए बंद हो सकता है।

3. दूसरे चरण के साथ login

1. User ईमेल और पासवर्ड भेजता है। सर्वर उन्हें जाँचता है।
2. अगर 2FA चालू है, तो सर्वर पूरा session नहीं बनाता। इसके बजाय वह एक अल्पकालिक "second factor pending" स्थिति बनाता है।
3. ऐप code वाली स्क्रीन दिखाता है। सर्वर code जाँचता है, घड़ी के थोड़े अंतर के लिए एक छोटी खिड़की की गुंजाइश रखते हुए।
4. केवल अब सर्वर असली session जारी करता है।

हर सुरक्षित route और API endpoint को pending स्थिति को अस्वीकार करना चाहिए। अगर 2FA स्क्रीन केवल browser में पेज छिपाती है, तो सीधे API call करके उसे छोड़ा जा सकता है।

4. सीमाएँ और अलर्ट

छह अंकों के code के एक लाख संयोजन होते हैं, इसलिए सीमा के बिना उसका अनुमान लगाया जा सकता है। प्रयासों की संख्या सीमित करें, बार-बार विफलता के बाद दूसरे चरण को कुछ समय के लिए lock करें, और ऐसा होने पर user को email भेजें। देखें rate limiting और अपने ऐप से emails भेजना।

5. Recovery और बंद करना

• Recovery code एक बार काम करता है, फिर हटा दिया जाता है।
• 2FA बंद करने के लिए पासवर्ड और मौजूदा code या recovery code दोनों चाहिए।
• Recovery codes दोबारा बनाने से पुराने सेट अमान्य हो जाते हैं।
• जब भी 2FA चालू या बंद हो, user को email भेजें।

अपने AI builder को दिए जाने वाले prompts

मुख्य प्रवाह से शुरू करें:

हमारे मौजूदा email और password login में authenticator apps (TOTP) का इस्तेमाल करके वैकल्पिक two-factor authentication जोड़ो। एक जानी-मानी TOTP library इस्तेमाल करो, algorithm खुद मत लिखो। Settings में QR code और text secret दिखाओ, और 2FA तभी चालू करो जब user एक सही code डाले। Secret को encrypted रूप में सहेजो और सेटअप के बाद उसे दोबारा कभी मत दिखाओ। 10 single-use recovery codes एक बार दिखाओ और उन्हें hashed रूप में सहेजो।

फिर लागू करना, जहाँ generated code सबसे ज़्यादा कम पड़ता है:

सर्वर पर 2FA लागू करो। सही पासवर्ड के बाद, जिन users का 2FA चालू है उन्हें पूरा session नहीं, बल्कि एक अल्पकालिक pending स्थिति मिले। हर सुरक्षित page और API route को pending स्थिति अस्वीकार करनी चाहिए। Code के प्रयास 5 तक सीमित करो, फिर दूसरे चरण को 15 मिनट के लिए lock करो और user को email भेजो।

फिर नीति:

Admin accounts के लिए 2FA अनिवार्य करो: जिस admin का 2FA नहीं है उसे setup पर भेजो, और जब तक वह पूरा न हो तब तक dashboard तक न पहुँचने दो। 2FA बंद करने या account email बदलने के लिए पासवर्ड और एक मौजूदा code माँगो। 2FA चालू या बंद होने पर user को email भेजो।

अंत में agent से समझाने को कहें कि उसने क्या बनाया:

हर route की सूची दो जो पूरा किया गया दूसरा factor जाँचता है, बताओ कि TOTP secret और recovery codes कहाँ सहेजे गए हैं, और वे कैसे सुरक्षित हैं।

आम गलतियाँ

• पासवर्ड के बाद session जारी करना। सबसे गंभीर bug। अगर code जाँचे जाने से पहले पूरा session मौजूद है, तो 2FA सिर्फ़ सजावट है। जाँचें: केवल पासवर्ड चरण के बाद कोई सुरक्षित API call करके देखें।
• प्रयासों की कोई सीमा नहीं। असीमित अनुमान से code को brute-force किया जा सकता है।
• Plain-text में secrets या recovery codes। Database लीक होने पर हर किसी का दूसरा factor सामने आ जाता है।
• जाँचने से पहले चालू करना। जिन users का स्कैन गलत हुआ, वे अगले login पर बाहर हो जाते हैं।
• कोई recovery रास्ता न होना। हर खोया फ़ोन एक support ticket या खोया हुआ ग्राहक बन जाता है।
• आसान बंद करना। अगर चुराया गया session बिना code के 2FA बंद कर सके, तो सुरक्षा ख़त्म।
• Logs में codes। सुनिश्चित करें कि codes और secrets कभी server logs या error messages में न दिखें।
• केवल login पेज पर जाँच। Password reset, "magic link" sign-in और कोई भी social login भी 2FA का सम्मान करें, वरना वे इसे बायपास करने का रास्ता बन जाते हैं।

टेस्टिंग चेकलिस्ट

• नामांकन तभी पूरा होता है जब सही code दिया जाए
• सही पासवर्ड पर लेकिन बिना code के login किसी सुरक्षित page या API तक पहुँच नहीं देता
• गलत code अस्वीकार होता है; बार-बार गलत codes से lockout और email होता है
• कुछ मिनट पुराना code अस्वीकार होता है
• हर recovery code ठीक एक बार काम करता है
• 2FA बंद करने के लिए पासवर्ड और मौजूदा code चाहिए
• Password reset 2FA को बायपास नहीं करता
• 2FA के बिना admins admin pages तक नहीं पहुँच सकते (अगर अनिवार्य हो)
• Secrets और recovery codes database में encrypted या hashed हैं
• Logs में कोई code या secret नहीं दिखता

लॉन्च से पहले AI से बने ऐप्स के लिए सुरक्षा चेकलिस्ट भी पूरी करें।

Mythex में 2FA जोड़ना

Mythex आपके ऐप के end users के लिए built-in login system शामिल नहीं करता, इसलिए 2FA उस auth तरीके का हिस्सा है जो आप चुनते हैं: प्रोजेक्ट के database का इस्तेमाल करने वाला आपका अपना email-और-password login, या multi-factor समर्थन वाला hosted provider। आप चैट में ऊपर जैसे prompts से बताते हैं कि आपको क्या चाहिए, और कोई भी provider keys संदेश बॉक्स में नहीं, बल्कि प्रोजेक्ट secrets में जाती हैं (/secrets के ज़रिए, प्रोजेक्ट settings से, या agent द्वारा दिखाए गए secrets card से)। Docs की recipe अपने ऐप में login जोड़ें में एक starter prompt है, और आपके बनाए ऐप्स के लिए सुरक्षा keys और permissions से जुड़ी आदतों को समझाता है। Agent के पूरा करने के बाद, publish करने से पहले Preview में चेकलिस्ट का हर बिंदु टेस्ट करें।

सवाल