क्या पासवर्ड के बजाय यादृच्छिक URL का उपयोग करना ठीक है? [बन्द है]


12

क्या इस तरह से यादृच्छिक अक्षरों से निर्मित URL का उपयोग करना "सुरक्षित" माना जाता है?

http://example.com/EU3uc654/Photos

मैं एक वेबसर्वर पर कुछ फाइलें / चित्र दीर्घाएँ रखना चाहता हूं जो केवल उपयोगकर्ताओं के एक छोटे समूह द्वारा एक्सेस की जानी हैं। मेरी मुख्य चिंता यह है कि फाइलों को खोज-इंजन या जिज्ञासु शक्ति-उपयोगकर्ताओं द्वारा नहीं उठाया जाना चाहिए जो मेरी साइट के आसपास प्रहार करते हैं।

मैंने एक .htaccess फ़ाइल स्थापित की है, बस यह ध्यान देने के लिए कि http://user:pass@url/लिंक पर क्लिक करना कुछ ब्राउज़रों / ईमेल क्लाइंटों के साथ अच्छी तरह से काम नहीं करता है, संवादों और चेतावनी संदेशों को प्रेरित करता है जो मेरे गैर-कंप्यूटर-सेवी उपयोगकर्ताओं को भ्रमित करते हैं।


नहीं, आप इसका उपयोग कर सकते हैं, लेकिन केवल या मुख्य प्रमाणीकरण तंत्र के रूप में नहीं।
एंड्रयू स्मिथ

1
मैंने इसे कई बार एक प्रयोग के रूप में आज़माया है, और हर बार लिंक खोज इंजन में हवा देता है। मैं नहीं जानता कि कैसे, लेकिन मुझे पता है कि ऐसा होता है।
डेविड शवार्ट्ज

आप चेतावनियों को रोकने के लिए एसएसएल को कॉन्फ़िगर करना चाह सकते हैं, आप startsl.com से मुफ्त सेरेट प्राप्त कर सकते हैं और एसएसएल अब कम्प्यूटेशनल रूप से गहन (जब तक कि यह ठीक से कॉन्फ़िगर नहीं किया जाता है)।
ह्यूबर्ट करियो

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

जवाबों:


17

यह "ठीक" है या नहीं यह इस बात पर निर्भर करता है कि चित्र कितने संवेदनशील हैं।

यदि आप एसएसएल का उपयोग नहीं कर रहे हैं, तो यूआरएल, एचटीएमएल और छवियां स्वयं आपके उपयोगकर्ता के कंप्यूटरों पर कैश की जाएंगी। यह लीक हो सकता है लेकिन मैं इस पर विचार नहीं करूंगा।

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

HTTP प्रमाणीकरण या POST चर जैसे उचित प्रमाणीकरण को इस तरह से अस्वीकार्य नहीं किया जाना चाहिए या किसी भी मूल वेबसाइट पर वापस रिपोर्ट किया जाना चाहिए।

एक अन्य तकनीक अद्वितीय और अल्पकालिक URL का उपयोग करना है। इस तरह, भले ही वे रिसाव करते हों, इससे ज्यादा फर्क नहीं पड़ता। बेशक, आपको नए URL के अपने वैध उपयोगकर्ताओं को अपडेट करते रहना होगा।


ब्राउज़र टूलबार का उल्लेख करने के लिए +1।
ह्यूबर्ट करियो जूल 1'12

23

नहीं, वास्तव में, यह केवल अस्पष्टता के माध्यम से सुरक्षा है जो बिल्कुल भी सुरक्षा नहीं है। कुछ भी जो बिना किसी वास्तविक सुरक्षा के इंटरनेट से सीधे सुलभ है, अनुक्रमित और कैश्ड पाया जाएगा।


10
क्या सभी पासवर्ड केवल अस्पष्टता के माध्यम से सुरक्षा नहीं हैं?
विंस्टन इर्वर्ट

4
@WinstonEwert: पासवर्ड खुद अस्पष्टता के माध्यम से सुरक्षा से कोई लेना-देना नहीं है जो डिजाइन / कार्यान्वयन की गोपनीयता से संबंधित है। उदाहरण के लिए अपाचे बेसिक कोर के मामले में यह डिज़ाइन / कार्यान्वयन सभी को देखने के लिए पूरी तरह से खुला है।
user9517

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

1
Apache config में एक गलती (या डिफ़ॉल्ट कॉन्फ़िगरेशन पर वापस लौटना) और आपकी निर्देशिका आपके हाथ की हथेली पर सभी फ़ाइलों और निर्देशिकाओं के साथ अनुक्रमित दिखाती है, पासवर्ड के साथ इतना नहीं।
ह्यूबर्ट करियो जूल

4
आप कहते हैं कि अस्पष्टता के माध्यम से सुरक्षा "डिजाइन / कार्यान्वयन की गोपनीयता से संबंधित है"। लेकिन स्पष्ट रूप से, यादृच्छिक URLS डिज़ाइन / कार्यान्वयन की गोपनीयता से संबंधित नहीं हैं। इस प्रकार, यादृच्छिक यूआरएल, जो भी उनके दोष हैं, उन्हें अस्पष्टता के माध्यम से सुरक्षा के रूप में वर्गीकृत नहीं किया जा सकता है।
विंस्टन इर्वर्ट

6

वे रास्ते में हर प्रॉक्सी में लॉग इन होंगे। जब तक कोई व्यक्ति वास्तव में लिंक प्रकाशित नहीं करता है, तब तक आप उत्सुक बिजली उपयोगकर्ताओं और खोज इंजन से सुरक्षित रहेंगे।

और अपने जनरेटर की यादृच्छिकता के लिए बाहर देखो।

मैं अनुमान लगा रहा हूँ कि आप यहाँ अति-उच्च सुरक्षा की तलाश नहीं कर रहे हैं।


यदि कोई व्यक्ति URL प्रकाशित करेगा, तो कोई भी चीज़ उसे पासवर्ड प्रकाशित करने से रोक देगी। एक कारक के रूप में ज्ञान द्वारा प्रमाणीकरण हमेशा इस तरह "छल किया जा सकता है"।
मैनुएल फॉक्स

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

5

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

मैं सुझाव दूंगा कि आप एक साधारण .htaccess आधारित प्रमाणीकरण प्रणाली का उपयोग कर रहे हैं, या इसके अतिरिक्त, जो आप प्रस्तावित कर रहे हैं।


5

मैं एक और जोड़ना चाहूंगा, शायद इस उदाहरण की तरह मोटे यूआरएल पर अधिक डरावना परिप्रेक्ष्य। यहां तक ​​कि अगर आपका URL अकस्मात रूप से साझा नहीं किया गया है, तो इसे खोज इंजन में सबमिट किया जा सकता है:

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

YMMV।


ओह हां - या केवल एक ब्राउज़र प्लगइन द्वारा जो संबंधित साइटों के लिए दिखता है या उपयोगकर्ताओं को एक पृष्ठ के बारे में नोट्स साझा करने की अनुमति देता है
ब्रोंड गोंडवाना

2

अतीत में मैंने उपयोगकर्ताओं को दस्तावेज़ प्रबंधन प्रणाली पर साझा स्थान बनाने की अनुमति देने के लिए एक समान विधि का उपयोग किया था। साझा सामग्री शीर्ष गुप्त नहीं थी, इसलिए सिस्टम को अति सुरक्षित होने की आवश्यकता नहीं थी।

मैंने अभी हाल ही में प्रत्येक उपयोगकर्ता URL में एक समाप्ति टाइमस्टैम्प और उनके ईमेल का MD5 सम्‍मिलित किया है।

तो URL जैसा दिखता था:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

उपर्युक्त के साथ, यदि उपयोगकर्ता 30 जुलाई से पहले ईमेल user@gmail.com में प्रवेश कर जाता है तो वे जाना अच्छा होगा।

बिल्कुल मिलिट्री ग्रेड सिक्योरिटी नहीं, बल्कि नौकरी की।


0

यह वही भेद्यता साझा करता है जो URL में सेशनिंग को संग्रहीत करता है। कोई गलती से दूसरों को लिंक कॉपी-पेस्ट कर सकता है, इसे स्क्रीनशॉट में सेंसर करना भूल सकता है, या किसी को इसे देखने दे सकता है, क्योंकि यह पासवर्ड की तरह तारांकित नहीं है।

इसके अलावा, अगर कुछ सामग्री पासवर्ड से सुरक्षित है, तो आप लॉग इन करके जानते हैं कि यह एक रहस्य है। यदि आपको एक लिंक मिलता है, तो आप इसे आसानी से भूल सकते हैं।

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

मुझे लगता है कि यह बुरा नहीं है अगर ये सिर्फ छवियां हैं। लेकिन अगर ये कुछ छवियां हैं, तो आप वास्तव में साझा करना पसंद नहीं करेंगे;) तो मैं आपको लंबे समय तक यादृच्छिक शब्द का उपयोग करने का सुझाव देता हूं, जैसे कि एक प्रस्तुत ई।

EDIT: URL में जोड़ें? DO_NOT_SHARE_THIS_LINK: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos/d_N_N__AREARE_THIS_LINK

यही कारण है कि जब भी अन्य खेलों की मेजबानी की जाती है तो कॉंग्रेगेट करता है (यह फ्रेम के url में स्थिति प्रमाणिकता डालता है)। BTW, Kongregate प्रकाशित गेम के लिए अतिथि एक्सेस लिंक का उपयोग नहीं करता है, जिस तरह से आप उपयोग करना चाहते हैं।


वास्तव में यह बहुत खराब है तो सत्र आईडी, क्योंकि सत्र कुछ समय के बाद समाप्त हो जाते हैं। सत्र आईडी में लॉग इन करने वाले खोज इंजन आमतौर पर एक मृत लिंक प्रस्तुत करते हैं / परिणाम में सत्र में लॉग इन नहीं होते हैं। या, यदि सर्वर परवाह नहीं करता है, तो यह कई उपयोगकर्ताओं के सत्र को सिंक कर सकता है और जब उनमें से कोई एक लॉग इन करता है, तो वे सभी करते हैं। वैसे भी, URL :-) में स्थायी रूप से लॉग इन के रूप में बुरा नहीं है
korkman

बेशक यह बदतर है, और आप सत्र में आईपी को भी याद रख सकते हैं क्योंकि आपको यूआरएल में sessid प्राप्त करने के लिए पहले लॉगिन करने की आवश्यकता है, और फिर IP बदल जाने पर आप सत्र को नष्ट कर सकते हैं।
मार्कस वॉन ब्रॉडी जू
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.