VPS GOAT / गाइड / अकाउंट की बनाम ईमेल लॉगिन: VPS होस्टिंग के लिए Mullvad मॉडल कैसे काम करता है

गुमनामी

अकाउंट की बनाम ईमेल लॉगिन: VPS होस्टिंग के लिए Mullvad मॉडल कैसे काम करता है

Anonymity · 8 मिनट रीड

संक्षिप्त उत्तर: अकाउंट की लॉगिन सिस्टम आपके ईमेल पते और पासवर्ड की जगह एक ही रैंडम जनरेट की गई स्ट्रिंग इस्तेमाल करता है, जो आपकी पहचान पूछे बिना ही आपको प्रमाणित कर देती है। Mullvad ने VPN के लिए इस मॉडल को लोकप्रिय बनाया, और तेज़ी से बढ़ती संख्या में प्राइवेसी-फर्स्ट होस्ट अब VPS अकाउंट्स पर भी वही तर्क लागू करते हैं: कोई ईमेल आवश्यक नहीं, आपकी पहचान से जुड़ा कोई पासवर्ड रीसेट नहीं, बस एक की जिसे आप खुद जनरेट करते हैं, संभालते हैं, और जिसकी पूरी ज़िम्मेदारी आप पर होती है।

अकाउंट की असल में क्या है

अकाउंट की एक लंबी, रैंडम जनरेट की गई पहचान है, आमतौर पर अंकों की एक स्ट्रिंग या अल्फ़ान्यूमेरिक टोकन, जिसे कोई सेवा साइनअप पर यूज़रनेम, ईमेल पता या पासवर्ड इकट्ठा करने के बजाय जारी करती है। अकाउंट की मॉडल क्रेडेंशियल को ही पहचान मानता है: जो भी स्ट्रिंग को रखता है, वही अकाउंट का मालिक है, बस इतना ही।

सिस्टम यह वेरिफाई करता है कि दी गई स्ट्रिंग एक वैध, सक्रिय की है, न कि किसी दावा की गई पहचान को। यह अंतर मायने रखता है। एक पारंपरिक साइनअप फॉर्म किसी असली या बनावटी पहचान के इर्द-गिर्द प्रोफ़ाइल बनाता है, जिसमें ईमेल, कभी-कभी नाम, कभी-कभी सुरक्षा प्रश्न शामिल होते हैं। अकाउंट की पहचान को पूरी तरह छोड़ देती है और एक शुद्ध बियरर क्रेडेंशियल की तरह काम करती है, ठीक वैसे जैसे किसी फिज़िकल सेफ-डिपॉज़िट-बॉक्स की चाबी काम करती है: जो भी इसे पकड़े, उसे एक्सेस मिल जाता है, और बॉक्स कभी नहीं पूछता कि वह कौन है।

साइनअप पर सर्वर-साइड या क्लाइंट-साइड जनरेट की जाती है, कभी भी व्यक्तिगत डेटा से नहीं निकाली जाती
एक ही स्ट्रिंग में यूज़रनेम और पासवर्ड दोनों का काम करती है
आमतौर पर 12-16+ अंकों की या एक लंबी अल्फ़ान्यूमेरिक टोकन, जो ब्रूट-फोर्सिंग झेलने लायक बनाई जाती है
प्रोवाइडर द्वारा केवल एक साल्टेड हैश के रूप में स्टोर की जाती है, कभी प्लेनटेक्स्ट में नहीं

Mullvad मॉडल, चरण दर चरण

स्वीडन की प्रोवाइडर Mullvad VPN को आमतौर पर लगभग 2016 से प्राइवेसी टूल्स के बीच इस तरीके को मुख्यधारा में लाने का श्रेय दिया जाता है। इसका अकाउंट नंबर सिस्टम इस तरह काम करता है: एक नया यूज़र साइट पर जाता है, साइनअप बटन क्लिक करता है, और उसे तुरंत 16 अंकों का नंबर मिल जाता है। कोई फॉर्म नहीं, कोई ईमेल फ़ील्ड नहीं, किसी असली इनबॉक्स से जुड़ी कोई वेरिफिकेशन नहीं।

उस बिंदु से, अकाउंट नंबर ही पूरा रिश्ता है। सर्विस टाइम जोड़ने के लिए, यूज़र नकद, प्रीपेड वाउचर, या क्रिप्टोकरेंसी से भुगतान करता है, सिर्फ उस नंबर का संदर्भ देकर। किसी नए डिवाइस पर लॉगिन करने के लिए, वे बस नंबर टाइप करते हैं। यदि वे इसे खो देते हैं, तो कोई पासवर्ड-रीसेट फ्लो नहीं है, क्योंकि रीसेट लिंक भेजने के लिए कोई ईमेल पता ही नहीं है। नंबर खुद ही एकमात्र रिकवरी मैकेनिज़्म है, और इसे खोने का मतलब है अकाउंट खोना।

जो VPS होस्ट इस मॉडल को अपनाते हैं, वे सर्वर होस्टिंग पर भी यही तर्क लागू करते हैं: अकाउंट की डैशबोर्ड, API, और बिलिंग को प्रमाणित करती है, और यही एकमात्र चीज़ है जो किसी ग्राहक को उसकी वर्चुअल मशीनों से जोड़ती है। VPS GOAT इसी तरीके का उपयोग करता है, साइनअप पर ईमेल पता इकट्ठा करने के बजाय एक ही गुमनाम अकाउंट की जारी करता है।

साइनअप पेज पर जाएँ और एक क्लिक में की जनरेट करें, कोई फॉर्म फ़ील्ड नहीं
क्रिप्टो (Monero, Bitcoin, USDT, Litecoin, Ethereum, या Paymento जैसे प्रोसेसर के ज़रिए Tron) से अकाउंट या किसी खास ऑर्डर को फंड करें
आगे किसी भी डिवाइस पर लॉगिन करने के लिए उस की का उपयोग करें
की को उतनी ही सावधानी से स्टोर करें जितनी आप अपने पूरे इन्फ्रास्ट्रक्चर की रक्षा करने वाले पासवर्ड की करते हैं, क्योंकि यही वह है

ईमेल-आधारित साइनअप एक प्राइवेसी देनदारी क्यों है

ईमेल पते तटस्थ लगते हैं, लेकिन वे सबसे मज़बूत कोरिलेशन हैंडल में से एक हैं जो कोई होस्टिंग प्रोवाइडर रख सकता है। एक पता अक्सर कई सेवाओं में दोबारा इस्तेमाल होता है, ब्रीच-एग्रीगेशन साइटों द्वारा इंडेक्स किया जाता है, और हर लॉगिन पर मेल प्रोवाइडर द्वारा IP मेटाडेटा के साथ लॉग किया जाता है। एक बार जब कोई होस्टिंग अकाउंट किसी इनबॉक्स से जुड़ जाता है, तो वह इनबॉक्स सबसे कमज़ोर कड़ी बन जाता है, चाहे होस्ट की अपनी सुरक्षा कितनी भी अच्छी क्यों न हो।

ईमेल आमतौर पर किसी कानूनी डेटा अनुरोध में सबसे पहले नाम लिया जाने वाला भी होता है, क्योंकि यह अक्सर मेल प्रोवाइडर, डोमेन रजिस्ट्रार, या कहीं और जुड़े किसी अकाउंट के ज़रिए असली पहचान तक पहुँचने का सबसे तेज़ रास्ता होता है। साइनअप फ्लो से ईमेल हटाने से जांच की वह पूरी शाखा शुरू होने से पहले ही हट जाती है।

इसमें एक अतिरिक्त लागत भी है: ईमेल पर बने पासवर्ड-रीसेट फ्लो खुद एक अटैक सरफेस हैं। कोई हमलावर जो इनबॉक्स को कॉम्प्रोमाइज़ कर लेता है, चाहे फिशिंग से हो, सिम-स्वैप्ड रिकवरी फोन से हो, या मेल प्रोवाइडर ब्रीच से हो, वह अक्सर होस्ट को सीधे छुए बिना ही होस्टिंग पासवर्ड रीसेट कर सकता है।

आपको क्या मिलता है, और आपको खुद क्या संभालना पड़ता है

अकाउंट की मॉडल जोखिम को खत्म करने के बजाय उसे स्थानांतरित करता है। प्रोवाइडर एक ऐसा व्यक्तिगत डेटा टुकड़ा रखना बंद कर देता है जो कोरिलेशन बनाता है, जो एक वास्तविक और मापने योग्य प्राइवेसी लाभ है। इसके बदले में, यूज़र एक अपारदर्शी स्ट्रिंग की पूरी कस्टडी अपने ऊपर ले लेता है, जिसके पीछे कोई फॉलबैक पहचान नहीं होती।

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

फायदा: साइनअप पर होस्ट द्वारा कोई ईमेल, IP, या नाम कोरिलेशन स्टोर नहीं किया जाता
फायदा: पासवर्ड-रीसेट ईमेल के ज़रिए फिश करने के लिए कुछ भी नहीं है
फायदा: भविष्य में किसी भी ब्रीच या डेटा अनुरोध में उजागर होने वाली फ़ील्ड कम होती हैं
लागत: की खोने का मतलब आमतौर पर अकाउंट स्थायी रूप से खोना है
लागत: की को उतनी ही सावधानी से स्टोर करना पड़ता है जितनी पासवर्ड मैनेजर एंट्री या क्रिप्टो सीड फ्रेज़ की जाती है

VPS होस्टिंग बनाम VPN में अकाउंट कीज़

Mullvad का मॉडल VPN के लिए साफ-सुथरे तरीके से काम करता है क्योंकि अकाउंट में सब्सक्रिप्शन एक्सपायरी डेट के अलावा ज़्यादा कुछ नहीं होता। VPS होस्टिंग दांव बढ़ा देती है: एक अकाउंट की चल रहे सर्वरों, स्नैपशॉट्स, API टोकन्स, और बिलिंग हिस्ट्री तक पहुँच को नियंत्रित कर सकती है, इसलिए खोई या लीक हुई की के परिणाम एक समाप्त हो चुके VPN कनेक्शन से कहीं भारी होते हैं।

जो प्रोवाइडर अकाउंट की मॉडल को VPS होस्टिंग तक बढ़ाते हैं, वे आमतौर पर एक ऐसी परत जोड़ते हैं जिसकी VPN उपयोग-मामले को ज़रूरत नहीं होती: अकाउंट के तहत स्कोप्ड API कीज़, एक सेकंडरी कंट्रोल-पैनल सीक्रेट, और कभी-कभी सपोर्ट के लिए एक वैकल्पिक एन्क्रिप्टेड संपर्क चैनल जो फिर भी डिफ़ॉल्ट रूप से किसी ईमेल इनबॉक्स को अकाउंट से जोड़ने से बचता है। VPS GOAT इसी पैटर्न का पालन करता है, एक अकाउंट की साइनअप, Paymento के ज़रिए बिलिंग, और सर्वर डैशबोर्ड चलाती है, जबकि SSH कीज़ और फ़ायरवॉल नियमों जैसी सर्वर-स्तरीय सुरक्षा को स्वतंत्र रूप से इसके ऊपर परत की तरह जोड़ा जाता है।

सार यह है कि एक अकाउंट की पहचान-आधारित लॉगिन की जगह लेती है, ऑपरेशनल सुरक्षा की नहीं। मज़बूत SSH की प्रबंधन, फ़ायरवॉल अनुशासन, और सर्वर पर ही एन्क्रिप्टेड बैकअप अभी भी पूरी तरह ऑपरेटर की ज़िम्मेदारी है; अकाउंट की केवल कंट्रोल प्लेन के सामने के दरवाज़े की रक्षा करती है।

अकाउंट की को स्टोर और रोटेट करने के सर्वोत्तम तरीके

अकाउंट की को बिल्कुल एक रूट पासवर्ड की तरह मानें जिसके पीछे कोई रिकवरी संपर्क न हो: इसे जनरेट करें, इसे किसी पासवर्ड मैनेजर या एन्क्रिप्टेड ऑफलाइन नोट में दर्ज करें, और इसे कभी भी चैट लॉग, टिकट सिस्टम, या सपोर्ट के लिए शेयर किए गए स्क्रीनशॉट में पेस्ट न करें।

कुछ प्रोवाइडर लॉग-इन रहते हुए एक सेकंडरी या रिप्लेसमेंट की जनरेट करने की अनुमति देते हैं, जो पासवर्ड रोटेशन के सबसे करीब है। जहाँ यह विकल्प मौजूद है, उसे समय-समय पर वैसे ही इस्तेमाल करें जैसे आप SSH की जोड़ी को रोटेट करते हैं, और अपने पासवर्ड मैनेजर में रिकॉर्ड तुरंत अपडेट करें, बाद में नहीं।

की को पासवर्ड मैनेजर एंट्री में स्टोर करें, न कि प्लेनटेक्स्ट फाइल या नोट ऐप में
उच्च-मूल्य वाले अकाउंट्स के लिए एन्क्रिप्टेड USB ड्राइव जैसा ऑफलाइन बैकअप रखें
अनएन्क्रिप्टेड चैनलों पर की कभी न भेजें, सपोर्ट टिकट सहित, जब तक प्रोवाइडर स्पष्ट रूप से सुरक्षित सबमिशन को सपोर्ट न करे
यदि आपको कभी शक हो कि की उजागर हो गई है, तो उसे रोटेट करें, यदि उपलब्ध हो तो प्रोवाइडर के की-चेंज फीचर का उपयोग करके
की को क्रिप्टो वॉलेट सीड फ्रेज़ जितनी ही गंभीरता से लें

अकाउंट की बनाम ईमेल और पासवर्ड लॉगिन
पहलू	अकाउंट की मॉडल	ईमेल और पासवर्ड मॉडल
साइनअप पर इकट्ठा किया गया व्यक्तिगत डेटा	कोई नहीं	ईमेल पता, कभी-कभी नाम या फोन
कोरिलेशन जोखिम	कम, की कहीं और पहचान से जुड़ी नहीं होती	अधिक, ईमेल अक्सर कई सेवाओं में दोबारा उपयोग होता है
पासवर्ड रीसेट फ्लो	कोई नहीं, डिज़ाइन से	ईमेल लिंक, इनबॉक्स कॉम्प्रोमाइज़ के प्रति संवेदनशील
ब्रीच एक्सपोज़र	केवल हैश्ड की, लीक करने के लिए कोई व्यक्तिगत डेटा नहीं	ईमेल प्लस पासवर्ड हैश, एक फिशिंग लक्ष्य
खो जाने पर रिकवरी	आमतौर पर कोई नहीं, डिज़ाइन से	ईमेल-आधारित रीसेट, लेकिन अकाउंट को इनबॉक्स से जोड़ता है
कानूनी अनुरोध सरफेस	केवल भुगतान ट्रेल	ईमेल, IP लॉग, और जुड़े हुए अकाउंट्स
आमतौर पर साथ में उपयोग होता है	क्रिप्टो भुगतान (Monero, Bitcoin, और अन्य)	कार्ड या बैंक बिलिंग

सामान्य प्रश्न

अगर मैं अपनी अकाउंट की खो दूँ तो क्या होगा?+

अधिकांश अकाउंट-की सिस्टम में, Mullvad के सिस्टम सहित, कोई पहचान-आधारित रिकवरी नहीं होती, इसलिए की खोने का मतलब आमतौर पर अकाउंट और उससे बिल किए गए किसी भी चीज़ तक पहुँच स्थायी रूप से खोना है। यही वजह है कि इस मॉडल का उपयोग करने वाले प्रोवाइडर लगातार पासवर्ड-मैनेजर स्टोरेज के साथ-साथ एक ऑफलाइन बैकअप की सलाह देते हैं।

क्या अकाउंट की लॉगिन वाकई ईमेल और पासवर्ड से ज़्यादा सुरक्षित है?+

यह इस पर निर्भर करता है कि 'सुरक्षित' का मतलब क्या है। एक अकाउंट की ईमेल को अटैक सरफेस और कोरिलेशन पॉइंट के रूप में हटा देती है, जो प्राइवेसी सुधारता है और रीसेट-लिंक-के-ज़रिए-फिशिंग जोखिम हटाता है, लेकिन यह किसी भी पहचान-आधारित रिकवरी रास्ते को भी हटा देती है, इसलिए सुरक्षा का बोझ पूरी तरह इस पर आ जाता है कि की को कितनी सावधानी से स्टोर किया गया है।

अगर मैं सिर्फ अकाउंट की का उपयोग करूँ तो क्या प्रोवाइडर फिर भी मेरी पहचान कर सकता है?+

इस मॉडल का उपयोग करने वाले प्रोवाइडर के पास अकाउंट की से जुड़ा कोई ईमेल, नाम, या पासवर्ड नहीं होता, इसलिए पहचान, अगर होती भी है, तो भुगतान ट्रेल या कनेक्शन लॉग जैसे अन्य मेटाडेटा से आनी होगी, और यही वजह है कि अकाउंट-की प्रोवाइडर इस मॉडल को क्रिप्टो भुगतान और न्यूनतम लॉगिंग के साथ जोड़ते हैं।

क्या अकाउंट कीज़ टू-फैक्टर ऑथेंटिकेशन के साथ काम करती हैं?+

हाँ, एक अकाउंट की को उसी तरह सेकंडरी कंट्रोल-पैनल सीक्रेट या हार्डवेयर की के साथ जोड़ा जा सकता है जैसे पासवर्ड के साथ किया जा सकता है, क्योंकि की केवल लॉगिन के 'आप कौन हैं' चरण की जगह लेती है, न कि 'आप अभी भी इस सेशन को पकड़े हुए हैं यह साबित करें' चरण की।

ज़्यादा होस्टिंग प्रोवाइडर अकाउंट की मॉडल का उपयोग क्यों नहीं करते?+

अधिकांश होस्टिंग प्रोवाइडर ऐसे बिलिंग सिस्टम, सपोर्ट टूलिंग, और अनुपालन धारणाओं के इर्द-गिर्द बने हैं जो शुरू से ही ईमेल पता और कानूनी पहचान की अपेक्षा करते हैं, इसलिए गुमनाम की पर स्विच करने का मतलब है साइनअप, बिलिंग, और सपोर्ट को क्रिप्टो भुगतान और एक कस्टडी मॉडल के इर्द-गिर्द फिर से डिज़ाइन करना, जिसे अपनाने का कारण कुछ ही मुख्यधारा के होस्ट के पास है।

ऑफशोर जाने के लिए तैयार हैं?

कोई KYC नहीं, कोई ईमेल नहीं — बस एक अनाम की और क्रिप्टो। ~55 सेकंड में डिप्लॉय करें।

अपना VPS कॉन्फ़िगर करें →