क्या पासवर्ड के आधार पर प्रमाणीकरण के लिए निजी, अनुपयोगी URL समान हैं?

128

मैं वेब पर एक संसाधन को उजागर करना चाहता हूं। मैं इस संसाधन की रक्षा करना चाहता हूं: यह सुनिश्चित करने के लिए कि यह केवल कुछ व्यक्तियों के लिए ही सुलभ है।

मैं किसी प्रकार का पासवर्ड-आधारित प्रमाणीकरण सेट कर सकता था । उदाहरण के लिए, मैं केवल एक वेब सर्वर के माध्यम से संसाधन तक पहुंच की अनुमति दे सकता हूं जो फ़ाइल की सेवा करने से पहले सही क्रेडेंशियल (शायद कुछ उपयोगकर्ताओं के बैकिंग डेटाबेस के खिलाफ) के लिए आने वाले अनुरोधों की जांच करता है।

वैकल्पिक रूप से मैं सिर्फ एक निजी URL का उपयोग कर सकता था । उदाहरण के लिए, मैं केवल कुछ असंभव-से-अनुमानित पथ पर संसाधन को होस्ट कर सकता हूं, उदाहरण के लिए https://example.com/23idcojj20ijf..., जो सटीक स्ट्रिंग को जानने वालों तक पहुंच को प्रतिबंधित करता है।

इस संसाधन का उपयोग करने के इच्छुक एक ईविलवेअर के दृष्टिकोण से, क्या ये दृष्टिकोण समतुल्य हैं? यदि नहीं, तो क्या उन्हें अलग बनाता है? और जहां तक स्थिरता है, क्या किसी भी दृष्टिकोण के लिए पेशेवरों और विपक्ष हैं कि मुझे एक या दूसरे को लागू करने से पहले पता होना चाहिए?

security authentication

— GladstoneKeep
स्रोत

45

यह दृष्टिकोण आमतौर पर केवल पासवर्ड रीसेट जैसी चीजों के लिए प्रमाणीकरण के बिना उपयोग किया जाता है । अमिट लिंक आमतौर पर समय की एक छोटी अवधि के भीतर समाप्त हो जाती है, और इसका उपयोग केवल पहले से ही अर्ध-प्रमाणित व्यक्ति द्वारा किया जा सकता है (यानी वेबसाइट पहले से ही उस ईमेल पते को जानती है जिससे लिंक भेजा गया था)।

— रॉबर्ट हार्वे

6

संबंधित पर चर्चा। सुरक्षा: सुरक्षा

— मार्क

9

@MonkeyZeus यह अस्पष्टता के माध्यम से सुरक्षा नहीं है। रहस्य, जो सामान्य रूप से एक पासवर्ड है, इस मामले में एक URL है।

— डेविड मम

16

@MonkeyZeus: सुरक्षा-थ्रू-अस्पष्टता तंत्र के कार्यान्वयन को गुप्त रखने के लिए संदर्भित करती है , अस्पष्ट कुंजियों का उपयोग नहीं करती है। यदि अस्पष्ट url अस्पष्टता के माध्यम से सुरक्षा है, तो मजबूत पासवर्ड भी हैं।

— जैक्सबी जूल

1

@GladstoneKeep URL शॉर्टर्स को ध्यान में रखें। एक बार अगर कोई दुर्भावनापूर्ण उपयोग करता है तो लिंक का अनुमान लगाना / लिखना आसान हो जाएगा।

— RookieTEC9

203

एक निजी URL क्रेडेंशियल के साथ प्रमाणीकरण की तुलना में कुछ हद तक कमजोर है, भले ही URL का बिट आकार क्रेडेंशियल्स के समान हो। कारण यह है कि URL अधिक आसानी से "लीक" हो सकता है। इसे ब्राउज़र में कैश्ड किया जाता है, सर्वर पर लॉग ऑन किया जाता है। यदि आपके पास आउटबाउंड लिंक हैं, तो निजी URL अन्य साइटों पर रेफरर हेडर में दिखाई दे सकता है। (यह आपके कंधे के ऊपर से देख रहे लोगों द्वारा भी देखा जा सकता है।)

अगर यह (दुर्घटना से या उपयोगकर्ता द्वारा लापरवाही के कारण) लीक हो जाता है, तो यह Google द्वारा सार्वजनिक और यहां तक कि अनुक्रमित किया जा सकता है, जो एक हमलावर को आसानी से आपकी साइट पर सभी लीक किए गए URL की खोज करने की अनुमति देगा!

इस कारण से, निजी URL का उपयोग आमतौर पर केवल एक-शॉट संचालन जैसे पासवर्ड रीसेट के लिए किया जाता है, और आमतौर पर वे केवल सीमित समय के लिए सक्रिय होते हैं।

सूचना सुरक्षा पर एक संबंधित थ्रेड है: क्या रैंडम यूआरएल प्रोफाइल फोटो की सुरक्षा का एक सुरक्षित तरीका है ? - एक उत्तर इस कहानी को साझा करता है : Google पर कर रिटर्न समाप्त होने के बाद ड्रॉपबॉक्स पुराने साझा लिंक को निष्क्रिय कर देता है । तो यह सिर्फ एक सैद्धांतिक जोखिम नहीं है।

— JacquesB
स्रोत

7

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

— स्टीव जेसोप

4

मैं कहूंगा कि उपयोगकर्ताओं को सीमित सफलता के साथ, उनके पासवर्ड की सुरक्षा के लिए सिखाया जाता है, लेकिन उनके URL की सुरक्षा के लिए नहीं।

— svavil

1

आपको जोड़ना चाहिए, कि निजी URL में एक पैरामीटर का उपयोग करके कई तकनीकी चिंताओं को कम किया जा सकता है ताकि प्रमाणीकरण की जाँच के बाद xzy.com/myDoc?auth=8502375 और सादे url पर एक स्वचालित रीडायरेक्ट किया जा सके। - लेकिन यह सभी संभावित समस्याओं को हल नहीं करता है

— फाल्को

3

TL; DR - गुप्त URL जैसी कोई चीज नहीं है। एक वर्तमान हमला है जो यूआरएल को हॉटस्पॉट में एक दुर्भावनापूर्ण अभिनेता को उजागर करता है, भले ही आप सामान्य रूप से एचटीटीपीएस से अधिक URL भेजते हों। हमला वेब प्रॉक्सी ऑटोडिस्कवरी (WPAD) का दुरुपयोग करता है, जिससे आपका ब्राउज़र हमलावर को आपके सभी URL भेजने के लिए मजबूर करता है। देखें (उदाहरण के लिए) arstechnica.com/security/2016/07/…

— हेराल्ड

5

@ जेसीबीएसबी ने उन कुछ जोखिमों की पहचान नहीं की है, जिन्हें आपने निजी हिस्से को यूआरएल के टुकड़े वाले हिस्से में डाल दिया है (यानी "#" के बाद, जैसे स्टैक एक्सचेंज अपने ऑथेंट प्रमाणीकरण प्रतिक्रियाओं के लिए करता है)? उदाहरण के लिए, संदर्भित शीर्षलेख को टुकड़े को शामिल करने की अनुमति नहीं है ।

— जेसन सी

48

ध्यान दें:

बहुत से लोग प्रमाणीकरण के साथ "निजी" URL को भ्रमित करते दिखते हैं। इसके अलावा, कुछ भ्रम प्रतीत होता है कि किसी विश्वसनीय इकाई के माध्यम से लिंक भेजना दो-कारक प्रमाणीकरण पर एक प्रयास है। स्पष्ट होने के लिए, हम एक सार्वजनिक रूप से सुलभ संसाधन के बारे में बात कर रहे हैं, भले ही यह अनुमान लगाने के लिए पर्याप्त रूप से कठिन हो।

निजी URL का उपयोग करते समय, आपको हमेशा यह मान लेना चाहिए कि यह समझौता किया जा सकता है - आपको ऐसा URL डिज़ाइन करना चाहिए ताकि यदि वह समझौता किया जाए, तो भी संसाधन हमलावर को जानकारी लीक नहीं करेगा।

URL का अनुमान लगाने में निजी / कठिन पासवर्ड-आधारित प्रमाणीकरण के बराबर नहीं हैं। स्वभाव से, निजी URL बिल्कुल भी निजी नहीं हैं - वे सार्वजनिक रूप से सुलभ संसाधन हैं। मुझे लगता है कि "निजी" URL एक मिथ्या नाम है, बल्कि वे "अस्पष्ट" URL हैं।

ऐसे कुछ मामले हैं जहां "निजी" URL का उपयोग करना स्वीकार्य है, लेकिन वे पारंपरिक प्रमाणीकरण विधियों जैसे पासवर्ड प्रमाणीकरण या कुंजी-आधारित प्रमाणीकरण से स्वाभाविक रूप से कम सुरक्षित हैं।

जिन जगहों पर मैंने आमतौर पर "निजी" URL का उपयोग किया है, वे हैं:

पासवर्ड रीसेट ईमेल
सर्टिफिकेट जनरेशन ईमेल
खाता / ईमेल पुष्टिकरण ईमेल
खरीदी गई सामग्री (ebooks, आदि) का वितरण
फ्लाइट चेक-इन, प्रिंट बोर्डिंग पास जैसी अन्य गलत चीजें, पारंपरिक प्रमाणीकरण के अलावा निजी URL का उपयोग करती हैं

यहां समानता यह है कि यादृच्छिक URL आमतौर पर केवल एक-शॉट ऑपरेशन के लिए अच्छे होते हैं। इसके अलावा, पारंपरिक प्रमाणीकरण और यादृच्छिक URL परस्पर अनन्य नहीं हैं - वास्तव में, संसाधन का वितरण करते समय अतिरिक्त सुरक्षा प्रदान करने के लिए उन्हें एक दूसरे के साथ संयोजन में उपयोग किया जा सकता है।

जैसा कि रॉबर्ट हार्वे ने इंगित किया है, एक यादृच्छिक / निजी URL का सुरक्षित रूप से उपयोग करने का एकमात्र तरीका पृष्ठ को गतिशील रूप से उत्पन्न करना और उपयोगकर्ता को URL इस तरह से प्रस्तुत करना है कि उपयोगकर्ता को अर्ध-प्रामाणिक माना जा सके। यह ईमेल, एसएमएस आदि हो सकता है।

बेतरतीब ढंग से उत्पन्न / निजी URL में आमतौर पर कुछ गुण होते हैं:

यह उचित समय के बाद समाप्त हो जाना चाहिए
यह एकल-उपयोग वाला URL होना चाहिए: IE इसे पहली बार एक्सेस करने के बाद समाप्त हो जाना चाहिए।
यह उपयोगकर्ता के प्रमाणीकरण को किसी अन्य इकाई के लिए स्थगित कर देना चाहिए जो उपयोगकर्ता को सुरक्षित रूप से प्रमाणित करने के लिए भरोसा करता है। (ईमेल या एसएमएस आदि के माध्यम से लिंक भेजकर)
आधुनिक कंप्यूटर के लिए समय सीमा से पहले समय सीमा समाप्ति में URL को बाध्य करना असंभव होना चाहिए - या तो संसाधन को उजागर करने वाले एपीआई को सीमित करके या पर्याप्त एंट्रोपी के साथ एक url समापन बिंदु बनाकर ऐसा अनुमान नहीं लगाया जा सकता है।
यह उपयोगकर्ता के बारे में जानकारी को लीक नहीं करना चाहिए। IE: यदि पृष्ठ को पासवर्ड रीसेट करना है: पृष्ठ को अनुरोधकर्ताओं की खाता जानकारी प्रदर्शित नहीं करनी चाहिए। यदि ऐलिस पासवर्ड रीसेट लिंक का अनुरोध करता है और बॉब किसी तरह यूआरएल का अनुमान लगाता है, तो बॉब को यह जानने का कोई तरीका नहीं होना चाहिए कि वह किसके पासवर्ड को रीसेट कर रहा है।
यदि यह उपयोगकर्ता के बारे में जानकारी को लीक करता है, तो इसका उपयोग पारंपरिक प्रमाणीकरण के शीर्ष पर किया जाना चाहिए, उदाहरण के लिए एक पृष्ठ किसी उपयोगकर्ता को प्रमाणित कर सकता है कि क्या उनके पास कुकी सेट है या यदि उनका सत्र_ मान्य है।

विभिन्न संसाधनों को सुरक्षा के विभिन्न स्तरों की आवश्यकता होती है। यदि आप कुछ दोस्तों के साथ एक गुप्त नुस्खा साझा करना चाहते हैं, उदाहरण के लिए, इसे साझा करने के लिए एक यादृच्छिक / निजी URL का उपयोग करना स्वीकार्य होगा। हालाँकि, यदि संसाधन का उपयोग किसी की पहचान को चुराने या अन्य सेवा प्रदाताओं के साथ अपने खातों से समझौता करने के लिए किया जा सकता है, तो आप संभवतः उस संसाधन तक पहुंच को सीमित करने के बारे में अधिक ध्यान रखेंगे।

— चार्ल्स एडिस
स्रोत

4

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

— एक सीवीएन

7

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

— चार्ल्स अदीस

9

@CharlesAddis स्पष्ट रूप से आपने मेरी दादी कुकीज़ को कभी नहीं चखा है!

— ब्रायन

1

मुझे लगता है, हालांकि मैं गलत हो सकता हूं, कि @ माइकल आपके गुणों का एक गुप्त URL के 5-सूत्रीय वर्णन कह रहा है, पहले से ही दोस्तों के साथ एक गुप्त नुस्खा साझा करने के लिए ओवरकिल है। प्रत्येक एक एकल-उपयोग करना (और इसलिए विशेष रूप से नुस्खा तक पहुंचने वाले प्रति मित्र को एक अलग URL की आवश्यकता होती है) विशेष रूप से नगण्य लाभ के लिए बहुत परेशानी लगती है, खासकर अगर एक समाप्ति समय भी है । मैंने आपके उत्तर को पढ़ने के लिए कहा, "यह निजी URL का उपयोग करने के लिए स्वीकार्य है, लेकिन निजी URL में ये 5 गुण होने चाहिए", और IMO थोड़ा गलत है।

— स्टीव जेसोप

1

@BenjaminHodgson जो आइटम # 5 => के लिए ठीक कारण है, यदि लिंक / URL गलत हाथों में समाप्त होता है, तो इसे अनुरोध करने वाले उपयोगकर्ता के बारे में कोई जानकारी लीक नहीं करनी चाहिए।

— चार्ल्स अदीस

8

बहुत सारी प्रमाणीकरण योजनाएं यह साबित करने के लिए उबालती हैं कि आप एक रहस्य जानते हैं। आप किसी गुप्त पासवर्ड, या गुप्त URL या ... को साबित करके किसी सेवा में स्वयं को प्रमाणित करते हैं ...

कुछ और उन्नत प्रोटोकॉल (जैसे, OAUTH, कर्बरोस, ...) आपको यह साबित करने में सक्षम करते हैं कि आप वास्तव में रहस्य को प्रसारित किए बिना रहस्य को जानते हैं । यह महत्वपूर्ण है क्योंकि इसे अनुमान लगाने के अलावा "अजेय" रहस्य प्राप्त करने के और भी तरीके हैं।

जब आप अपने "असंदिग्ध" URL में टाइप करते हैं, तो मैं अपने आप को उसी इंटरनेट कैफे में बैठा सकता हूं, जो आपके वाईफाई कनेक्शन पर निर्भर करता है। उस समय, यदि आप एसएसएल का उपयोग नहीं कर रहे थे, या यदि मैं आपके एसएसएल कार्यान्वयन में नवीनतम नई बग का फायदा उठा सकता हूं, तो मुझे इसका रहस्य भी पता चल जाएगा।

— सोलोमन स्लो
स्रोत

1

निष्पक्ष होने के लिए, यह प्रमाणीकरण या किसी संचार के लिए भी सही है ।

— एंडी

किसी भी चीज़ पर "आपके वाईफाई कनेक्शन पर काम कर रहा है": यूआरएल, सीएसआरएफ संरक्षित <form>एस, जावास्क्रिप्ट सैन्य ग्रेड एन्क्रिप्टेड डेटा (शायद सक्रिय सूँघने की आवश्यकता होगी)। इसे ठीक करना सरल है: HTTPS का उपयोग करें।

— गुस्तावो रोड्रिग्स

@GustavoRodrigues सबसे पहले, अगर वास्तव में " कुछ भी काम " किया जाता है, तो यह HTTPS पर काम करेगा। अन्यथा, "कुछ भी" का क्या अर्थ है? या, आपको क्या लगता है कि HTTPS में कौन सा जादू है जो इसे बाकी सब चीजों से ऊपर रखता है?

— सोलोमन स्लो

2

... लेकिन वहाँ है जादू है कि छुपकर जानकारी बंद वार्ड: यह सार्वजनिक कुंजी क्रिप्टोग्राफी है। यहाँ एक सरल उदाहरण है: एक सेवा मुझे एक यादृच्छिक संख्या और टाइमस्टैम्प युक्त एक चुनौती भेजती है । मैं अपनी निजी कुंजी के साथ चुनौती पर हस्ताक्षर करता हूं और इसे वापस करता हूं। यदि वे मेरी पंजीकृत सार्वजनिक कुंजी के साथ मेरी प्रतिक्रिया को मान्य कर सकते हैं, तो यह साबित करता है कि मुझे रहस्य पता है (रहस्य मेरी निजी कुंजी है), लेकिन मैंने इसे बिना संभावित ईवेसड्रोपर को प्रकट किए बिना साबित कर दिया। यह मेरी प्रतिक्रिया को दोहराने के लिए बाज के मालिक की मदद नहीं करेगा, क्योंकि सेवा कभी भी एक ही चुनौती को दो बार नहीं भेजेगी।

— सोलोमन स्लो

HTTPS (अर्थात, SSL पर HTTP) सार्वजनिक-कुंजी क्रिप्टो का उपयोग करता है, लेकिन FYI करें, SSL के सबसे लोकप्रिय कार्यान्वयन में बग्स का इतिहास है जिसने क्रिप्टोग्राफी के बावजूद भी ईवेर्सड्रॉपर को तोड़ने की अनुमति दी है। नए कीड़े (उर्फ, "कारनामे") की खोज हर साल दो या तीन बार की जाती है, और एसएसएल का उपयोग करने वाले सभी उत्पादों के सभी डेवलपर्स को अपने बालों के साथ आग के चारों ओर भागना पड़ता है जब तक कि नवीनतम शोषण पैच नहीं हो जाता। (मुझे नहीं पता कि मैं कैसे जानता हूं!)

— सोलोमन स्लो

3

इस थ्रेड में पहले से ही बहुत सारे अच्छे उत्तर, लेकिन सीधे सवाल का जवाब देने के लिए:

इस संसाधन का उपयोग करने के इच्छुक एक ईविलवेअर के दृष्टिकोण से, क्या ये दृष्टिकोण समतुल्य हैं? यदि नहीं, तो क्या उन्हें अलग बनाता है?

मुझे एक परिभाषा स्थापित करने दो। "प्रमाणीकरण" पहचान का दावा साबित करने के लिए प्रमाणिकता प्रदान करता है। अभिगम नियंत्रण आमतौर पर उपयोगकर्ता की पहचान पर आधारित होता है।

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

दूसरी ओर, एक पासवर्ड एक अद्वितीय उपयोगकर्ता खाते से जुड़ा हुआ है। आपके पास इसे रीसेट करने की क्षमता है, या केवल इसे उपयोगकर्ता के घर के स्थान, या ज्ञात आईपी पते, या किसी भी अन्य नियंत्रण के किसी भी नंबर का उपयोग करने की अनुमति देता है।

एक उपयोगकर्ता नाम / पासवर्ड आपको पहुँच का बहुत अधिक नियंत्रण प्रदान करता है।

अभिगम नियंत्रण एक संसाधन (वस्तु) के लिए एक पहचान (विषय) का उपयोग करने की अनुमति देता है। आपके यूआरएल उदाहरण में पहचान "किसी को भी, जो किसी भी माध्यम से URL प्राप्त करता है।"

यदि आप कर सकते हैं तो उपयोगकर्ता नाम / पासवर्ड के साथ जाएं। समय के साथ सभी तरह के अप्रत्याशित तरीके से यूआरएल लीक हो जाते हैं।

— JesseM
स्रोत

1

एक गुप्त URL एक गुप्त पासवर्ड की तरह ही सुरक्षित है। हालाँकि, पासवर्ड URL की तुलना में गुप्त रखना आसान होता है, क्योंकि सभी और उनके कार्यक्रमों को पता होता है कि पासवर्ड गुप्त रहना चाहिए।

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

इसी तरह, HTTP प्रॉक्सी आमतौर पर पासवर्ड लॉग नहीं करेंगे, जबकि आमतौर पर URL लॉग होते हैं।

प्रमाणीकरण के लिए URL का उपयोग करने का अर्थ यह भी है कि URL साझा करना प्रमाणीकरण को साझा करता है, जिससे व्यक्तिगत रूप से (या रिकॉर्ड) पहुंच को रद्द करना मुश्किल हो जाता है।

और निश्चित रूप से, गुप्त URL गुप्त पासवर्ड की सभी कमजोरियों को प्राप्त करते हैं। विशेष रूप से, प्रमाणीकरण के लिए पासवर्ड का उपयोग करने से उस पासवर्ड को सर्वर और आपके संचार को पढ़ने में सक्षम किसी को भी पता चल जाएगा।

— Meriton
स्रोत

3

यह उत्तर बहुत सी धारणाएँ बनाता है जो गलत हैं। यदि आप HTTPS वाली किसी साइट पर लॉग इन करते हैं, और अपने उपयोगकर्ता नाम और पासवर्ड में टाइप करते हैं, तो बीच में और समीप के हॉप्स आपके पासवर्ड को नहीं जान पाएंगे।

— पीटेर बी

"आपके संचार को रोकना" से मेरा मतलब इसकी सामग्री को फिर से संगठित करने की क्षमता से था। यह HTTPS द्वारा रोका नहीं जा सकता है या नहीं। विशेष रूप से, एक एकल खराब प्रमाण पत्र पर भरोसा करना (उदाहरण के लिए कुछ कॉर्पोरेट HTTPS प्रॉक्सी जो सभी स्थापनाओं के लिए एक ही निजी कुंजी का उपयोग करता है) एक हमलावर को HTTPS ट्रैफ़िक को मैन-इन-द-बीच करने की अनुमति देता है।

— मेरिटॉन

2

लेकिन url में गुप्त एन्कोडिंग द्वारा आप मूल रूप से HTTPS को पूरी तरह से अनुपयोगी बनाते हैं। क्लाइंट और सर्वर के बीच प्रत्येक हॉप में गुप्तता है। किसी भी तरह के समझौता प्रमाणपत्र की आवश्यकता नहीं है।

— पीटर बी

4

बकवास; HTTPS में, URL केवल एन्क्रिप्टेड स्ट्रीम में प्रसारित किया जाता है। आप इसे डोमेन या आईपी के साथ भ्रमित कर रहे होंगे, जो क्रमशः DNS लुकअप और आईपी हेडर फ़ील्ड में दिखाई देते हैं।

— मैरिटन

1

एक और आइटम जो कहीं भी नोट नहीं किया गया है, वह 'अनुमान' का थ्रॉटलिंग है। अधिकांश पासवर्ड प्रमाणीकरण प्रणालियों के लिए, आपको एक उपयोगकर्ता के लिए पासवर्ड का अनुमान लगाने पर सीमित संख्या में प्रयास करने से पहले आगे प्रमाणीकरण प्रयासों को या तो बंद कर दिया जाता है, या सीमित किया जाता है।

जब आप अपनी URL योजना के विरुद्ध 'अनुमान' के साथ कुछ ऐसा कर सकते हैं, तो इसे लागू करना कुछ कठिन होगा। यदि आपकी URL पीढ़ी के लिए एक पहचानने योग्य पैटर्न है, तो आपके 'यादृच्छिक' URL स्थान के माध्यम से अपने तरीके से काम करने के लिए किसी को सेट करना मुश्किल हो सकता है।

— धान
स्रोत

0

एक और पहलू है जिसका मैंने अभी तक उल्लेख नहीं किया है - URL शॉर्टर्स।

हाल ही के एक प्रकाशन (अप्रैल 2016) में, यह दावा किया गया था कि URL शॉर्टनर सेवाएं यादृच्छिक उत्पन्न "अचूक" URL द्वारा प्रदान की गई सुरक्षा को पूरी तरह से कम कर देती हैं। Shorterner सेवा का URL स्थान आपके यादृच्छिक रूप से उत्पन्न URL की तुलना में काफी छोटा है - जिसका अर्थ है कि शॉर्टनर सेवा के साथ साझा किए गए ऐसे किसी भी "सुरक्षित" URL का अनुमान लगाने की तुलना में आसान तरीके से अनुमान लगाया जा सकता है।

उदाहरण के लिए - मान लें कि आपका रैंडम URL 128bit लंबा है (यानी एक गाइड)। इसके अलावा, मान लें कि आपका यादृच्छिक संख्या जनरेटर वास्तव में मजबूत है और आप एक समान तरीके से उन बिट्स को उत्पन्न करते हैं। 128bit संख्या का अनुमान लगाना बहुत कठिन है और इसमें काफी समय लग सकता है - आपका URL प्रभावी रूप से 128bit कुंजी संरक्षित है।

फिर, मान लें कि किसी ने इस URL को Google URL शॉर्टनर पर साझा किया है। आज वह सेवा अक्षरों और संख्याओं से बनी एक 10 वर्ण लंबी आईडी का उत्सर्जन करती है। (26 + 10) ^ 10 ~ = 3.6 * 10 ^ 15 <2 ^ 52 - इसलिए हमने प्रभावी रूप से 128 बिट से 52 बिट तक प्रमुख ताकत को आधा कर दिया है।

इस तथ्य को जोड़ें कि जनरेटर अन्य विचार के कारण पूरे स्थान का उपयोग नहीं करते हैं और आप एक प्रभावी हमले को माउंट कर सकते हैं जो पक्ष चैनलों (सबसे अधिक संभावना पूर्व-आवंटित यादृच्छिक URL बफ़र्स) के साथ जानवर बल को जोड़ती है।

मूल लेख: http://arxiv.org/pdf/1604.02734v1.pdf
लेख (लेखक द्वारा) को सारांशित करते हुए एक ब्लॉग पोस्ट: https://freedom-to-tinker.com/blog/vitaly.gone-in-in छह वर्ण-शॉर्ट यूआरएल-माना-हानिकारक के लिए क्लाउड-सेवाओं /

— रान बिरनो
स्रोत

2

ठीक है, हाँ, लेकिन किसी को उम्मीद होगी कि संवेदनशील डेटा के लिए ऐसी सेवाओं का उपयोग करने वाले किसी भी यूआरएल को पोस्ट करने से बेहतर जानेंगे , जिसमें एक छोटी सेवा भी शामिल है। यह वास्तव में यह कहने से अलग नहीं है कि

Gah! My password/private key is too long and complex. I know! I'll just write it in a text document and put that in a zip file with an easier password.

दोनों पारदर्शी विफल हैं, जो कि आशा के विरुद्ध एक आशा है कि लोग मूर्खतापूर्ण पर्याप्त नहीं होंगे। लेकिन हाँ, वास्तव में, दुख की बात है कि आपकी चेतावनी शायद ज़रूरी है;)

— अंडरस्कोर_ड

@underscore_d हाँ बिल्कुल - यदि आप इस विषय को टिप्पणी करने के लिए पर्याप्त रूप से जानते हैं तो यह ब्लॉग-योग्य बिंदु नहीं है।

— रॉबर्ट ग्रांट