ईमेल से one-time code भेजना पासवर्ड से भी बदतर है
(blog.danielh.cc)- हाल के समय में कई सेवाओं ने ईमेल या फोन नंबर आधारित 6-अंकीय कोड लॉगिन तरीका अपनाया है
- ईमेल/फोन नंबर दर्ज करने पर 6-अंकीय verification code भेजा जाता है, और उसे दर्ज करके लॉगिन किया जाता है
- यह तरीका अकाउंट सुरक्षा में गंभीर कमजोरियां पैदा करता है
- हमलावर सिर्फ किसी और का ईमेल पता किसी वैध सेवा में दर्ज करके verification code भेजने का अनुरोध कर सकता है
- उपयोगकर्ता के लिए यह समझना आसान नहीं होता कि मिला हुआ verification code वास्तव में सही उपयोग के लिए है या phishing की कोशिश है
- Password manager जैसे मौजूदा phishing-रोधी टूल प्रभावी नहीं रहते
- इस authentication code तरीके का वास्तविक दुरुपयोग लगातार सामने आ रहा है
- Microsoft द्वारा संचालित Minecraft अकाउंट लॉगिन में भी इसी तरह का तरीका इस्तेमाल हो रहा है
- Reddit, YouTube जैसी कई online community और media में कई अकाउंट चोरी के मामले रिपोर्ट हुए हैं
निष्कर्ष
6-अंकीय code ईमेल authentication तरीका सुरक्षा के लिहाज से अनुमान से कहीं अधिक कमजोर है
- पारंपरिक password तरीके की तुलना में phishing का जोखिम काफी बढ़ जाता है
- user experience सुधारने या सुरक्षा के लिए अपनाया गया यह तरीका असल में और खराब नतीजे पैदा कर सकता है
3 टिप्पणियां
मुझे इससे खास सहमति नहीं है, क्योंकि यह ऐसा ट्रिक लगता है जो सिर्फ बहुत ही खास परिस्थितियों में ही काम करता है।
Passkey इस्तेमाल करते-करते अगर डिवाइस खो जाए, तो सच में बड़ी मुश्किल हो सकती है...
Hacker News की राय
हमले का पैटर्न कुछ इस तरह होता है
1) उपयोगकर्ता किसी धोखाधड़ी वाली साइट पर साइन अप करता है
2) वह साइट कहती है, “GOOD साइट ने लॉगिन कोड ईमेल से भेजा है, कृपया उसे दर्ज करें”
3) धोखाधड़ी वाली साइट, उपयोगकर्ता के ईमेल पर GOOD साइट की “ईमेल से one-time code द्वारा लॉगिन” प्रक्रिया शुरू कर देती है
4) GOOD साइट लॉगिन कोड उपयोगकर्ता को ईमेल कर देती है
5) उपयोगकर्ता यह देखकर कि ईमेल GOOD से आया है, उस पर भरोसा करके कोड दर्ज कर देता है
6) उपयोगकर्ता वह कोड धोखाधड़ी वाली साइट में दर्ज करता है
7) धोखाधड़ी वाली साइट उसी कोड से GOOD साइट में उपयोगकर्ता बनकर लॉगिन कर लेती है
इसी वजह से “ईमेल से one-time code भेजने” वाला authentication phishing हमलों के लिए बहुत असुरक्षित है
“ईमेल के भीतर लिंक पर क्लिक” वाला तरीका थोड़ा बेहतर है, क्योंकि उपयोगकर्ता सीधे GOOD साइट पर पहुँचता है और उस लिंक को कॉपी-पेस्ट करके धोखाधड़ी वाली साइट में डालना अधिक झंझटभरा और संदिग्ध लगता है
लेकिन, अगर कोई लोकप्रिय ईमेल सेवा अचानक लॉगिन ईमेल या लिंक को ही ब्लॉक करना शुरू कर दे, तो बहुत से उपयोगकर्ता लॉगिन ही नहीं कर पाएँगे
Passkeys सबसे सही तरीका है
password manager में passkey support लगातार बेहतर होता जा रहा है
अगर passkey सहेजने वाला डिवाइस खो भी जाए और सारे passkeys चले जाएँ, तब भी यह पुराने password सिस्टम से कहीं अधिक सुरक्षित है, इस पर मुझे यक़ीन है
मुझे लगता है कि दादी को account access के लिए बैंक जाना पड़े, यह उससे बेहतर है कि कोई phishing करके उनकी सारी रकम चुरा ले
Passkeys की समस्या “डिवाइस खोने पर access खो जाना” से भी अधिक जटिल है (और settings के आधार पर डिवाइस खोने पर भी समाधान हो सकता है)
सबसे बड़ी समस्या Attestation है
इससे services को यह छूट मिलती है कि वे ऐसे लोगों को ब्लॉक कर सकें जो उपयोगकर्ता स्वतंत्रता बढ़ाने वाले tools का इस्तेमाल करते हैं (जैसे open source authentication solutions आदि)
Passkeys या challenge-response protocol, मूल रूप से password का बहुत बड़ा और बेहतर विकल्प बन सकते थे
लेकिन हक़ीक़त में इन्हें इस तरह डिज़ाइन किया गया है कि BigTech का प्रभुत्व और मज़बूत हो और उपयोगकर्ता की स्वतंत्रता कम हो
“दादी का account recover कराने के लिए बैंक जाना बेहतर है” वाली बात पर
ज़रा यह भी सोचिए कि अगर किसी को बंदूक दिखाकर account unlock कराया जाए और सारा पैसा लूट लिया जाए, तो फिर क्या होगा
जिस तीसरी दुनिया के देश में मैं रहता हूँ, वहाँ smartphone लूट की समस्या इतनी गंभीर है कि 2FA भी व्यावहारिक नहीं लगता
मैंने एक बार 2FA recovery की थी, वह किसी नरक से कम नहीं था
password के मामले में तो कहीं से भी Bitwarden खोलकर काम हो जाता था
मैंने github पर Passkey सेट किया था, और यह भी पुष्टि की थी कि वह Chrome में सेव है
लेकिन github में passkey से लॉगिन करने पर Chrome एक popup दिखाता है कि Google Password Manager PIN दर्ज करें
मुझे नहीं पता यह PIN क्या है, और इसे reset करने का कोई तरीका भी नहीं मिल रहा
Google profile, password manager, या security settings कहीं भी इस PIN के बारे में कोई जानकारी नहीं है
“दादी बैंक जाकर account recover कर लें, यह ठीक है” वाली राय पर
मैं खुद बैंक या कंपनी के IT helpdesk जाकर account recover करा सकता हूँ,
लेकिन Google·Facebook·Xitter के मुख्यालय जाकर ऐसा नहीं कर सकता
device-bound passkeys में ऐसे मामलों में गड़बड़ी होने की संभावना बहुत अधिक है
ज़्यादातर उपयोगकर्ता ऐसी स्थितियों के बारे में सोचते ही नहीं
केवल Passkeys काफ़ी नहीं हैं
बात यह है कि हमें पुरानी गलतियाँ दोहरानी नहीं चाहिए
password manager डिफ़ॉल्ट होना चाहिए, और dedicated MFA सिर्फ़ वास्तव में अपवाद वाले मामलों में होना चाहिए (जैसे ईमेल account, financial accounts आदि)
मेरा मानना है कि MFA सेटअप में कम से कम 3 तरीके अनिवार्य रूप से सेट कराने चाहिए, और उनमें से 2 या अधिक का उपयोग करना चाहिए
अगर printed codes, OS-independent authenticator apps, yubikey जैसी hardware keys, और लगभग सभी तरीके support नहीं होते, तो वह MFA किसी काम का नहीं
मुझे दिन में चार बार Microsoft account password reset request के alert emails मिलते हैं
वे 6 अंकों वाले नंबर का ईमेल होते हैं, जिनसे account recover किया जा सकता है
यानी हमलावर को हर दिन 1,000,000 में 1 संभावना के साथ मेरा account hijack करने की 4 कोशिशें मुफ्त में मिलती हैं
अगर यही चीज़ हज़ारों accounts पर आज़माई जाए, तो रोज़ कुछ accounts मुफ्त में टूट सकते हैं
मैंने इस पर security report भी दर्ज की, लेकिन उन्होंने कहा कि गणितीय रूप से vulnerability का प्रमाण पर्याप्त नहीं है, इसलिए कार्रवाई से इनकार कर दिया गया
अब बस spam झेलते हुए यही दुआ की जा सकती है कि account न टूटे
मैंने login alias जोड़कर इसका समाधान किया
लॉगिन के समय पुराना account email (जो public था) ब्लॉक कर दिया, और अब सिर्फ़ private random string वाला alias ही लॉगिन के लिए काम करता है
उसके बाद से एक भी external login attempt नहीं हुआ
[सेटिंग का तरीका: account.microsoft.com > मेरी जानकारी > login preferences > ईमेल जोड़ें > alias जोड़कर default सेट करें > login preferences में केवल alias की अनुमति चुनें]
मेरा भी बिल्कुल यही अनुभव रहा
मुझे लगता है शायद यह तब से है जब मुझे Microsoft Teams इस्तेमाल करना पड़ा था
अगर हमलावर 125,000 accounts पर यह तरीका इस्तेमाल करे, तो औसतन रोज़ एक account हाथ लग सकता है
अगर किसी एक खास account को लक्ष्य न बनाकर पूरे समूह पर कोशिश की जाए, तो समय के हिसाब से यह काफ़ी असरदार है
इसे ठीक करने के लिए 4 तयशुदा कोशिशों की सीमा के बजाय हर असफलता पर प्रतीक्षा समय बढ़ाने वाला exponential backoff लागू करना चाहिए
मुझे भी Instagram के एक पुराने account पर ऐसे ही संदेश लगातार मिलते हैं
“क्या लॉगिन में समस्या हो रही है? password बदलने के लिए यहाँ क्लिक करें!”
मेरे एक पुराने बेकार account के साथ भी यही हुआ
लॉगिन की कोशिश करने वाले IP addresses देखे तो वे दुनिया भर के कई ISP से आ रहे थे, और अधिकांश अलग-अलग /16 networks से थे
जब ऐसे “बेकार” account पर भी botnet लगाया जा रहा है, तो जिन लोगों पर वास्तव में खतरा है उनकी स्थिति कितनी गंभीर होगी, यह सोचकर चिंता होती है
2FA जोड़ते ही समस्या पूरी तरह खत्म हो गई
अब तक समझ नहीं आया कि उन्हें 6 अंकों वाले कोड वाला लॉगिन flow शुरू में मिला कैसे (क्योंकि मेरे लिए तो हर बार password के बाद सीधे लॉगिन हो जाता था)
फिर भी 2FA जोड़ने के बाद मैंने एक भी अतिरिक्त कोशिश नहीं देखी
2FA codes भी मैं password manager में ही रखता हूँ
Microsoft का अपने आप बना 6 अंकों वाला (अंग्रेज़ी भी नहीं, सिर्फ़ नंबर!) “password” अब उन पर हमला नहीं किया जा सकता, इससे मैं संतुष्ट हूँ
सबसे बुरी बात यह है कि ऐसे authentication तरीके उपयोगकर्ताओं की आदतें और अपेक्षाएँ और भी खराब बना देते हैं
अगर आप 1password जैसा आधुनिक password manager इस्तेमाल करते हैं, तो यह ईमेल token वाले तरीके से कहीं आसान, सुरक्षित और तेज़ है
बस कुछ डिवाइसों पर शुरुआती setup और verification का थोड़ा ध्यान रखना होता है
जैसे नए घर में आकर दरवाज़े की चाबी की कॉपी बनवाते हैं, वैसे ही password manager में सेव करने के बाद दूसरे डिवाइसों में sync भी हुआ या नहीं, यह जाँच लेना चाहिए
लोग यह कर सकते हैं
encryption या 2FA की अवधारणा जाने बिना भी, बस “नया password बनाएँ” पर क्लिक करना है और app द्वारा सेव किया गया random password इस्तेमाल करना है
passkeys के साथ भी यही बात है, बस इन्हें डिवाइस के built-in storage में नहीं बल्कि backup/recovery को ध्यान में रखकर इस्तेमाल करना चाहिए
विडंबना यह है कि पुराना तरीका (ईमेल और password दर्ज करना) ही कभी-कभी ज़्यादा अच्छा काम करता है
password manager तुरंत autofill कर देता है, इसलिए व्यवहार में यह काफ़ी तेज़ होता है
passkeys इससे भी तेज़ हो सकते हैं
मुझे भी निराशा होती है, लेकिन मेरे आसपास गैर-IT काम करने वाले लगभग 80% लोग security के मामले में अनभिज्ञ हैं और जैसे हार मानकर जीते हैं
जो थोड़ी सफलता मिली, वह बस इतनी कि वे account जानकारी एक छोटी नोटबुक में लिख लें, और password में अंक व अंग्रेज़ी अक्षर ज़रूर हों
मैं इस flow की समस्या समझता हूँ
मेरे अनुभव में यह one-time password तरीका मेरे आसपास के गैर-IT लोगों के लिए password के बाद दूसरा सबसे परिचित authentication है
जहाँ मैं रहता हूँ, उस छोटे शहर में password manager या passkeys इससे कहीं अधिक उलझाऊ लगते हैं, और सामने बैठकर समझाने पर भी लोग उसे कभी नहीं समझ पाते
उनकी mental model ही इसके लिए बहुत अपरिचित है, और UX भी इतना जटिल है कि समझ से बाहर है
जब तक आम लोग सहज रूप से समझ सकें ऐसा कुछ नहीं आता, तब तक password और “समस्याग्रस्त” one-time code वाला तरीका अपनी सादगी के कारण मुख्यधारा में बना रहेगा
भले ही सही password इस्तेमाल किया जाए, account recovery का तरीका “password भूल जाने” पर अक्सर यही one-time code पैटर्न होता है
अंत में हमलावर अगर “मैं password भूल गया” जैसा व्यवहार करे, तो उसी recovery flow से लॉगिन कर सकता है
मैं भी अपनी बनाई service के लिए one-time code लॉगिन इस्तेमाल करता हूँ
लेकिन वह कोई संवेदनशील service नहीं है, इसलिए कड़ा authentication मेरा उद्देश्य नहीं है
मैं इसे ICGAFAS (“I Couldn't Give A Factor” Auth System) भी कहता हूँ, यानी शुरुआत से ही security की बहुत परवाह नहीं है
ईमेल-आधारित authentication में admin के नज़रिए से भी SMTP sending/delivery जैसी कई चीज़ों का ध्यान रखना पड़ता है
आखिरकार blacklist या spam filter में फँसने से बचने के लिए 3rd party relay service का इस्तेमाल करना पड़ता है
यह बहुत खीझ पैदा करने वाली बात है कि ज़्यादातर services पुराने email+PW या social login के बजाय यही one-time code तरीका थोप रही हैं
मैं तो बस अपना 100-character password इस्तेमाल करना चाहता हूँ
आप target user नहीं हैं
बल्कि आप एक बहुत ही असामान्य अल्पसंख्यक समूह में आते हैं
लंबी अवधि में हमें ऐसे समाधान के बारे में सोचना चाहिए जो “बहुसंख्यक” तक पहुँच सकें
100-character जैसे लंबे passwords का कोई ख़ास मतलब नहीं है
नीचे cryptography में वास्तव में इस्तेमाल होने वाली key length के अनुसार उनकी लंबाई truncate हो जाती है
मैंने जाँचकर देखा कि क्या NIST दस्तावेज़ (NIST 800-63b section 5.1.2.1) में ऐसे authentication को आधिकारिक तौर पर अनुमति है
अगर इसे “Look-up Secret Authenticator” माना जाए, तो इसमें कोई विशेष समस्या नहीं दिखती
मूल रूप से यह तरीका पहले से बाँटे गए authentication codes (जैसे recovery codes) के लिए था, लेकिन अब इसका दुरुपयोग real-time delivery और single choice के रूप में हो रहा है
मुझे लगता है कि यह phishing के प्रति कमज़ोर है, लेकिन यह साफ़-साफ़ कहना भी कठिन है कि यह पारंपरिक username/password से ज़्यादा खतरनाक है
उदाहरण के लिए, अगर उपयोगकर्ता के ईमेल पर 6 अंकों का कोड भेजकर उससे दर्ज करने को कहा जाए, तो उपयोगकर्ता यह नहीं जान सकता कि वह असली कोड है या नकली
हाँ, हमलावर Google account जैसी दिखने वाली नकली page बनाकर उपयोगकर्ता को धोखा देकर जानकारी छीन सकता है
अंततः मुझे लगता है कि phishing-resistant authentication ही असली भविष्य है
मुझे आज अचानक ऐसे authentication चक्र में फँसना पड़ा, इसलिए gofundme account हटाना पड़ा
मैंने कई वर्षों तक account इस्तेमाल किया और donations भी किए, लेकिन अब वह phone number और MFA code अनिवार्य रूप से माँगता है और मना करने का कोई विकल्प नहीं देता
अंत में सारी प्रक्रिया पूरी करके account deactivate कर दिया
मुझे लगता है ऐसा authentication जीवन में अनावश्यक है, gofundme के बिना भी जिया जा सकता है
आजकल मैं घर ढूँढ़ रहा हूँ, और Zillow app भी यही करती है: लॉगिन माँगती है, और मिले हुए संदेश पढ़ने के लिए भी हर बार MFA माँगती है
एक घंटे में session expire हो जाता है
मैं ऐसे authentication से तंग आ चुका हूँ
यह बिल्कुल पागल दुनिया है
Ticketmaster भी कुछ ऐसा ही करता है
वह Google Voice नंबर स्वीकार नहीं करता, सिर्फ़ SIM से जुड़े नंबर ही माँगता है
मेरा SIM नंबर तो बस एक अक्सर बदलने वाली “implementation detail” है, लेकिन अब उसके बिना account में लॉगिन ही नहीं किया जा सकता
नतीजा यह है कि या तो ऐसी ticketing छोड़ दो, या हर बार SIM बदलने पर account lockout का जोखिम लो
Google ने मेरे account पर खुद ही 2FA चालू कर दिया, और account में दर्ज phone number पुराना होने के कारण मैं पूरी तरह lock out हो गया हूँ
जब कोई service बिना किसी चेतावनी के password और secondary authentication बदल देती है, तो यात्रा के दौरान अगर account से जुड़ा phone साथ न हो, तो हमेशा के लिए access बंद हो सकता है
ज़्यादातर services मानती हैं कि secondary authentication मेरे 20-character random password (जो local password manager में सेव है) से अधिक सुरक्षित है
जबकि secondary authentication का मतलब अक्सर बस SMS में plain text भेजना, या ईमेल में plain text भेजना जैसी मामूली चीज़ें होता है
मैं यह वाक्य चार बार पढ़ने के बाद भी नहीं समझ पाया
मतलब कुछ ऐसा था: “अगर हमलावर उपयोगकर्ता का ईमेल पता वैध service पर भेजकर 6 अंकों का कोड माँगे, तो उपयोगकर्ता को यह पता नहीं चल सकता कि वह कोड असली लॉगिन के लिए है या नहीं”