"ईमेल ही authentication है" पैटर्न

 (rubenerd.com)
4 पॉइंट द्वारा GN⁺ 2024-09-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ उपयोगकर्ता पासवर्ड याद रखने या मैनेज करने के बजाय, हर बार “पासवर्ड भूल गए” प्रक्रिया को ही लॉगिन के तरीके की तरह इस्तेमाल करते हैं
  • वास्तविक flow यह है कि लॉगिन पेज से recovery link ईमेल में लिया जाता है, अस्थायी पासवर्ड डाला जाता है, और अगली बार आने पर भी वही प्रक्रिया दोहराई जाती है
  • यह आदत किसी सचेत security strategy से ज़्यादा, समय के साथ जम चुके सीखे हुए व्यवहार के करीब है
  • password manager और 2-step·multi-factor authentication जैसे सुधार भी उपयोगकर्ता को security बढ़ने से ज़्यादा friction बढ़ने की तरह महसूस हो सकते हैं
  • system design को उपयोगकर्ता के बार-बार दोहराए जाने वाले व्यवहार को आधार मानना चाहिए, और उन्हें स्वाभाविक रूप से बेहतर उपयोग-पद्धति की ओर ले जाने की ज़रूरत है

लॉगिन की तरह इस्तेमाल होने वाली पासवर्ड recovery

  • कुछ उपयोगकर्ता online account में लॉगिन करते समय पासवर्ड दर्ज नहीं करते, बल्कि हर बार recovery प्रक्रिया दोहराते हैं
    • लॉगिन पेज पर पहुंचते हैं
    • “I forgot my password” पर क्लिक करते हैं
    • ईमेल पर जाते हैं
    • recovery link पर क्लिक करते हैं
    • ऐसा अस्थायी पासवर्ड दर्ज करते हैं जिसे वे याद नहीं रखेंगे
    • फिर बाद में वही प्रक्रिया दोहराते हैं
  • उनसे पूछा जाए कि वे ऐसा क्यों करते हैं, तो वे जवाब नहीं दे पाते या कहते हैं कि उन्होंने इस बारे में कभी सोचा ही नहीं
  • यह व्यवहार सुबह उठकर बनाई गई कोई लॉगिन strategy नहीं, बल्कि समय के साथ पक्का हो चुका दोहराव वाला क्रम है

सुरक्षा सुधार उपयोगकर्ता के लिए कैसी friction पैदा करते हैं

  • यह तरीका उपयोगकर्ता के लिए ऐसा कम-मेहनत वाला समाधान बन जाता है जिसमें उन्हें passphrase याद रखने की ज़रूरत नहीं पड़ती
  • password manager, पहचान की चोरी, 2-step authentication और multi-factor authentication, तथा username/password तरीके के पुराने पड़ने पर पहले ही काफी चर्चा हो चुकी है
  • बेहतर security प्रक्रियाएं अक्सर रुकावटें और friction बढ़ा देती हैं, इसलिए उपयोगकर्ता के लिए उन्हें स्वाभाविक रूप से अपनाना मुश्किल हो सकता है
  • डिजाइनरों को उपयोगकर्ता के सीखे हुए व्यवहार को ध्यान में रखकर ऐसा flow बनाना चाहिए, जिससे समय के साथ वे बेहतर उपयोग-पद्धति की ओर बढ़ सकें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-09
Hacker News की राय

  • ईमेल अकाउंट ऑनलाइन authentication में सबसे आम common denominator है। मोबाइल फोन भी मजबूत विकल्प है, लेकिन खो सकता है, और फोन नंबर ज्यादा आम व लंबे समय तक टिकने वाले होते हैं, पर उनका security level बड़े email providers के अकाउंट से काफी कम होता है
    अगर “इंटरनेट के लिए काल्पनिक authentication system” डिजाइन करना हो, तो पहले account recovery देखनी होगी। जब आपका शानदार authenticator खो जाए और जवाब “बस access नहीं मिलेगा” या “सहकर्मियों का panel आपकी पहचान की गारंटी देगा” हो, तो वह system इंसानों के लिए नहीं, बल्कि काल्पनिक बुद्धिमान जीवों को user मानकर ही चलेगा

    • यही कई सालों से blockchain/cryptocurrency के खिलाफ मेरा सबसे बड़ा कारण रहा है। “key खोई तो wallet भी खोया” वाला तरीका असली users से मूल रूप से मेल नहीं खाता
      इंसानों को गलतियों से recover कर पाने की जरूरत होती है
    • सरकार द्वारा जारी digital ID इस समस्या का बड़ा हिस्सा हल कर सकती है। इसकी अपनी समस्याएं होंगी, लेकिन व्यक्तिगत पहचान को सरकार के भरोसे छोड़ना Google जैसी कंपनियों के account lockout से ज्यादा मूल्यवान और कम जोखिमभरा लगता है
    • दुर्भाग्य से Google जैसे बड़े email providers में भी “बस access नहीं मिलेगा” एक आम pattern है। जिन लोगों के फोन खो गए या चोरी हो गए और वे अपने account से हमेशा के लिए lock out हो गए, वे इसे अच्छी तरह दिखाते हैं
    • “बड़े provider का email account” के साथ भी यह caveat जुड़ा है कि “बिना कारण account suspend कर दिया, appeal का कोई तरीका नहीं, और यह भी नहीं बताते कि suspend क्यों किया”
    • सहकर्मियों के panel द्वारा किसी व्यक्ति की पहचान की गारंटी देने का तरीका एक दिलचस्प design problem है। अगर कोई common system हो जो सही तरह से distributed authentication secrets को संबंधित पक्षों के निर्देश पर फिर से जोड़ सके, तो इसे काफी seamless बनाया जा सकता है
      क्या इसे सामान्य इंसानों के लिए भी काम करने लायक बनाया जा सकता है? मुझे लगता है कि इसे डिजाइन करने की पर्याप्त creativity मौजूद है

  • हमारी service काफी हल्के-फुल्के nature वाला business है, इसलिए users account सिर्फ सुविधा के लिए इस्तेमाल करते हैं। हमने जो तरीका अपनाया है, वह यह है: user email डालता है, हम email पर authentication code भेजते हैं, और user code डालता है तो हम एक बहुत लंबी cookie जारी करते हैं जिससे वह असल में अनिश्चित काल तक logged in रहता है
    मौजूदा account है या नहीं, यह महत्वपूर्ण नहीं; अगर नया email है तो नया account बना देते हैं। कभी-कभी कई emails वाले users गलती से नया account बना लेते हैं, लेकिन signup और login conversion rate काफी बेहतर हो गया, इसलिए यह स्वीकार्य है। code validity time और attempts की संख्या पर risk analysis चाहिए, और संभव हो तो lock mechanism इस्तेमाल करना अच्छा है। अगर service बहुत critical नहीं है, तो मैं यह strategy recommend करूंगा। iOS Mail भी अब Messages के one-time code feature की तरह इस तरीके को support करता है, इसलिए कुछ users के लिए यह काफी सुविधाजनक है

    • मेरे देखे data के हिसाब से यह तरीका e-commerce revenue को maximize करने में जबरदस्त रूप से बेहतर है
      खरीदार पर account थोपने के बजाय बस details मांगिए। वैसे भी browser autofill कर देता है। फिर order status check link email से भेज दीजिए, और अगले order पर फिर email पूछ लीजिए। अतिरिक्त friction से होने वाला revenue loss “registered user” पाने के फायदे से बड़ा होता है
    • मैं एक छोटा B2C app चला रहा हूं, जहां users सिर्फ email address से signup करते हैं और password field है ही नहीं। account बन जाता है और उस device पर वे अनिश्चित काल तक logged in रहते हैं
      दूसरे device से login करना हो तभी नया password मांगा जा सकता है। इससे signup friction और कमजोर passwords घटते हैं। ज्यादातर लोगों को वैसे भी दूसरे device से login करने की जरूरत बहुत कम पड़ती है
    • मैंने यह login तरीका कई बार implement किया है, और यह उस अनुभव से निकला है जिसमें “user account” क्या होता है, इस बारे में ढेर सारी assumptions हटानी पड़ीं। असल में funnel को दोनों पक्षों की इच्छा के अनुसार चलाना हो, तो ऐसी simplification जरूरी थी
      अगर यह anonymity बचाए रखने वाला क्षेत्र नहीं है, तो ऐसा किया जा सकता है, और बाद में passkeys integrate कर सकते हैं। कमी यह है कि password sharing असंभव हो जाती है, इसलिए एक account में कई users manage करने की समस्या पर पहले सोचना पड़ता है। लेकिन अगर इसे consciously handle किया जाए, तो funnel या user experience अंत में बेहतर होता है। security भी users के email providers के average security level से बंध जाती है, लेकिन आम तौर पर वह जरूरत से बेहतर ही होती है। password को बाद में जरूरत पड़ने पर second factor के रूप में इस्तेमाल किया जा सकता है या कोई दूसरा factor जोड़ा जा सकता है, और B2B हो तो सीधे SAML या OIDC पर जा सकते हैं। B2B या D2C में यह हमेशा अच्छी तरह काम करता रहा, और edge cases acquisition benefit की वजह से solve करने लायक थे
    • मैंने ऐसा login तरीका देखा है; क्या email में ऐसा link नहीं भेज सकते जो app home पर ले जाए और user पहले से logged in हो?
      code copy करना, login page खुली हुई tab ढूंढना, और paste करना झंझट भरा है
    • मैंने लगभग single form जैसी छोटी CRUD app में यह तरीका इस्तेमाल किया था, और campaign के दौरान support requests लगभग 0 के करीब रहीं, इसलिए यह काफी valuable था

  • इस स्तर पर तो email address पर one-time URL link भेजकर एक click में login क्यों न करा दें? 10 मिनट में expire हो और one-time इस्तेमाल के बाद discard हो जाए
    बेशक link जिसके पास पहले पहुंचेगा, वह account में login कर सकता है, लेकिन access वैसे भी email से ही संभव है। email account से अधिक security की भावना सब खत्म हो जाती है, लेकिन reality पहले ही वहीं पहुंच चुकी है। अगर mobile message में “login authenticate करने के लिए click करें: www.someurl.com?p=134234535” जैसा pattern इस्तेमाल करें, तो यह ऐसा two-factor authentication बन जाता है जिसमें बेवकूफी से code enter नहीं करना पड़ता

    • कई web apps में यह तरीका इस्तेमाल हो रहा है, लेकिन users के लिए confusing है (“मेरा account पहले से क्यों है? मैंने तो signup किया ही नहीं!”), cost भी आती है (email भेजना free नहीं है), और यह slow भी है
      email spam में चला जाता है, या greylisting की वजह से लोग घंटों login नहीं कर पाते, या पहुंचने में 1 मिनट लगता है और कभी-कभी वह भी बहुत लंबा महसूस होता है। इसे recommend करना चाहिए या नहीं, मुझे पक्का नहीं
    • जो sites सिर्फ यही तरीका देती हैं और 30 seconds में email नहीं भेज पातीं, वे मुझे सचमुच नापसंद हैं
      mobile पर भेजे जाने वाले “login authenticate करने के लिए click” में code और link दोनों देने चाहिए। हमेशा login करने वाला device mobile नहीं होता, इसलिए “1234 enter करें या click करें” होना चाहिए
    • Netdata जैसी कुछ sites ऐसा करती हैं
      लेकिन यह password manager द्वारा username/password combination autofill करने से slow है, क्योंकि email का इंतजार करना और link दबाना पड़ता है
    • मैं ठीक इसी login flow वाला web app बना रहा हूं, और mobile पर समस्या आई। Gmail जैसे apps बिना preview के link को browser में copy नहीं करने देते, और वह preview link को consume कर देता है (next.js auth)
      मैं Gmail in-app browser में login नहीं करना चाहता, बल्कि regular browser में login करना चाहता हूं, लेकिन यह काफी झुंझलाहट भरा है
    • अगर ऐसा ही करना है तो बेहतर है सीधे single sign-on तक जाएं। 95% users वैसे भी Gmail, Outlook, Apple में से किसी एक का इस्तेमाल करेंगे
      “mail से link भेजें” की तुलना में “Google से login” button बेहतर है, और दोनों ही मामलों में tracking संभव है

  • हर मामूली-सी सेवा के लिए इंसान अलग पासवर्ड बनाए और याद रखे, यह सोच व्यावहारिक नहीं है। एक और पासवर्ड-आधारित authentication system बनाना एक तरह के role-play जैसा है
    पासवर्ड आम तौर पर दो तरीकों में से एक में इस्तेमाल होते हैं: एक password manager जिसे एक असली पासवर्ड सुरक्षित करता है, या हर सेवा पर दोहराया जाने वाला वही पासवर्ड। लगभग हर सेवा email recovery देती है, इसलिए असल में email ही authentication का तरीका है। निजी email लोग आसानी से नहीं बदलते, शेयर नहीं करते, और reuse भी नहीं होता। शायद आपने अपना निजी email फोन नंबर से ज्यादा लंबे समय तक इस्तेमाल किया होगा। मेरा मौजूदा email address इस्तेमाल करते हुए फोन नंबर कम-से-कम पांच बार बदल चुके हैं, और वे नंबर अब दूसरे लोग इस्तेमाल कर रहे हैं

    • Derived password भी होते हैं, जो एक तरह का hybrid हैं। यह इंसान द्वारा याद रखा गया कोई pattern हो सकता है, या domain के हिसाब से calculate करने वाला management tool भी हो सकता है
      और password recovery feature कम-से-कम address owner को हर कोशिश के बारे में बताता है। Password-based login हर नए location से login होने पर हमेशा email नहीं भेजता
    • Apple ने “बस 1Password/Keychain password डालने के बजाय email से परेशान करना पड़े” वाली प्रक्रिया को काफी बेहतर बना दिया है। कम-से-कम तब तो, जब वह email या SMS पहचानकर code खुद भर देता है

  • जवाब सरल है। आम तौर पर यह service provider द्वारा user के लिए बनाई गई असुविधा से जुड़ा होता है। इस मामले में यह साफ दिखता है: email provider session आम तौर पर लगभग कभी खत्म नहीं होता और browser cache साफ न किया जाए तो login बना रहता है
    अपनी service के authentication token भी Gmail जैसी ही lifetime के बनाएं, और विकल्प के तौर पर हर बार one-time password से login करने दें। लेकिन 12 घंटे वाले authentication token जैसी अपवित्र प्रथाएं बंद करनी चाहिए। तब user फिर कभी password recovery के जरिए login नहीं करेगा

    • असली वजह यह भी हो सकती है कि वे websites बस ठीक से काम नहीं करतीं
      पहले Epic और Spotify account में मेरे साथ समस्या हुई थी। account बनाइए और एक हफ्ता इस्तेमाल कीजिए, फिर session expire हो जाता और Spotify मुझे account से बाहर निकाल देता। login करने पर कहता कि password गलत है, जबकि password manager में saved है, इसलिए यह संभव नहीं। आखिर email से reset करना ही पड़ता। पहले कुछ बार email मिलकर reset करने के बाद भी वही pattern दोहरता रहा, और 3–4 बार के बाद तो email भी नहीं आया, इसलिए नया account बनाना पड़ा। अब मैं Google account से Spotify में login करके इस्तेमाल कर रहा हूं और अभी तक कोई समस्या नहीं है। लेकिन सामान्य email से इस्तेमाल करें तो उनका authentication system बस काम नहीं करता
    • मुझे लगता है यह सच्चाई के ज्यादा करीब इशारा है। Gmail और Cloudflare समेत कई “high-security organizations” में authentication session बहुत लंबे होते हैं। वजह यह है कि ऐसे systems इस्तेमाल करने वाले व्यक्ति के PC तक किसी की पहुंच होना, और user का logout न किया होना, वास्तव में बहुत कम संभावना वाली बात है। ज्यादातर hacks remote तरीके से कमजोर password को निशाना बनाते हैं
      समस्या यह है कि risk को मापने और “क्या इस site को सच में two-factor authentication चाहिए?”, “क्या 30-minute session time उचित है?” जैसे फैसले लेने के लिए कोई consistent language नहीं है। अगर latest antivirus है, तो ज्यादातर लोग logged-in रहना चाहेंगे। क्या कभी किसी site की problem ठीक करने के लिए आपसे सारी cookies clear करने को कहा गया है? मेरा जवाब हमेशा मना होता है। मैंने कभी सुना था, “account आपका है, और अगर आप logged-in रहकर hacking risk लेना चाहते हैं तो वह service operator का नहीं, आपका risk है,” और मैं इससे धीरे-धीरे और ज्यादा सहमत हो रहा हूं। अगर laptop logged-in रहते हुए किसी ने सारे EC2 instances delete कर दिए, तो यह AWS की गलती नहीं कि उसने आपको पहले logout नहीं कराया; यह आपकी गलती है। AWS कर सकता है, लेकिन क्यों करे? एक लापरवाह व्यक्ति को बचाने के लिए 10 लाख लोगों को परेशान करने की वजह नहीं है
    • सही बात है। platforms के session limits और forced two-factor authentication के जरिए nanny जैसा व्यवहार करने से थक गया हूं। बस settings में एक toggle दे दें

  • मैंने ऐसी sites देखी हैं जिन्होंने password recovery step हटा दिया है या password ही हटा दिया है। email ही authentication है
    तरीका यह है कि email address डालें, code वाला email पाएं, और code डालकर login करें। ऐसा क्यों करते हैं समझ आता है, लेकिन कई email इस्तेमाल करने वाले के तौर पर मुझे यह काफी नापसंद है। कौन-सा email इस्तेमाल करना है याद रखने के लिए password manager में email और notes डालने पड़े, और वह बिना password वाली entry की तरह रह जाता है

    • magic link इस्तेमाल करने की friction इतनी ज्यादा थी कि मैंने ऐसी websites पर पैसा खर्च नहीं किया और alternative ढूंढ लिया
      अगर वे ढंग का login system भी नहीं बना सकते, तो संभव है कि वादा की गई functionality देने की क्षमता भी कम हो। magic link अब झुंझलाहट से आगे बढ़कर filter बन गया है
    • B2B SaaS में हम यह तरीका इस्तेमाल करते हैं। individual users शायद 6 महीने में एक-दो बार login करते हैं, इसलिए passwordless login फायदेमंद है
      कम इस्तेमाल होने वाली service का password याद रखने का बोझ नहीं होता, और company onboarding भी आसान होती है। company users का CSV upload करती है, और users password बनाने, confirm करने और rules match कराने की प्रक्रिया के बिना सीधे काम शुरू कर सकते हैं। email link पसंद नहीं है, क्योंकि phone app के previews या enterprise virus scanners वगैरह link को “click” कर देते हैं
    • non-technical consumers का बड़ा हिस्सा password manager इस्तेमाल नहीं करेगा। अगर केवल password signup दें और magic link या code न दें, तो आप ज्यादातर consumers की जिंदगी ज्यादा मुश्किल बना रहे हैं
      दोनों देने पर भी, अगर password मांगते हुए email verification भी कराते हैं, तो signup flow में ज्यादा drop-off होगा। इसके अलावा password और कई email login flows handle न करने से code भी कहीं ज्यादा simple रहता है
    • voucher redeem करने वाली “guest login” site में यह तरीका दिया गया था, और मुझे लगता है कि जो लोग account नहीं बनाना चाहते, उनके लिए यह valid use case है
      voucher को email से जोड़ना जरूरी था, इसलिए बाद में voucher खोने पर support issue के लिए ownership link click करके verify करनी पड़ती थी। बाद में account बनाने पर पहले मिले vouchers भी देख सकते हैं
    • इसका मतलब है कि site मेरा password store नहीं करती, इसलिए चिंता करने की चीजें कम हो जाती हैं

  • यह लेख पढ़ने के बाद ही मुझे एहसास हुआ कि मैं Best Buy पर ठीक यही तरीका इस्तेमाल कर रहा हूँ
    यह जानबूझकर नहीं था। 1Password में पासवर्ड सेव है, इसलिए मुझे पता है कि वह सही है, लेकिन जब भी मैं bestbuy.com पर कुछ खरीदने की कोशिश करता हूँ, कोई account takeover prevention लग जाती है और झूठा कहती है कि पासवर्ड गलत है। मैं पूरी तरह मान सकता हूँ कि समस्या मेरी तरफ भी हो सकती है। यह ad blocker या local DNS blocking जैसी चीज़ हो सकती है। लेकिन कुछ बार दोहराने के बाद debug करने का मन खत्म हो जाता है और इंसान बस सबसे कम रुकावट वाला रास्ता अपना लेता है

    • कहीं यह maximum length mismatch तो नहीं? पासवर्ड बदलने वाले field और login page के maxlength का अलग होना बहुत आम है
      उदाहरण के लिए, अगर पासवर्ड बदलते समय 60-character का पासवर्ड डाला, लेकिन login page की maximum length 40 characters है, तो login करते समय “पासवर्ड गलत” हो जाएगा। इसलिए अब मैं application settings में maximum length सेव करने और उसे सभी password fields में propagate करने की policy इस्तेमाल करता हूँ। जांचने पर पता चला कि सच में length mismatch है। password set करने वाले form में maxlength 54 है, लेकिन login page में maxlength है ही नहीं। इसलिए अगर पासवर्ड 54 characters से लंबा है और 1Password saved password को अपने-आप 54 characters या कम में truncate नहीं करता, तो login नहीं हो पाएगा

  • ज़्यादातर लोगों के लिए कंप्यूटर पर काम करना तब तक brute-force तरीके से बार-बार कोशिश करना है, जब तक कुछ कामचलाऊ रूप से चल न जाए। Software वे लोग बनाते हैं जो underlying system को बारीकी से समझते हैं, लेकिन यह उन लोगों के लिए बनाया जाता है जिनके पास वह समझ नहीं होती
    user एक बार कोई pattern ढूंढ ले जो काम करता है, तो उसी पर टिक जाता है। अब कई स्कूल शिक्षा में tablets इस्तेमाल कर रहे हैं, इसलिए यह प्रवृत्ति और बढ़ रही है। कंप्यूटर कैसे काम करता है, इसका अंदाज़ा ठीक से नहीं बनता। अधिकतर लोग गहराई से सोचते नहीं। वह बस वहां है, और लोग पहले से टूटी हुई चीज़ों के आदी हैं, तो कुछ extra clicks कर लेने में क्या बड़ी बात है

    • software developers में शायद 10% ही ऐसे होंगे जो वास्तव में गहराई से समझते हैं कि वे क्या कर रहे हैं। उल्टा, developers खुद ठीक से नहीं समझते कि वे क्या कर रहे हैं, इसलिए आम लोग खराब software को बार-बार कोशिश करके किसी तरह इस्तेमाल करते हैं

  • बढ़ा-चढ़ाकर कहें तो login flow समान ही है
    A) website पर जाएं, password manager के जरिए कोई random string copy-paste करें, और identity verify करने के लिए email से आया TOTP request लें। या B) website पर जाएं, forgot password दबाएं, login link पाएं और फिर random string डालें। कई मामलों में B वास्तव में तेज़ होता है, और लगभग कभी ज्यादा धीमा भी नहीं होता। “remember me” checkbox का कोई असर नहीं होता

    • password manager से copy-paste कौन करता है?
      मुझे अपना flow दोनों से बेहतर लगता है। site पर जाते ही Safari autofill suggest करता है, TouchID/FaceID इस्तेमाल होता है, और 2-step code मांगा जाता है। अगर वह SMS या email से आता है, तो Safari autofill suggest करता है। TOTP method हो तब भी Safari autofill कर देता है। बहुत आसान है। passkey और भी आसान है, क्योंकि इसमें दूसरा step और SMS/email का इंतज़ार नहीं होता
    • TOTP email से भेजी जाने वाली चीज़ नहीं है। TOTP का मूल बिंदु यह है कि current time और पहले से shared secret value से authentication code खुद generate किया जा सकता है
    • अगर greylisting हो, तो B flow में करीब 10 मिनट लग सकते हैं
    • B तरीका email तक पहुंच वाली किसी भी जगह से संभव है, और यह इस पर निर्भर नहीं करता कि app या phone मेरे हाथ में है या नहीं
    • browser पासवर्ड याद नहीं रखता क्या?

  • motivation तुरंत समझ में आती है। “पासवर्ड भूल गया” इस्तेमाल करें तो पासवर्ड याद रखने की जरूरत नहीं रहती। और account security भी और कमजोर नहीं होती। क्योंकि वह route तो वैसे भी attacker के लिए खुला था
    कुछ websites इसे default flow बना देती हैं, और अगर किसी को email में login button भेजा जा सकता है तो वे implicit रूप से दावा करती हैं कि password खुद ही meaningless है। निजी तौर पर मुझे यह पसंद नहीं। मैं email पर भरोसा नहीं करता, और यह भी पसंद नहीं कि वह दर्जनों accounts का single point of failure बन जाए। अगर सिर्फ दूसरे factor से login किया जा सकता है, तो वह 2-step authentication नहीं है। मैं reset option के बिना password से login करना चाहूंगा, लेकिन हकीकत ऐसी नहीं है

    • email को 2-step authentication से protect करें, तो यह फिर से 2-step authentication बन जाता है