क्या अधिकांश वेबसाइटों के लिए SSL वास्तव में मायने रखता है?

Question

मैं इस साइट के लिए "सिक्योरिटी राइट" सीखने के बारे में बहुत अधिक पागल हो गया हूं जो मैं बना रहा हूं (पहली गैर-तुच्छ साइट मैंने बनाई है), और मैंने कुछ ऐसा देखा है जो मुझे परेशान करता है: एसएसएल।

मैंने यहां ढेर सारे सुरक्षा सूत्र पढ़े हैं, StackOverflow पर, और दूसरी जगहों पर जो n उपयोग के बाद सत्र आईडी को पुनर्जीवित करने के बारे में लंबाई पर चलता है, और कैसे आपके पासवर्ड को नमकीन, हैशेड और सादे पाठ में संग्रहीत नहीं किया जाना चाहिए। मैंने आईपी पते, उपयोगकर्ता एजेंटों को ट्रैक करके और ट्रैकिंग कुकीज़ का उपयोग करके, सत्र के अपहरण का पता लगाने के तरीके के बारे में बहुत कुछ पढ़ा है।

मुझे समझ में नहीं आ रहा है कि वेबसाइट के सामान्य HTTP POST के माध्यम से वेबसाइट के लॉग इन करने और सादे पाठ में वायर पर अपना पासवर्ड भेजने के बाद यह क्या है?

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

• एसएसएल के साथ परेशान नहीं करना कब ठीक है?

जीमेल, आपका बैंक और लिंक्डइन जैसी साइटें, मैं एसएसएल का उपयोग करने के लिए एक कारण देख सकता हूं, लेकिन यह ठीक है कि फेसबुक और रेडिट जैसी साइटें परेशान नहीं करती हैं (नरक, प्लेंटीऑफिश आपके पासवर्ड को सादे पाठ में संग्रहीत करता है और यहां तक ​​कि ईमेल भी करता है। आपको अनुस्मारक के रूप में साप्ताहिक रूप से? (!)

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

Answer 1

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

यदि आपके पास चोरी करने लायक कुछ भी नहीं है, तो यह न सोचें कि एसएसएल सुरक्षा को बहुत बढ़ाएगा या बिल्कुल भी नहीं, या आपके उपयोगकर्ता इसे एक उपयोगी सुविधा के रूप में नहीं देखेंगे, फिर आप एसएसएल का उपयोग नहीं करने पर विचार कर सकते हैं।

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

Comments

+1 "कई बड़ी साइटों को सर्वोत्तम प्रथाओं का पालन करना आवश्यक नहीं है" - मुझे यकीन है कि नाइजीरियाई 419'ers ने चुराई गई डेटिंग साइट प्रोफाइल को विमुद्रीकृत करने का एक तरीका

— खोजा है

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

— AgentConundrum

@danlefree, यह आसान है। उपयोगकर्ता ईमेल और बैंकिंग साइट के पासवर्ड रिकवरी प्रश्नों का उत्तर देने के लिए डेटिंग साइटों पर व्यक्तिगत विवरण का उपयोग करें। या बस पासवर्ड को कैप्चर करें, क्योंकि लोग अपने पासवर्ड का फिर से उपयोग करते हैं, बहुत दूर तक।

— ज़ॉडेचे सेप

@AgentConundrum Startssl मुफ्त में एसएसएल प्रमाणपत्र प्रदान करता है। यदि आप एक तंग बजट पर हैं, लेकिन एक स्थिर आईपी है, तो आप उसके लिए जा सकते हैं।

— राणा प्रताप

@AgentConundrum आपको SSL के लिए एक समर्पित IP की आवश्यकता नहीं है, जब तक कि आपका होस्ट SNI का समर्थन करता है (और यदि वे नहीं करते हैं, तो एक नया होस्ट ढूंढें क्योंकि वे नहीं जानते कि वे क्या कर रहे हैं)। आप मुफ्त में एक प्रमाण पत्र प्राप्त कर सकते हैं, इसलिए यह एक जोड़ा लागत भी नहीं है ...

— डॉकटोर जे

Answer 2

जॉन के जवाब के विपरीत दृष्टिकोण लेते हुए, मुझे लगता है कि आपको एसएसएल पर गंभीरता से विचार करना चाहिए यदि आप किसी भी व्यक्तिगत रूप से पहचाने जाने योग्य जानकारी को संभालते हैं - इसमें शामिल हैं: भौतिक पते, ई-मेल पते, वित्तीय जानकारी और संचार के साथ नाम जो उपयोगकर्ताओं को निजी तौर पर उम्मीद करेंगे ।

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

अपने आगंतुकों की जानकारी देखने से अनधिकृत तीसरे पक्ष को रोकें और अपने उपयोगकर्ताओं को इस बात से अवगत रखें कि आप अपने आगंतुकों के विश्वास को बनाए रखने के लिए उनकी जानकारी का उपयोग कैसे करते हैं।

यहां तक ​​कि फेसबुक भी ऐसा करता है, जहां तक ​​मैं बता सकता हूं।

<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit=";var d=document.documentElement;if (d.onsubmit) { return d.onsubmit(event); }else { return Event.fire(d, &quot;submit&quot;, event); }">

(Facebook.com लॉगिन HTML स्रोत)

Comments

अजीब। मुझे नहीं पता कि मैंने फेसबुक के लिए यह कैसे नोटिस किया। मैं इसे HTTPFox से देख रहा था और किसी तरह शुरुआती अनुरोध पर 's' से चूक गया। मैं उसे हटाने के लिए संपादित करूँगा। यह तथ्य अभी भी बना हुआ है कि बहुत सी साइटें ऐसा करती हैं (reddit, hacker news, TDWTF, आदि), इसलिए सबसे खराब स्थिति में मैं उनसे बेहतर नहीं हो सकता। बजट मेरे लिए एक बड़ी चिंता का विषय है, इसलिए एक स्थिर आईपी ($ 8 / मो होस्ट पर) के लिए एक अतिरिक्त $ 5 / मो खर्च करने के साथ-साथ एक सभ्य प्रमाण पत्र भी खरीद रहा हूं .. मैं लगभग सिर्फ लानत का निर्माण नहीं करने पर विचार करूंगा साइट।

— AgentConundrum

@AgentConundrum - सख्ती से बोलना, यदि पासवर्ड नमकीन है, तो HTTP पर वन-वे हैशिंग एल्गोरिथ्म के माध्यम से एक पासवर्ड पास करना ठीक है , इसलिए मैं उन साइटों पर MD5 हैश कार्यान्वयन देखकर बहुत आश्चर्यचकित नहीं होऊंगा, जो कि उपयोगी नहीं हैं एसएसएल: pajhome.org.uk/crypt/md5

— danlefree

और कैसे ग्राहक पक्ष पर एक हैश बनाने से कुछ भी मदद मिलेगी? उस स्थिति में, मूल रूप से हैश पासवर्ड है । मैं हैश को कैप्चर करने में सक्षम होना चाहिए और इसे आसानी से फिर से खेलना चाहिए क्योंकि मैं एक पासवर्ड कैप्चर कर सकता हूं।

— ज़ॉडेचेस

@Zoredache यही कारण है कि हैश नमकीन होना चाहिए । यहां बताया गया है कि यह कैसे काम करता है: मैं आपको पूर्व-आबाद टोकन के साथ लॉगिन पृष्ठ भेजता हूं जिसमें microtime()सर्वर से कॉल शामिल है । आपका प्रेषित हैश आपके पासवर्ड का संयोजन है + microtime()और, एक बार जब मुझे आपका हैश प्राप्त होता है, तो मैं microtime()+ पासवर्ड चुनौती / प्रतिक्रिया जोड़ी को अमान्य करता हूं (इसे फिर से उपयोग नहीं किया जा सकता)।

— डेनलेफ्री

Answer 3

अगस्त 2014 तक Google ने आधिकारिक तौर पर संकेत दिया है कि HTTPS का उपयोग रैंकिंग संकेत के रूप में किया जाएगा।

इसका मतलब यह है कि भले ही आपकी वेबसाइट पूरी तरह से स्थिर वेबसाइट है, अगर आप एसईओ के बारे में परवाह करते हैं तो आपको कम से कम एसएसएल प्रमाणपत्र स्थापित करने पर विचार करना चाहिए।

बेशक, HTTPS सैकड़ों में से सिर्फ एक रैंकिंग संकेत है, इसलिए संभवतः ऐसे और भी महत्वपूर्ण काम हैं जो आप SEO के लिए कर सकते हैं।

Comments

Google ने यह भी घोषणा की कि चूंकि SSL प्रमाणपत्र स्थापित करने में संसाधन लगते हैं, आपको केवल तभी करना होगा जब आपकी वेबसाइट इसकी मांग करेगी। संक्षेप में, उन्होंने उल्लेख किया कि आपकी रैंकिंग सिर्फ इसलिए प्रभावित नहीं होगी क्योंकि आपने अपने व्यक्तिगत ब्लॉग पर एसएसएल प्रमाणपत्र स्थापित नहीं किया था।

— राणा प्रताप

Answer 4

यहां वह कोण है जिस पर आपने विचार नहीं किया होगा: एसएसएल / टीएलएस का उपयोग नहीं करना आपके उपयोगकर्ताओं को निष्क्रिय निगरानी को उजागर कर सकता है, भले ही आपकी साइट में कोई लॉगिन न हो।

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

यह इस कारण से है कि मैं अपनी साइट पर HTTPS प्रदान करता हूं, जो केवल स्थैतिक सामग्री प्रदान करता है।