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

 (utcc.utoronto.ca)
4 पॉइंट द्वारा GN⁺ 2024-01-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें

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

  • ईमेल पते को अकाउंट के स्थायी आंतरिक पहचानकर्ता के रूप में इस्तेमाल करना समस्याग्रस्त है। लोगों के ईमेल पते किसी संगठन के भीतर भी बदल सकते हैं, और इसके कारण भी वही तरह-तरह के हो सकते हैं जिनसे नाम या लॉगिन जानकारी बदलती है।
  • संगठनों के लिए लोगों को आवंटित ईमेल पते को कभी न बदलना या रीसेट न करना कानूनी रूप से टिकाऊ नहीं हो सकता।
  • ईमेल पते दोबारा इस्तेमाल किए जा सकते हैं या किसी विशेष व्यक्ति को फिर से आवंटित किए जा सकते हैं, जिससे सुरक्षा समस्याएँ पैदा हो सकती हैं।

आंतरिक पहचानकर्ता अर्थहीन होने चाहिए

  • भले ही अकाउंट रिकवरी के लिए ईमेल पता याद रखना पड़े, आंतरिक अकाउंट पहचानकर्ता अर्थहीन होना चाहिए। इससे लंबे समय में सिस्टम प्रबंधन सरल होता है।
  • OIDC जैसे authentication सिस्टम में ईमेल पते की जगह एक unique और permanent internal ID का उपयोग करना चाहिए।
  • ईमेल पते को बहुत अधिक अर्थ देने से सुरक्षा समस्याएँ पैदा हो सकती हैं।

GN⁺ की राय

  • इस लेख की सबसे महत्वपूर्ण बात यह है कि ईमेल पते को स्थायी अकाउंट पहचानकर्ता के रूप में इस्तेमाल करने से कई तरह की समस्याएँ पैदा हो सकती हैं।
  • यह विषय इसलिए दिलचस्प है क्योंकि बहुत-से सिस्टम user authentication के लिए ईमेल पते का उपयोग करते हैं, लेकिन यह लेख बताता है कि यह प्रथा संभावित सुरक्षा जोखिम और प्रबंधन संबंधी समस्याएँ पैदा कर सकती है।
  • यह लेख software engineers को internal system design के दौरान ध्यान में रखे जाने वाले महत्वपूर्ण सुरक्षा और प्रबंधन पहलुओं के बारे में जागरूकता बढ़ाने में मदद कर सकता है।

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

1 टिप्पणियां

 
GN⁺ 2024-01-01
Hacker News राय

  • ईमेल और यूज़रनेम की सीमाएँ

    • ईमेल पता बदल सकता है, और लोग अपने पुराने ईमेल तक पहुँच खो सकते हैं।
    • यूज़रनेम को लेकर असंतोष है, और लोग user53267 जैसे नामों की जगह गैर-अद्वितीय नाम चुनना चाहते हैं।
    • डिवाइस खो जाने के मामले भी होते हैं, और cookie में सेव किया गया गुप्त UUID या डिवाइस की passkey अकेले पर्याप्त नहीं है।
    • कुछ लोगों के लिए ईमेल या यूज़रनेम स्थिर हो सकते हैं, लेकिन बहुत कम लोग कई सालों तक एक ही primary device इस्तेमाल करते हैं।
    • work email account (first.last@company.com) और vendor software में 'Google se login' इस्तेमाल करने के तरीके से अक्सर समस्याएँ पैदा होती हैं.
    • लोग शादी करते हैं, तलाक लेते हैं, gender transition करते हैं, और नई संस्कृति में जाकर नया नाम चुनते हैं। नाम और ईमेल पते बदलते रहते हैं।
    • OIDC जैसी चीज़ों को ऐसे standard API की ज़रूरत पड़ सकती है जो यूज़रनेम और ईमेल पते बदलने की सुविधा दे।

  • व्यक्तिगत बचाव के तरीके

    • Gmail को AI algorithm द्वारा मनमाने ढंग से लॉक किया जा सकता है, और समस्या होने पर राहत पाना मुश्किल होता है।
    • Yahoo पुराने ईमेल से authentication माँग सकता है, जिससे पहुँच खो सकती है।
    • Yahoo/AOL/Tutanota/Protonmail आदि में अगर अक्सर login न करें तो अकाउंट अपने-आप delete हो सकता है।
    • self-hosting के लिए शुरुआती ईमेल ज़रूरी होता है, और उसे खो देने पर hosting account तक पहुँच खो सकती है।
    • फ़ोन खराब हो जाने पर Duo push समस्या बन सकता है।
    • SMS authentication फ़ोन खराब होने, प्लान तक पहुँच खोने, या कर्मचारियों से जुड़ी सुरक्षा समस्याओं के कारण जोखिमपूर्ण हो सकता है।
    • फ़िलहाल university Gmail address इस्तेमाल करना सबसे अच्छा तरीका लगता है। समस्या होने पर university support center से मदद माँगी जा सकती है।

  • ईमेल और फ़ोन नंबर की समस्याएँ

    • ईमेल स्थायी identifier के रूप में अच्छा नहीं है, और पहचान के हिस्से के रूप में फ़ोन नंबर का इस्तेमाल इससे भी खराब है।
    • अपने domain के ज़रिए लगभग 20 साल तक एक ही ईमेल इस्तेमाल किया है, लेकिन उसी अवधि में लगभग 12 फ़ोन नंबर बदल चुके हैं।
    • विदेश में रहते हुए भी अमेरिकी नंबर बनाए रखने के लिए हर महीने AT&T को लगभग $150 चुका रहे हैं।

  • public key email address का प्रस्ताव

    • public key email address (<pk-12345@gmail.com>) को support करने का विचार रखा गया।
    • अगर Google या Hotmail सेवा बंद भी कर दें, तो किसी दूसरी सेवा में private key से authenticate करके उसी अकाउंट तक पहुँचा जा सके।
    • ईमेल client ऐसे addresses को map कर सके या public key के ज़रिए track कर सके।
    • इस विचार के लिए बड़े पैमाने पर support चाहिए, लेकिन इस पर विचार करना सार्थक है।

  • UUID का उपयोग

    • राय है कि random UUID सबसे अच्छा है।
    • यूज़र के शुरुआती ईमेल को hash करना, सिर्फ salting के साथ, पर्याप्त नहीं हो सकता।

  • कई ईमेल पतों को जोड़ना

    • सिस्टम को इस तरह बदला जा रहा है कि एक अकाउंट से कई ईमेल पते जोड़े जा सकें।
    • student discount देने के लिए educational email verify करना सबसे आसान तरीका है, लेकिन ज़्यादातर लोग उसी ईमेल से sign up नहीं करना चाहते।
    • कई ईमेल की अनुमति देकर दोनों दुनियाओं के फायदे लिए जा सकते हैं।

  • ईमेल पते और भौतिक पते के बीच जुड़ाव की समस्या

    • एक energy supplier का उदाहरण, जो एक ईमेल पते को कई physical addresses के लिए इस्तेमाल नहीं करने देता।
    • online account सेट करते समय वही ईमेल पता इस्तेमाल न कर पाने से समस्या होती है।

  • client-side समाधान

    • domain के लिए भुगतान करके ईमेल alias पर 100% नियंत्रण रखा जा सकता है।
    • मौजूदा provider (Google) के साथ समस्या होने पर भी अपने server पर mail host करके अकाउंट खोजे जा सकते हैं और alias ownership बनाए रखी जा सकती है।

  • पहचान और authentication की समस्या

    • पहचान और authentication को मिलाकर चर्चा करने की समस्या है।
    • पहचान की समस्या नाम, ईमेल, ID card आदि जैसे इंसानों से जुड़े अद्वितीय string या number के ज़रिए व्यावहारिक रूप से हल हो जाती है।
    • authentication की समस्या यह सत्यापित करना है कि व्यक्ति वास्तव में कौन है, और यह आधुनिक तकनीक के सामने सबसे बड़ी समस्याओं में से एक है।
    • password, geographic location, IP address, email, phone number, security token और certificate के combination का इस्तेमाल किया जाता है, लेकिन ये सिस्टम नियमित रूप से breach होते रहते हैं, और सुरक्षा कड़ी करने पर वैध users पर नकारात्मक असर पड़ता है।

  • backend समस्या

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