ईमेल पता अकाउंट के 'स्थायी' पहचानकर्ता के रूप में उपयुक्त नहीं है

• सिस्टम के भीतर दीर्घकालिक अकाउंट ID बनाते समय, सिर्फ इसलिए कि OIDC ईमेल पता लौटाता है, उसे स्थायी ID के रूप में इस्तेमाल करने पर बदलाव और पुन:उपयोग की समस्याएँ साथ आ जाती हैं
• ईमेल पता एक ही संगठन के भीतर भी नाम या लॉगिन की तरह बदल सकता है, इसलिए इसे अकाउंट के आधारभूत मान के रूप में लेना पर्याप्त रूप से स्थिर नहीं है
• भले ही पुराने पते पर मेल एक्सेस या फ़ॉरवर्डिंग बनी रहे, फिर भी यह गारंटी नहीं है कि वह पता OIDC authentication जैसे गैर-ईमेल उपयोगों में काम करता रहेगा
• अकाउंट रिकवरी के लिए ईमेल पते की ज़रूरत हो सकती है, लेकिन अगर authentication system कोई अलग unique और permanent ID देता है, तो आंतरिक ID के रूप में वही मान इस्तेमाल करना चाहिए
• भले ही यह मान उपयोगकर्ता को दिखाई न दे, अकाउंट का आंतरिक पहचानकर्ता बेमतलब ID रखना दीर्घकालिक संचालन और security के लिहाज़ से अधिक सरल है

---

ईमेल पते को स्थायी ID के रूप में इस्तेमाल करने का मन क्यों होता है

• हर अकाउंट के लिए आंतरिक पहचानकर्ता बनाते समय ईमेल पता एक स्वाभाविक उम्मीदवार लगता है, क्योंकि OIDC जैसे authentication system ईमेल पता सहित डेटा लौटाते हैं
• लेकिन ईमेल पते को अकाउंट का स्थायी आंतरिक पहचानकर्ता बना देने पर दो समस्याएँ पैदा होती हैं: बदलने की संभावना और पुन:उपयोग की संभावना

जो पता बदल सकता है, उसे आधार मान बनाना मुश्किल है

• सबसे बड़ी समस्या यह है कि ईमेल पता बदल सकता है
  • एक ही संगठन के भीतर भी किसी व्यक्ति का ईमेल पता बदल सकता है
  • यह उन्हीं तरह के कारणों से बदल सकता है जिनकी वजह से किसी व्यक्ति का रोज़मर्रा में इस्तेमाल होने वाला नाम या लॉगिन बदलता है
  • संगठन द्वारा दिए गए ईमेल पते में बदलाव या पुनःजारी करने से इनकार करना कई जगह कानूनी रूप से लंबे समय तक टिक पाना मुश्किल बना देने जितना कठोर हो सकता है
• भले ही पुराना ईमेल पता पूरी तरह गायब न हो, फिर भी वह स्थायी पहचानकर्ता के लिए पर्याप्त नहीं है
  • पुराने पते पर एक्सेस या फ़ॉरवर्डिंग बनी रह सकती है
  • फिर भी यह ज़रूरी नहीं कि पुराना पता OIDC authentication जैसे गैर-ईमेल उपयोगों में काम करता रहे
  • उपयोगकर्ता असुविधाजनक पुराने ईमेल पते की बजाय अपना वर्तमान नया पता इस्तेमाल करना चाहेंगे

पुन:उपयोग और रिकवरी ईमेल को अलग तरह से संभालना चाहिए

• एक दूसरी, अपेक्षाकृत छोटी समस्या यह है कि इस बात की कोई गारंटी नहीं होती कि संगठन ईमेल पते का पुन:उपयोग नहीं करेगा
  • सामान्य तौर पर उसका पुन:उपयोग हो सकता है
  • खासकर अधिक पसंद किए जाने वाले पते किसी प्रभावशाली व्यक्ति की इच्छा पर अपवादस्वरूप दोबारा इस्तेमाल या पुनःआवंटित किए जा सकते हैं
• अगर अकाउंट रिकवरी पंजीकृत ईमेल पते के माध्यम से होनी है, तो ईमेल पता सहेजना पड़ सकता है
  • लेकिन अगर OIDC जैसी व्यवस्था सैद्धांतिक रूप से unique और permanent आंतरिक ID देती है, तो उसी आंतरिक ID का उपयोग करना चाहिए
• भले ही अकाउंट रिकवरी के लिए ईमेल सहेजना पड़े, अकाउंट का आंतरिक पहचानकर्ता बेमतलब ID होना चाहिए
  • भले ही यह मान उपयोगकर्ता को दिखाया न जाए, लंबे समय में संचालन अधिक सरल हो जाता है
• ईमेल पते को जरूरत से ज़्यादा अर्थ देने पर security समस्याएँ भी छिपी हो सकती हैं

[GN⁺]

Hacker News टिप्पणियां

• अच्छा identity identifier जैसी कोई चीज़ नहीं है
  ईमेल बदल जाते हैं, और पुराने ईमेल का access भी खो सकता है
  बहुत से लोगों को usernames भी पसंद नहीं होते, इसलिए वे user53267 जैसे बेअर्थ unique नाम के बजाय non-unique नाम चुनना चाहते हैं
  डिवाइस भी खो जाते हैं, इसलिए cookies में secret UUID सेव करना या डिवाइस की passkey इस्तेमाल करना भर समाधान नहीं है
  कोई आदर्श समाधान नहीं है; कई तरीकों को मिलाना पड़ता है। कुछ लोगों के लिए ईमेल लंबे समय तक स्थिर रहता है और identity identifier के तौर पर अच्छा होता है, लेकिन दूसरों के लिए username स्थिर होता है, इसलिए वे उसे पसंद करते हैं। हालांकि मैंने बहुत कम लोगों को देखा है जो दशकों की तो बात छोड़िए, कुछ सालों से ज़्यादा वही primary डिवाइस इस्तेमाल करते हों, इसलिए device-based पहचान शायद अच्छी तरह काम नहीं करेगी
  यह खासकर work email [e-mail] में अक्सर दिखता है। बहुत-सा vendor software Sign in with Google इस्तेमाल करता है, और उस ईमेल address को vendor app के अंदर identifier के रूप में सेव करता है
  शादी, तलाक, transition, सांस्कृतिक परिवेश बदलना, नया नाम चुनना आदि कारणों से नाम बदलते हैं और ईमेल address भी बदलता है
  शायद OIDC जैसी चीज़ों में username change standard API और email address change standard API जैसे नए extensions की ज़रूरत है

  • सबसे पुराना accessible ईमेल 20 साल से ज़्यादा पुराना है। अब उसका इस्तेमाल नहीं करता, लेकिन यह अब तक के किसी भी फोन नंबर या असली address से ज़्यादा समय तक रहा है
    official ID या social security number जैसे public identifiers को छोड़ दें, तो इससे बेहतर करना मुश्किल लगता है
  • लोगों को सब कुछ खोकर नई ज़िंदगी शुरू करने का अधिकार भी है। कुछ ही दशकों पहले तक यह सचमुच संभव था
  • OIDC पहले से ही यह requirement रखकर इस समस्या को संभालता है कि sub claim reassign नहीं होना चाहिए और unique होना चाहिए: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...
    बेशक, इसका मतलब है कि ID token के sub में email address नहीं डालना चाहिए
  • ऐसे email changes में मेरा सबसे “पसंदीदा” मामला contractor suffix change जैसा खुद बनाया हुआ issue है
    मैंने एक ऐसी company देखी है जहां employee में convert होने पर बिल्कुल नया account बनाना पड़ता था, और simple, unified permission system न होने के कारण conversion के तुरंत बाद पिछले दिन तक जिन systems तक access था, उन्हें वापस पाने में लगभग 3 हफ्ते लग गए
    और मज़ेदार बात यह है कि वही company customers को complex account systems देने का बहुत काम करती है, और ऐसे issues को आसानी से handle करने वाला external identity system भी रखती है। लेकिन उस external identity system को maintain करने वाले internal employees पर उसे लागू नहीं करती
  • Discord का पुराना तरीका, यानी email और display name को अलग रखना, अच्छा था
    सबके साथ number लगा होता था, इसलिए number का कोई खास मतलब नहीं था। जब यह unique account ID में बदला तो थोड़ी निराशा हुई, और उन्होंने ऐसा क्यों बदला यह अब भी सोचता हूं

• एक व्यक्ति के तौर पर इस समस्या से निपटने का सबसे अच्छा तरीका क्या है?
  Gmail AI algorithms की वजह से अचानक lock हो सकता है या account ban हो सकता है, और कुछ गलत हो जाए तो कोई remedy नहीं है
  Yahoo ने हाल ही में login करते समय 15 साल से access न किए गए inactive email से verify करने को कहा, इसलिए access खो गया। किस्मत से email client तक access था, इसलिए important accounts move कर सका
  Yahoo/AOL/Tutanota/Protonmail/और कई अन्य, अगर आप पर्याप्त बार login नहीं करते, तो account auto-delete कर देते हैं। Protonmail अभी नहीं करता, लेकिन terms के तहत इसकी अनुमति है
  self-hosting में भी शुरुआत से ही सारी infrastructure के लिए email चाहिए। अगर उस email का access खो जाए, तो payment notifications भी छूट सकते हैं और hosting account भी खो सकता है। payment notifications ऐसे email पर जा रहे थे जो IMAP support नहीं करता था और जिसे मैं लगभग check नहीं करता था, इसलिए domain खोते-खोते बचा। अगर आप professional system administrator नहीं हैं और maintenance के लिए पर्याप्त समय नहीं है, तो hacking का risk भी बढ़ जाता है
  Duo push में phone खराब हो जाए तो सब खत्म, और SMS authentication में phone damage, plan access खोना, internal employee द्वारा code leak जैसे issues हैं
  अंत में मैंने university Gmail address इस्तेमाल करने का फैसला किया। उन्होंने वादा किया है कि alumni भी इसे रख सकते हैं, और अगर कुछ गलत हो जाए—शायद phone खोने से 2FA खोना—तो एक ठीक-ठाक alumni support center है
  कहीं न कहीं इंसानी support desk होना बहुत ज़रूरी है, जहां बात की जा सके। फिर भी पक्का नहीं कि यह सबसे अच्छा है या नहीं, और सोचता हूं कि क्या Google side का risk अब भी बचा है

  • जो best solution छूट गया, वह है अपना domain और Gmail जैसी hosted email service इस्तेमाल करना
    जैसा कहा, अगर lock हो जाए तो “बस” provider बदल दें, और ज्यादा से ज्यादा कुछ घंटों के email ही खोएंगे
  • iCloud कैसा रहेगा? सिद्धांततः account ban संभव होगा, लेकिन कम से कम Apple में आम तौर पर remedy होती है और किसी इंसान से बात कर पाने का अहसास होता है

• मैं इस बात से सहमत हूँ कि ईमेल स्थायी पहचानकर्ता के रूप में अच्छा नहीं है। लेकिन पहचान के हिस्से के रूप में फोन नंबर इस्तेमाल करना और भी खराब है
  मैं अपने खुद के domain पर लगभग 20 साल से वही ईमेल इस्तेमाल कर रहा हूँ, लेकिन इसी अवधि में मेरा फोन नंबर करीब 12 बार बदल चुका है। अक्सर देखा है कि वेबसाइटों पर 2-step पुराने नंबर से चालू रहता है, या लोग यह भूल जाते हैं कि उस साइट पर उन्होंने पुराना नंबर ही रजिस्टर किया था
  विदेश में रहते हुए भी मैं AT&T को हर महीने करीब 150 डॉलर टैक्स देकर अपना अमेरिकी नंबर बनाए रखता हूँ, क्योंकि कुछ साइटें अभी भी उसी नंबर पर login code भेजती हैं, और डर है कि अगर नंबर छोड़ दिया तो उन अहम सेवाओं तक access खो दूँगा जिनमें update करना भूल गया हूँ या जहाँ अमेरिकी नंबर जरूरी है

  • DIDww जैसी VoIP कंपनी में नंबर port कर दें तो उसे महीने के 2.50 डॉलर में बनाए रखा जा सकता है, और चाहें तो आए हुए SMS inbox में भी भेजे जा सकते हैं
    बाद में अगर फिर किसी mobile account में वही नंबर इस्तेमाल करना चाहें, तो अपनी पसंद के carrier में वापस port कर सकते हैं
  • विदेश में इस्तेमाल के लिए अमेरिकी नंबर बनाए रखने पर इतना ज्यादा खर्च करने की जरूरत नहीं है
    जहाँ संभव हो, 2-step authentication को Google Authenticator जैसे app पर बदल दें, और नंबर को Google Voice में ले जाएँ; इससे पुराने नंबर पर SMS मुफ्त में मिल सकते हैं
    अगर Google को बिल्कुल शामिल नहीं करना चाहते, तो time-based authentication के लिए कई और apps हैं, और SMS के लिए www.tossabledigits.com भी इस्तेमाल कर सकते हैं
  • समझ नहीं आता कि आप इतना ज्यादा क्यों दे रहे हैं। नंबर को किसी VoIP provider में port कर दें तो महीने के कुछ डॉलर ही लगेंगे
    सामान्य mobile service के हिसाब से भी यह रकम बहुत ज्यादा है। मैं दो lines के लिए भी महीने के 100 डॉलर से कम देता हूँ
  • VoIP पर ले जाने की सलाह से सहमत हूँ
    पहले जब मैं शिफ्ट हुआ था, तो मेरा personal office phone number नए इलाके में allowed नहीं था, लेकिन किस्मत से उसे VoIP account में port किया जा सका
    उस समय internet धीमा था, इसलिए कुछ समय तक Ethernet phone adapter इस्तेमाल किया, और बाद में उस नंबर को सिर्फ receive-only के लिए रखा। voice calls और fax, दोनों email पर forward होते हैं
    20 साल से ज्यादा समय से यह अच्छी तरह काम कर रहा है। जोड़ने के लिए कोई device नहीं है, इसलिए सालाना खर्च भी काफी कम है
    कभी शायद phone लगाकर modern internet का फायदा उठाऊँ, लेकिन अभी वाला तरीका पसंद है और यह अच्छा है कि मैं किसी खास location से बंधा नहीं हूँ
  • carrier बदलने पर भी phone number साथ ले जाया जा सकता है। email address के साथ ऐसा नहीं है

• मेरा अनुभव भी यही है। निजी तौर पर मुझे लगता है कि random UUID सबसे अच्छा है
  user के शुरुआती email का hash भी आदर्श नहीं है। सिर्फ salting काफी नहीं हो सकती, और दूसरे लोग यह मान सकते हैं कि किसी भी input email को सुरक्षित रूप से hash किया जा सकता है

  • database class में पढ़ी गई natural key जैसी चीज क्या कभी वाजिब होती है?
    असल काम में तो मैं हमेशा auto-increment integer या random string/UUID को primary key बनाता हूँ
  • identifier को “permanent” रखने की गारंटी देने का एकमात्र तरीका है उसे ऐसा चुनना जिसे बदलने की लोगों के पास कोई वजह ही न हो
    उसका phone number, email address, नागरिकता-शैली के national ID, नाम, fingerprint जैसी real-world properties से कोई संबंध नहीं होना चाहिए, जिनकी लोगों को परवाह होती है
    random string इस शर्त पर बिल्कुल फिट बैठती है। sequential integer भी ठीक है, लेकिन उसे guess करना आसान होता है, इसलिए अतिरिक्त security उपायों की जरूरत पड़ सकती है
  • UUID की बजाय मैं sequential UID पसंद करता हूँ, लेकिन मूल बात वही रहती है

• public key email address को support करने का क्या विचार है? उदाहरण के लिए . जैसी चीज और . जैसी चीज को बराबर मानना
  एक से signup करने के बाद दूसरे से भी login या account recovery हो सके। अगर Google मुझे ban कर दे या Hotmail बंद हो जाए, तो मैं किसी दूसरी service पर जाकर private key से authenticate करके वही account खोल सकूँ
  जाहिर है, सुविधाजनक नाम इस्तेमाल करने के लिए alias की प्रक्रिया चाहिए होगी, लेकिन लगता है mail client को ऐसे addresses map करने होंगे या कम से कम public key के साथ track करने होंगे
  यह end-to-end encrypted email को शामिल कराने का मौका भी बन सकता है। यह बड़े पैमाने पर लगभग कभी जड़ नहीं जमा पाया
  सच में काम करने के लिए बड़ी कंपनियों का support चाहिए होगा, लेकिन थोड़ी देर सोचने पर यह काफी मजबूत लगता है। बस यही कमी है कि अभी कोई इसे support नहीं करता

  • हैरानी है कि इस thread में Decentralized Identity Foundation अभी तक नहीं आया: https://identity.foundation/
    provider या central authority पर निर्भर हुए बिना, अपनी identity खुद own करने के तरीके से web पर पहचान और communication के नए तरीके बन रहे हैं

• मेरी पिछली energy supplier British Gas (Centrica के स्वामित्व वाली) एक email address को दो या अधिक real addresses के लिए इस्तेमाल करने की अनुमति नहीं देती थी
  घर बदलने के बाद जब मैंने online account “set up” करने की कोशिश की, तो current address details देखने पर हर बार HTTP 500 आता था
  phone पर पूछने पर उन्होंने कहा कि पुराने address का energy account बंद होने के बावजूद “एक ही email address कई postal addresses के लिए इस्तेमाल नहीं किया जा सकता”

  • +whatever trick इस्तेमाल कर सकते हैं। Gmail हो तो dot . trick भी चलती है
  • तरीका खराब है, लेकिन अगर email के लिए अपना domain इस्तेमाल करते हैं तो यह असल समस्या नहीं है

• अभी हम email system को बदल रहे हैं ताकि एक account में कई linked email addresses allow किए जा सकें
  इसकी एक मुख्य वजह यह है कि हम student discount देते हैं। account पर discount लगाने का सबसे आसान तरीका यह check करना है कि email किसी educational institution का address है या नहीं। जैसे .edu, .ac.uk वगैरह
  लेकिन लगता है कि ज्यादातर लोग असल में उस email से signup नहीं करना चाहते। कई emails allow करने से दोनों फायदे मिल जाते हैं
  काश हमने शुरुआत से ही ऐसा किया होता

  • अमेरिका में यह ध्यान रखना चाहिए कि university से graduate होने के बाद भी कई लोगों को .edu alumni forwarding address मिल सकता है
    मेरे पास एक काफी बढ़िया address है। मैंने जल्दी apply कर दिया था, इसलिए उसमें बस मेरा नाम है
    हालांकि मैं उसे ज्यादा इस्तेमाल नहीं करता। शुरुआती दिनों में forwarding कभी-कभी unreliable थी, लेकिन अब शायद बेहतर हो गई होगी
    व्यावहारिक रूप से मेरा Gmail address पहले ही लगभग दशकों से stable रहा है, और लगता नहीं कि बदलेगा
    वैसे भी अपना edu address मैं बहुत कम लोगों को बताता हूँ

• सबसे elegant न सही, लेकिन client-side solution मौजूद है
  अगर आप खुद domain का खर्च उठाकर उसे maintain करते हैं, तो email aliases पर 100% control रख सकते हैं
  मौजूदा provider Google के बंद हो जाने पर भी आप खुद mail host करके account recover कर सकते हैं और alias ownership बनाए रख सकते हैं

  • अगर domain expire हो जाए तो क्या?

• मुझे लगता है यह backend की समस्या है। यूज़र को दिखने वाला ID ईमेल हो सकता है, लेकिन system data में primary key ईमेल नहीं होनी चाहिए
  क्या अभी भी कहीं ऐसा किया जाता है? ईमेल जैसी चीज़ को identifier की तरह इस्तेमाल करने के बजाय, उसे किसी असली unique ID (UUID या sequence-based auto-increment value) से map करने वाली lookup table रखना सबसे बुनियादी database design का मुद्दा है
  लेख में यह फर्क साफ़ नहीं किया गया है, इसलिए यह ऐसे भी पढ़ा जा सकता है मानो यूज़र को इस abstraction को समझना चाहिए

  • सही। यह तो high school स्तर की database class के exam question जैसा है, लेकिन हैरानी की बात है कि कई adult developers database के बारे में रुककर सोचते ही नहीं

• कुछ भी हमेशा के लिए नहीं होता। इंसान की पूरी उम्र तक stable रहने वाली चीज़ें भी बहुत कम हैं
  आसानी से scan किए जा सकने वाले biometric markers भी पर्याप्त बड़े population group में reliably unique नहीं होते
  ईमेल address को ऐसे use के लिए इसलिए चुना गया, क्योंकि वे काफी लंबे समय तक stable और unique रहते हैं
  phone number भी पहले की तुलना में ज्यादा sticky identifier बन गया है, और अब useful identifier के रूप में ईमेल जैसा ही हो गया है
  ईमेल और phone number दोनों अक्सर खो जाते हैं, और कई बार एक साथ खो जाते हैं
  backup email address ही जवाब है
  GitHub identity handling काफी अच्छी तरह करता है, ऐसा मुझे लगता है, लेकिन वह अभी भी password इस्तेमाल करता है। password खराब हैं