2009-09-01 17 views
6

प्रदर्शन केवल एकमात्र मुद्दा है? किसी उपयोगकर्ता के सत्र में https कनेक्शन का उपयोग नहीं किया जा सकता है? स्पष्ट रूप से कम पुनर्निर्देशन हो रहा है!https केवल लॉगिन के लिए क्यों उपयोग किया जाता है?

मैं पर http vs. https performance

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

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

+5

आपको यह कहां मिला कि https केवल * लॉगिन के लिए उपयोग किया गया है? – romaintaz

उत्तर

5

प्रदर्शन एकमात्र मुद्दा नहीं है। यदि आप HTTPS का उपयोग करने जा रहे हैं, तो आपको वास्तव में यह जांचना होगा कि आपकी सभी सामग्री, तृतीय पक्ष छवियों और पुस्तकालयों सहित, HTTPS के माध्यम से उपलब्ध है। अन्यथा, आप IE पर कष्टप्रद मिश्रित सामग्री संदेशों उत्पन्न करेगा:

http://blog.httpwatch.com/2009/04/23/fixing-the-ie-8-warning-do-you-want-to-view-only-the-webpage-content-that-was-delivered-securely/

यह भी मतलब है कि आप प्रत्येक होस्ट नाम है कि आप का उपयोग (जैसे images.example.com) या किसी प्रकार के लिए अलग से SSL प्रमाणपत्र की आवश्यकता होगी वाइल्ड कार्ड एसएसएल प्रमाणपत्र (जैसे * .example.com के लिए)।

एक सावधानी से कॉन्फ़िगर किया गया साइट केवल एक मामूली सीपीयू क्लाइंट और सर्वर का उपयोग कर HTTPS पर मारा भुगतना चाहिए:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

-2

क्योंकि लॉगिन और पासवर्ड हैं सबसे संवेदनशील डेटा जिसे संरक्षित करने की आवश्यकता है।

शेष एन्क्रिप्टेड नहीं होने पर निश्चित रूप से स्नीफ किया जा सकता है, लेकिन यह केवल "रीड-मोड" में होगा, हैकर कुछ भी संशोधित करने में सक्षम नहीं होगा। हालांकि लॉगिन/पासवर्ड प्राप्त करके वह करेंगे।

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

+1

-1 मुझे संदर्भ पसंद नहीं है कि यह सबसे संवेदनशील डेटा है। मेरी राय में, क्रेडिट कार्ड जानकारी आदि अधिक संवेदनशील –

3

https लॉगिन से कहीं अधिक के लिए उपयोग किया जाता है। जब भी मैं अपने ऑनलाइन बैंक में लॉग इन करता हूं, या शॉपिंग कार्ट तर्क करता हूं, या ऑनलाइन क्रेडिट कार्ड देता हूं, तो मुझे लगता है कि https प्रोटोकॉल है। यह बेहतर होगा, या मैं ऐप का उपयोग नहीं करूंगा।

+0

+1 हैं। हालांकि "इस्तेमाल किया जा सकता है" में "इस्तेमाल किया जा सकता है" बदल जाएगा। – RichardOD

+0

मैंने इसे "प्रयोग किया जाता है" के रूप में लिखा क्योंकि मैंने जांच के लिए अपने बैंकिंग ऐप में लॉग इन किया था, और यह वास्तव में मेरे सत्र में प्रत्येक पृष्ठ के लिए लागू था। मैं यही देखना चाहता था। वर्तमान काल, और जो जोर दिया गया है, इस मामले में मेरे लिए उपयुक्त लग रहा था। मैं ओपी के विचार से मुकाबला करना चाहता था कि https लॉगिन के लिए "केवल" अच्छा है। मैं बैंकिंग और ऐसे वैकल्पिक के लिए https पर विचार नहीं करता हूं। – duffymo

+0

बैंक एप्लिकेशन आपके सत्र में https througout का उपयोग करेंगे, क्योंकि यह महत्वपूर्ण है कि जो कुछ भी होता है उसे सुरक्षित तरीके से संभाला जाता है। – awe

6

एक HTTPS कनेक्शन कहीं भी उपयोग किया जा सकता है। यह सिर्फ एसएसएल (टीएलएस) का उपयोग कर सभी डेटा प्रसारित करता है, जो सार्वजनिक/निजी और सममित एन्क्रिप्शन का एक रूप है। यह सर्वर से भेजे गए डेटा को डिक्रिप्ट करना बहुत कठिन बनाता है।

डेटा एन्क्रिप्ट करने और डिक्रिप्ट करने की लागत के कारण, (कुछ मामलों में) का उपयोग नहीं किया जाता है जहां संवेदनशील डेटा प्रसारित नहीं होता है। इसका उपयोग न करने से सर्वर लोड कम हो जाता है। संवेदनशील डेटा को प्रसारित करने की आवश्यकता होने पर इसका हमेशा उपयोग किया जाना चाहिए। यदि आप क्रेडिट कार्ड डेटा दर्ज कर रहे हैं (उदाहरण के लिए), तो आपको यह जांचना चाहिए कि प्रोटोकॉल http के बजाय https है।

+0

+1। सबमिट यूआरएल के साथ केवल HTTPS का उपयोग करने के साथ नए सुरक्षा मुद्दे हैं, हालांकि - देखें http://www.grc.com/sn/sn-217.htm – TrueWill

1

बस शब्दों में कहें, आप सुरक्षित जानकारी भेजने के लिए HTTPS का उपयोग करते हैं। इस प्रकार, क्रेडिट कार्ड की जानकारी और पासवर्ड उन्हें बचाने के लिए HTTPS का उपयोग करेंगे। कैदियों को काउंटी जेल से राज्य जेल में लाने के लिए इस्तेमाल की जाने वाली एक बख्तरबंद कार की तुलना करें। लेकिन एक बार यह जानकारी सही स्थान पर हो जाने पर, किसी भी आगे के जोखिम के बिना जानकारी को संदर्भित करने के लिए एक साधारण टोकन का उपयोग किया जा सकता है। जब आप लॉगऑन करते हैं, तो सुरक्षित कनेक्शन सत्र आईडी उत्पन्न करेगा जो 10, 20 मिनट पहले समाप्त होने से पहले मान्य होगा। हालांकि कोई जोखिम है कि कोई इस सत्र आईडी को कैप्चर करेगा, फिर भी आपकी जानकारी पूरी तरह से लेने के लिए पर्याप्त जानकारी नहीं है। उस आईडी का दुरुपयोग करने के लिए हैकर के पास सिर्फ एक छोटी सी खिड़की होगी। इस प्रकार, पासवर्ड के मुकाबले सत्रों के साथ कम जोखिम है। क्रेडिट कार्ड की जानकारी के साथ ही। एक बार साइट आपके क्रेडिट कार्ड नंबरों को जानता है, तो यह सिर्फ आपको पूछ सकता है कि क्या आप कार्ड 1, कार्ड 2 या किसी अन्य का उपयोग करना चाहते हैं। यह सिर्फ प्रत्येक कार्ड को एक आईडी निर्दिष्ट करता है, जो आम तौर पर आपके पास कार्ड की संख्या से 1 तक की संख्या है। अगर कोई इसे पढ़ता है, तो वे जानते हैं कि आप कार्ड 1 के साथ $ 49.95 का भुगतान कर रहे हैं। हालांकि, वे अभी भी इस कार्ड के बारे में और कुछ नहीं जानते हैं।

जिन चीज़ों को सुरक्षित करने की आवश्यकता है, वे बख्तरबंद कार या HTTPS के साथ भेज रहे हैं। कुछ और सिर्फ किसी अन्य प्रकार के परिवहन का उपयोग कर सकता है।

3

"लॉगिन और पासवर्ड सबसे संवेदनशील डेटा है कि जरूरत संरक्षित किया जा रहे हैं क्योंकि। बाकी को स्नीफ किया जा सकता है ..., लेकिन यह 'रीड-मोड' में केवल होगा, हैकर कुछ भी संशोधित करने में सक्षम नहीं होगा। "

यह मेरे लिए गलत लगता है।

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

संबंधित मुद्दे