2 पॉइंट द्वारा GN⁺ 2024-08-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • MFA के बढ़ते इस्तेमाल के बीच Microsoft Authenticator में QR code से जोड़ा गया नया TOTP account मौजूदा account को overwrite कर सकता है, जिससे user lock out हो सकता है
  • टकराव की मुख्य वजह account पहचान में सिर्फ label इस्तेमाल करने वाला design है; यह Google Authenticator·Okta आदि की तरह issuer और label को साथ में इस्तेमाल नहीं करता
  • overwrite तुरंत सामने नहीं आता, इसलिए user को हफ्तों या महीनों बाद मौजूदा account access करने की कोशिश में ही access न मिलना अनुभव हो सकता है
  • workaround के तौर पर दूसरा authentication app इस्तेमाल करना या Secret Key को manually enter करना है, लेकिन enterprise environment के आम users के लिए यह बहुत practical नहीं है
  • Microsoft ने कहा कि यह intended behavior है और warning message दिया जाता है; बाद में उसने कुछ issuers में issuer missing होने को वजह बताया और सिर्फ future improvements की संभावना छोड़ी

QR scan किस तरह मौजूदा MFA account को overwrite करता है

  • Microsoft Authenticator नया account QR scan से जोड़ते समय उसी user name वाले मौजूदा account को overwrite कर सकता है
  • user name के तौर पर email address बहुत इस्तेमाल होते हैं, इसलिए कई services के MFA accounts का वही label share करना आम है
  • Google Authenticator और ज़्यादातर अन्य authentication apps bank·car company जैसे issuer name को भी साथ में इस्तेमाल करके collision से बचते हैं
  • Microsoft Authenticator issuer को साथ में इस्तेमाल नहीं करता और सिर्फ user name से account की पहचान करता है
  • overwrite के बाद नए बनाए गए account और overwrite हुए पुराने account, दोनों में authentication समस्याएँ आ सकती हैं

वजह समझना मुश्किल बना देने वाला lockout

  • lockout होने पर user Microsoft Authenticator के बजाय authentication देने वाली company की तरफ problem मान सकता है
  • नतीजतन enterprise helpdesk को ऐसी स्थिति सुलझाने में समय लगाना पड़ता है जो उनकी बनाई हुई problem नहीं है
  • यह आसानी से पता लगाना मुश्किल है कि कौन सा account overwrite हुआ
  • पुराने account के गायब होने की बात तब तक सामने नहीं आ सकती जब तक user उस account को फिर से इस्तेमाल करने की कोशिश न करे
    • यह समय हफ्तों या महीनों बाद हो सकता है

workaround और पुरानी शिकायतें

  • सबसे आसान workaround Microsoft Authenticator की जगह दूसरा authentication app इस्तेमाल करना है
  • QR code scan न करके Secret Key manually enter करने से problem से बचा जा सकता है
  • Microsoft account से जुड़े authentication accounts में यह problem दिखाई नहीं देती लगती है
  • CSO Online ने इस problem पर शिकायतें 2020 तक पीछे जाकर देखीं, और problem खुद Microsoft Authenticator के June 2016 launch से मौजूद लगती है
  • 2020 में एक user ने Identity Provider की Secret Key manually enter करने वाले workaround का ज़िक्र किया था, लेकिन enterprise environment के औसत end user के लिए random string संभालने का यह तरीका मददगार नहीं माना गया

field में reproduce हुआ overwrite

  • Australia के IT consultant Brett Randall ने vendor training session में देखा कि participants Microsoft Authenticator से MFA QR code scan करते हुए दूसरी application की TOTP key overwrite कर बैठे
  • Randall के अनुसार MFA QR code कई values वाली string बनाता है, और दूसरे apps label और issuer को combine करके उस key का unique ID बनाते हैं
  • Microsoft Authenticator इस standard behavior के बजाय सिर्फ label इस्तेमाल करता है, और वह label आम तौर पर email address होता है
  • उसी email address का इस्तेमाल करने वाली आखिरी TOTP key नई key से overwrite हो सकती है
  • Randall ने कहा कि Microsoft को इस problem से अवगत कराकर action दिलवाना लगभग असंभव था

security और IT experts की प्रतिक्रिया

  • CSO Online ने कई security·IT experts से problem reproduce करने को कहा, और सभी reproduce करने में सफल रहे
  • IllumineX के fractional CTO Gary Longsine ने इसे design flaw माना और कहा कि वे Microsoft Authenticator recommend नहीं करेंगे
  • Wallarm के product VP Tim Erlin ने कहा कि उसी email address वाला दूसरा item जोड़ने पर collision होता है, और overwrite के बाद यह पता नहीं चलता कि कौन सा account overwrite हुआ
  • Erlin ने कहा कि users वजह नहीं जान पाते होंगे, इसलिए यह problem असल से कम जानी गई हो सकती है
  • Netography के chief product officer David Meltzer ने खुद reproduce करने के बाद इसे clear bug माना और कहा कि Microsoft के लिए इसे ठीक करना अपेक्षाकृत सरल issue है
  • Google spokesperson Kimberly Samra ने जवाब दिया कि Google Authenticator codes overwrite नहीं करता, और यह एक explicit decision है

Microsoft का रुख और warning text

  • Microsoft ने problem confirm की, लेकिन कहा कि यह bug नहीं बल्कि intended behavior है
  • पहली लिखित प्रतिक्रिया में उसने बताया कि जब user QR code scan करता है, तो account settings overwrite कर सकने वाली action से पहले उसे confirmation message मिलता है
  • असली warning text है: “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
  • यह text user को बताता है कि अगर उसने खुद यह शुरू किया है और source trusted है, तो continue करे
    • bank या hotel जैसी legitimate service में user ने खुद QR scan शुरू किया हो, तो दोनों conditions ज़्यादातर पूरी होती हैं
    • निर्देशों के अनुसार आगे बढ़ने पर account overwrite हो सकता है
  • warning window authentication attempt छोड़ने के अलावा overwrite से बचने का कोई तरीका नहीं देती

issuer missing होने पर जिम्मेदारी को लेकर खींचतान

  • Microsoft ने बाद में दिए लंबे दूसरे statement में समझाया कि कुछ sites या vendors label में issuer, यानी site name या Identity Provider name, शामिल नहीं करते
  • अगर उसी label वाला existing account है, तो app newly scanned TOTP account से existing account overwrite करने की कोशिश कर सकता है
  • Microsoft ने कहा कि ऐसी स्थिति में user को हमेशा overwrite confirmation message मिलता है और वह proceed करने या न करने का चुनाव कर सकता है
  • “हम product improvements जारी रखे हुए हैं और इसे ध्यान में रखकर future improvements में लागू करेंगे” — Microsoft की ओर से इस problem को ठीक करने की संभावना जताने वाला यही एकमात्र हिस्सा था

दूसरे authentication apps से तुलना

  • Randall के अनुसार end users को गलती से दूसरे app की key overwrite करने से रोकने के दो तरीके हैं
    • सभी applications के otpauth का audit करना और हर company को उनकी गलत implementation ठीक करने के लिए मनाना
    • Microsoft एक बार fix कर दे ताकि आगे वही चिंता न रहे
  • Randall ने 14 अन्य authentication apps में वही collision behavior test किया, लेकिन कहा कि Microsoft Authenticator जैसा behavior किसी में नहीं था
  • tested apps में Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth, Authenticator 2FA Sentinel शामिल थे

1 टिप्पणियां

 
GN⁺ 2024-08-18
Hacker News की राय
  • बिना usability वाली security की बड़ी समस्या दिखाने वाला छोटा-सा उदाहरण, सच में बहुत relatable है
    “security” के नाम पर झेली जाने वाली बेतुकी चीज़ों के बारे में सोचिए। जबरन समय-समय पर password बदलवाना, पागलपन भरे password rules, undocumented requirements जिन्हें trial and error से समझना पड़ता है, security jargon से भरे जटिल error messages, और ऐसे “secret questions” जिनके जवाब याद नहीं रहते
    लेकिन असल में इन्हीं systems की security छलनी जैसी छेदों से भरी होती है। Data breach और information leak लगभग रोज़ news में आते हैं, और अक्सर सोचता हूं कि ये सब यूं ही कैसे चलता रहता है

    • Capital One ने किसी समय “username” शुरू किया और email address से login तोड़ दिया, लेकिन न तो इसे document किया और न ही username में email address इस्तेमाल करने से रोका
      कई महीनों तक हर login पर “find my account” इस्तेमाल करना पड़ा, और हर बार username वापस email address पर set कर दिया। करीब 10 साल से वही login credential था, तो यह स्वाभाविक था
      username में @ या . इस्तेमाल न कर पाने की पाबंदी login करने तक कभी enforce नहीं हुई, और आखिर कई महीनों बाद पता चला कि इसे किसी और value में बदलना होगा
      मूल account ING Direct था, फिर Capital One 360 बना, और बाद में Capital One की बाकी अव्यवस्था में पूरी तरह integrate हो गया; मुझे लगता है यह username वाली समस्या भी उसी से जुड़ी थी
    • कल एक अच्छा उदाहरण झेला
      website: “special characters और numbers सहित 8 characters से ज्यादा का complex password चुनें”
      password manager खोला और 128-character random password generate करके खुश हुआ
      अगली visit पर website: “अपने password का 31वां, 98वां, 102वां character enter करें”
      यह UK की mortgage website थी
      अब सोचता हूं तो इसका मतलब है कि वे password को plain text में store कर रहे हैं, या कम से कम hash नहीं बल्कि encrypt करके रख रहे हैं ताकि कभी भी decrypt कर सकें
    • सबसे ज्यादा नापसंद pattern यह है: किसी website पर पता चलता है कि मेरा account है जिसे काफी समय से use नहीं किया, email और site URL से algorithmically generated सही password enter करता हूं, लेकिन fail हो जाता है
      सोचता हूं शायद पुराने version algorithm से बना password था, फिर try करता हूं, फिर भी fail। आखिर password reset दबाता हूं, email लेकर link click करता हूं, और algorithm से generated password को नए password के रूप में डालता हूं तो “वह special character इस्तेमाल नहीं कर सकते” आता है
      अपने rules के अनुसार उस special character को अगले character से बदलकर डालता हूं, तो इस बार “current password से reset नहीं कर सकते” दिखता है
    • अब तक देखी चीज़ों में https://studentaid.gov/ सबसे खराब था। झूठी जानकारी डालना नहीं चाहता था, और account clone करके requirements फिर से check भी नहीं कर सकता था
      याद से, “dictionary words निषिद्ध”, “हाल के 24 passwords reuse निषिद्ध”, “कुछ special characters बाहर”, “5 security questions”, और कई अन्य password requirements थे
      security questions case-sensitive हैं या नहीं, कोई नहीं जानता
      account creation information सच है और आप ही हैं यह certify करना होता है, और गलत या भ्रामक जानकारी देने पर जुर्माना या जेल या दोनों हो सकते हैं—ऐसी लाइन भी थी
    • अच्छी खबर यह है कि ऊपर गिनाई गई चीज़ें end users और security समझने वाले लोगों—दोनों के लिए bad ideas मानी जाती हैं। अफसोस, security policies implement करने वाले ज्यादातर लोग इनमें नहीं आते
      चार या उससे ज्यादा dictionary words इस्तेमाल करने से मजबूत password security मिल सकती है, और security question answers के लिए भी यही तरीका इस्तेमाल किया जा सकता है। free और paid password managers भी बहुत हैं, जो सभी secret values याद रखने की समस्या हल कर देते हैं। 2-factor authentication secrets backup करने के लिए भी अच्छे हैं
      अगर “जटिल error message” ऐसा error है जिसे user से खुद ठीक करवाने की उम्मीद है, तो बेहतर है कि generic error और unique ID return करें और support team से संपर्क करने को कहें। jargon की बौछार चिढ़ाती है, लेकिन यह security-specific समस्या से ज्यादा errors explain न कर पाने वाली मानवीय अक्षमता जैसी लगती है
      ज्यादातर organizations, भले ही पूरा business सफल हो, एक साथ बहुत सारी चीज़ें बिगाड़ रही होती हैं, और security भी उनमें से एक है। organization काफी बड़ी हो तो अक्षम लोगों का अक्षम काम करना टालना मुश्किल लगता है
  • यह कई स्तरों पर समझ नहीं आता। क्या इसका मतलब है कि Microsoft Authenticator entries को सिर्फ label के आधार पर store करता है? क्या वह कोई internal key जैसी चीज़ भी नहीं बनाता?
    और फिर यह दावा करता है कि समस्या website के issuer को label में नहीं, बल्कि जहां होना चाहिए उस issuer field में डालने की है?
    मुझे आश्चर्य है कि Microsoft में क्या सचमुच कोई अपना Authenticator इस्तेमाल करता भी है। अगर मैं कुछ miss नहीं कर रहा हूं, तो एक site पर email इस्तेमाल करते ही उसे दूसरी site में add नहीं कर पाएंगे, इसलिए यह लगभग हर application में unusable लगता है

    • इसी तरह, search giant Google ने Android के लिए Google Authenticator बिना search box के launch किया, और कई feature requests के बावजूद जानबूझकर अभी तक नहीं जोड़ा
      लेकिन iOS version में search box है। आखिर क्यों, समझ नहीं आता
      विशाल Piper repository में कोई local search library पहले से होगी जिसे एक ही changelist में डाल सकते हों, हालांकि वह large language model नहीं है
    • लेख के अनुसार, Microsoft ने इसे ठीक करने का इरादा नहीं किया क्योंकि यह free product है और revenue नहीं बनाता
    • अगर Microsoft employees अपना Authenticator इस्तेमाल करते हैं, तो ज्यादा से ज्यादा सिर्फ company work के लिए, जहां Microsoft ही एकमात्र issuer है, शायद वहीं करते होंगे
      और मुझे लगता है बहुत सारे लोग तो बिल्कुल इस्तेमाल ही नहीं करते होंगे
    • यहां कुछ बात मेल नहीं खा रही। मेरे पास same email वाले कई accounts हैं, और backup TOTP app Authenticator के code की correct code से तुलना की, तो match हुआ
      हालांकि मुझे एक UI problem मिली जो user को गलत code दिखा सकती है। screen पर दिख रहे पहले कुछ accounts के codes हर 30 seconds में refresh होते हैं, लेकिन screen के बाहर वाले codes refresh नहीं होते
      scroll करके off-screen code लाने पर पुराना code दिखता है, और एक मामले में correct code से 4 rotations पीछे का code दिखा
    • शायद इसका इस्तेमाल सिर्फ उस एक work MS account के लिए होता होगा जिसे company enforce करती है। दूसरी जगहों पर शायद नहीं, क्योंकि वे जानते हैं कि यह अच्छा नहीं है
  • अजीब बात है कि मुझे Microsoft से एक ऐसा ईमेल मिला जो phishing जैसा दिखता था, लेकिन शायद नहीं था
    उसमें लिखा था, “कार्रवाई आवश्यक: 15 अक्टूबर 2024 तक अपने tenant में multi-factor authentication enable करें”, और कहा गया कि मुझे यह इसलिए मिला क्योंकि मैं “global administrator” हूँ, लेकिन organization के नाम की जगह सिर्फ UUID लिखा था
    सूचना यह थी कि 15 अक्टूबर 2024 से Azure portal, Microsoft Entra admin center, और Intune admin center में login के लिए MFA जरूरी होगा, इसलिए तब तक MFA enable करें। अगर नहीं कर सकते, तो enforcement date टालने के लिए आवेदन करने को कहा गया
    समस्या यह है कि मैं Microsoft में कोई organization manage नहीं कर रहा हूँ। मेरे पास बस व्यक्तिगत Office365 Family account जैसी चीजें हैं, और account में पहले से 2-step authentication set है
    ईमेल में न मेरा नाम था, न कथित organization का नाम, सिर्फ ID थी, इसलिए समझ ही नहीं आया कि बात क्या है। फिर भी ईमेल वाकई Microsoft से आया था

    • Azure portal में login करने पर शायद वैसा ही message दिखे और संबंधित resource पर जाने का विकल्प मिले
  • Gmail account बनाने के बाद देश और computer बदलते हुए मैंने कुछ accounts खो दिए। Login करने की कोशिश की तो Google ने कहा कि password सही है, लेकिन device और IP अपरिचित हैं
    recovery address के जरिए recovery क्यों नहीं हुई, यह ठीक-ठीक याद नहीं, लेकिन recovery email address तक अब भी access होने के बावजूद यह fail हो गया। शायद Google को बताना पड़ता था कि recovery email address क्या है, और संभव है कि मैंने recovery address में random + suffix इस्तेमाल किया हो
    पहले मैं Gmail account के लिए Google Authenticator इस्तेमाल करता था, लेकिन जब Google कोई खास राहत का तरीका नहीं देता, तो एक और चीज खराब होने का डर लगा और मैंने उसे बंद कर दिया
    password में लगभग 96 bits से ज्यादा entropy होती है; /dev/urandom से 256 bits निकालकर multi-precision integer बनाता हूँ, फिर divmod से digits, lowercase, uppercase, और symbols में से एक-एक चुनता हूँ, बाकी पूरे alphabet से चुनता हूँ, और बची entropy से Fisher-Yates shuffle चलाता हूँ ताकि पहला character हमेशा digit न बने
    ये site-specific passwords हैं, और 2000s की शुरुआत में खुद बनाए gpg-based password manager में stored हैं
    Multi-factor authentication ongoing active compromise के कुछ मामलों में मदद करता है, लेकिन database breach से हुए password hash dump में मदद नहीं करता। Password पता होने के बावजूद recovery email address से recover न हो पाना सच में बहुत परेशान करने वाला है
    अगर मैंने महीनों तक कहीं login नहीं किया और मेरे पास सही password है, तो कम से कम recovery address बताने की मांग न करके verification link या code recovery address पर भेजना चाहिए। वे यह न बताएं कि कहां भेज रहे हैं, ठीक है, लेकिन recovery address को याद रखने वाला एक और password बना देना सच में झुंझलाहट भरा है

    • यह मुझे पता नहीं था। Risk और बढ़ाने के लिए मैंने recovery address किसी दूसरे dormant Gmail account पर set कर रखा था
      अब Google पर उतना ही भरोसा करता हूँ जितना data पहले ही दे चुका हूँ और जितना देना बिल्कुल जरूरी है
      International migration planned है, इसलिए serious problem आने से पहले email life को testing में चल रहे paid account Proton Mail पर shift करने की रफ्तार बढ़ानी होगी
      जब Gmail भोला-भाला लगता था और administrative काम online होने शुरू हुए थे, तब मैंने tax, healthcare, public agencies जैसी जगहों पर Gmail को contact के तौर पर देना शुरू किया। वह अच्छी तरह काम करता रहा, और कई international migrations के दौरान Gmail एक अहम administrative tool बन गया
      इधर-उधर dormant accounts भी हैं, लेकिन उनमें ऐसे जरूरी काम बचे हो सकते हैं जिनकी कभी जरूरत पड़ जाए। जैसे कई वर्षों तक valid रहने वाला Australian travel authorization
      Mass surveillance तेज होने के बाद भी Gmail काफी हद तक harmless लगता था, और मैं किन institutions से deal करता हूँ, इस तथ्य के अलावा कोई असली secret या बहुत निजी बातें शायद ही थीं
      लेकिन अब online administration लगभग mandatory हो गया है, और बाकी means न्यूनतम रह गए हैं, इसलिए Gmail असुविधाजनक हद तक केंद्र में है। Automated bots बिना शक वाले users के साथ बिना दया या appeal के जो चिंताजनक काम करते हैं, उनकी वजह से migration शुरू करना ही पड़ा
      यह इतना व्यापक रूप से फैला है कि सब कुछ ढूँढने का समय कम पड़ता है, और भूले हुए accounts के लिए धुंधली यादें खंगालना यातना जैसा है। फिर भी करना होगा
      मैं नहीं चाहता कि जब मेरी जुड़वां बेटियाँ उस उम्र में पहुँचें जहाँ official कामों के लिए email की जरूरत हो, तो उन्हें Google bots की दया पर छोड़ दिया जाए
    • जब आपने recovery email add किया होगा, तो उस account पर notification mail मिला होगा। Inbox में वह mail ढूँढें, तो to field से random suffix पता चल सकता है
    • मेरे साथ भी कुछ ऐसा ही हुआ। मुझे किसी open source project के Google domain में add किया गया और email address मिला, लेकिन Google phone number मांगता है, इसलिए login नहीं कर पा रहा हूँ
      शायद admin से कहकर reset कराया जा सकता है, लेकिन personal information देने तक account को practically hostage बनाए रखना काफी unpleasant है
    • बात करने के लिए कोई इंसान नहीं है—इसी वजह से, अगर computer कह दे कि नहीं होगा, तो बस वहीं बात खत्म
  • काम वाले account की वजह से Microsoft वाला इस्तेमाल करता आया हूं। वैसे भी Office365 में यह काफी गहराई से जुड़ा है, इसलिए न इस्तेमाल करने की कोई वजह नहीं थी
    वैसा dialog मैंने कभी नहीं देखा, और जो accounts जोड़े उनमें भी कोई समस्या नहीं हुई। काम का account है, इसलिए 99% मामलों में account name के तौर पर अपनी company email शेयर करता हूं
    तो क्या इसका मतलब है कि जिन sites का मैंने इस्तेमाल किया, उन्होंने पर्याप्त unique labels दिए और मैं lucky रहा? लगता है मैं पूरी तरह नहीं समझ पाया कि समस्या ठीक-ठीक क्या है

    • Hardware key को 2-step authentication के लिए इस्तेमाल करना चाहता था, लेकिन हर system support भी नहीं करता और ठीक से support भी नहीं करता। अगर register की जा सकने वाली key अधिकतम 1 ही हो, तो समझ नहीं आता आखिर करना क्या चाहते हैं
      अंत में समय निकलता जाता है, और यह परिवार की रोज़ी-रोटी कमाने वाला काम नहीं बल्कि login करने के लिए क्या-क्या जुगाड़ करना पड़ेगा, यह खोदने वाला झंझट भर है, इसलिए मैंने वही MS वाला इस्तेमाल करने का फैसला किया जिसे पिछली job में अनिवार्य किया गया था
      Online accounts इस्तेमाल करते हुए meaningful काम करने के बजाय ऐसी चीज़ों से जूझते हुए मैं पहले ही बहुत ज्यादा समय बर्बाद कर चुका हूं
      पूरी online identity verification व्यवस्था बेहद अविश्वसनीय है और बड़े holes व उससे भी बड़े risks से भरी है, लेकिन हम उसी के ऊपर अपनी पूरी जिंदगी बना रहे हैं
      दशकों तक password weaknesses से गंभीर नुकसान होने के बावजूद हम अब भी passwords इस्तेमाल करते हैं, और band-aid या paint करके उन्हें पैबंद लगाने की कोशिश करते हैं
      लगभग हर हफ्ते कोई न कोई online system आसानी से exploit हो सकने वाली बड़ी मात्रा में personal information leak करता है, फिर भी हम जलते कमरे के बीच coffee पीते dog meme की तरह “ठीक है, ठीक है” कहते बैठे रहते हैं
      हम मानते रहते हैं कि अगर हर system के लिए अलग-अलग 8 या ज्यादा characters वाले passwords रखेंगे तो सुरक्षित रहेंगे और सब ठीक होगा
    • लगता है यह bug सिर्फ iOS app में QR code scan करते समय होता है
    • मेरे साथ भी यही है। 3 personal accounts एक ही email address इस्तेमाल करते हैं, और उनमें से दो FAANG हैं, फिर भी लगभग 10 साल से बिना समस्या के ठीक चल रहे हैं
    • Microsoft का जवाब पढ़ें तो Microsoft MFA जारी करने वाली कंपनियों को दोष देता है कि वे “issuer को label में नहीं डालतीं।” MSFT उम्मीद करता है कि issuer वहीं होना चाहिए
      अगर वे ऐसी उम्मीद रखते हैं, तो Microsoft products खुद issuer को label में डालेंगे, इसलिए उन्हें समस्या नहीं होगी
      समस्या तब होती है जब कोई ऐसा दूसरा provider इस्तेमाल किया जाए जो identifier के तौर पर वही email इस्तेमाल करता है, और issuer को store करने के लिए बने issuer field में issuer डालता है। मानो यह कोई बहुत अजीब हरकत हो
  • Safari में भी ऐसा ही bug था, जिसने बिना किसी warning के passkey को overwrite कर दिया और account से पूरी तरह lock out कर दिया। बाद में इसे fix कर दिया गया, लेकिन इसकी वजह से मेरी GitHub access चली गई
    https://bugs.webkit.org/show_bug.cgi?id=270553
    Safari में अब भी एक bug है जिसमें hardcoded exceptions के अलावा वह अलग-अलग subdomains पर hosted websites में फर्क नहीं कर पाता, और एक subdomain के password को दूसरे subdomain के password से overwrite कर देता है। यह मेरे साथ हर महीने होता है

    • Keychain ने StackOverflow और StackExchange subdomains पर password reuse की warning दी थी, यही उन कारणों में से एक था कि मैंने third-party password manager इस्तेमाल करना शुरू किया जिसमें एक item में कई sites manually add की जा सकती हैं
      लेकिन मुझे नहीं पता था कि ऐसी मूर्खता और भी गहराई तक जाती है
  • Security vulnerabilities होने के बावजूद SMS multi-factor authentication users में popular होने की वजह यही है
    आम तौर पर जब तक आप SIM swap attack के target नहीं बनते, यह काफी ठीक है। ज्यादातर लोग target नहीं बनते, लेकिन multi-factor authentication key खो देने की समस्या आने की संभावना काफी ज्यादा होती है

    • सही है। सरल है और लगभग सभी इसे समझते हैं। खुद password की तरह
      YubiKey जैसे ज्यादा secure तरीके आम जनता में नहीं फैल पाए, इसकी वजह भी यही है। झंझटभरे और confusing हैं
    • मैंने इसे दो बार enable किया। पहली बार enable करने के तुरंत बाद phone पूरी तरह खराब हो गया, और दूसरी बार वह चोरी हो गया
      अब मैं बस randomly generated passwords पर निर्भर करता हूं
    • आगे का रास्ता मुझे FIDO और बहुत सस्ती NFC card keys ही लगता है
      कहीं login करना हो तो wallet से card निकालकर phone या laptop से touch कर दें
      जिस company के paid customers हों, उसके लिए alternate authentication methods support करने की तुलना में, customer के पास card न होने पर उसे physical mail से भेजना ज्यादा उचित हो—card इतने सस्ते होने चाहिए
      ज्यादातर services को शायद second authentication layer की जरूरत भी न हो। किसी ने wallet चुरा लिया तो क्या वह वाकई Reddit account की भी परवाह करेगा
  • मैंने test किया और same account name/email इस्तेमाल करने वाले कई accounts के बीच कोई conflict नहीं था
    हर item में issuer icon भी सही दिखता है, और issuer हर item में registered है
    MS Authenticator कई साल से इस्तेमाल कर रहा हूं और इस तरह की समस्या कभी नहीं आई; और स्वाभाविक रूप से account name या username के लिए हमेशा वही email इस्तेमाल करता हूं
    बस test result लिख रहा हूं। इससे Authenticator या Microsoft के बारे में मेरी राय बदलने वाली नहीं लगती, लेकिन

    • जानना चाहूंगा कि कौन-सा platform है। सुना है वह समस्या, या “feature”, iOS version तक सीमित है
  • कुछ समय तक update न करने के बाद जब मैंने MS Authenticator update किया, तो मेरे साथ भी यह हुआ
    सारा data मिट गया और मैं सभी accounts से lock out हो गया। MS Authenticator कोई सावधानी से बनाया गया product नहीं है

  • करीब 1 साल पहले Google Authenticator app नए version में auto-update हुआ था, तब भी ऐसा ही कुछ हुआ
    update process में मेरे सभी accounts खो गए, और निश्चित रूप से कुछ सबक मिले

    • इस nightmare की वजह से मैं हमेशा MFA QR code का backup रखता हूं, और उसे एक open source app में भी add करता हूं जिससे data का backup कहीं और भी रखा जा सके