हार्टलेड फिक्स होने के दौरान इंटरनेट का उपयोग कैसे करें?


119

कई वेबसाइटें हैं जो वर्तमान में असुरक्षित नहीं हैं, लेकिन मुझे कुछ पता नहीं है कि क्या वे कुछ दिन पहले असुरक्षित थीं

उदाहरण के लिए:

  • twitter.com: अभी कमजोर नहीं है, लेकिन प्रमाणपत्र बुध मार्च 05 00:00:00 यूटीसी 2014 से है
  • google.com: अभी कमजोर नहीं है, लेकिन प्रमाणपत्र बुध मार्च 12 09:53:40 यूटीसी 2014 से है
  • bankofamerica.com: अभी कमजोर नहीं है, लेकिन प्रमाणपत्र थू दिसंबर 05 00:00:00 यूटीसी 2013 से है

मैं क्या करूं? इनका उपयोग तब तक न करें जब तक कि वे फिर से न मिलें? मुझे कैसे पता चलेगा कि वे नए सिरे से प्रमाणपत्र को फिर से जारी करते हैं? ऐसा लगता है कि मुझे अपना पासवर्ड बदलने के लिए इन साइटों में भी प्रवेश नहीं करना चाहिए क्योंकि यह जानने का कोई तरीका नहीं है कि वे वास्तविक वेबसाइट हैं।


जवाबों:


201

अपडेट 2014-04-11

क्लाउडफेयर ने यह सत्यापित करने के लिए एक चुनौती की स्थापना की कि निजी कुंजी निष्कर्षण वास्तव में संभव था। यह लगभग 100 हजार अनुरोधों के साथ किया गया है, और यह आशंकाओं को सत्यापित करता है। यह अब सैद्धांतिक नहीं है, लेकिन सिद्ध है । इसके बारे में पढ़ने के लिए आप यहां जा सकते हैं ।

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


टीएल; डीआर अपने सिस्टम की स्थिति के बारे में संगठनों से घोषणाओं के लिए देखें, अपने सभी पासवर्ड बदलें , और बैंकिंग या अन्य वित्तीय प्रणालियों जैसे महत्वपूर्ण खातों पर धोखाधड़ी / संदिग्ध गतिविधि के लिए देखें।

यह समझने के लिए कि स्थिति इतनी खतरनाक क्यों है, हमें पहले यह समझना होगा कि यह हमला वास्तव में क्या करता है। CVE-2014-0160, AKA हार्टब्लेड, एक बफर ओवर्रेड बग है जो एक हमलावर को OpenSSL के कमजोर संस्करण को चलाने वाले सर्वर से 64 kB तक की मेमोरी प्राप्त करने की अनुमति देता है।

जो वाकई बहुत बुरा लगता है। यह व्यवहार में कैसे काम करता है

आप सही हैं, यह एक गंभीर दोष है, लेकिन हम थोड़ी देर बाद वापस आ जाएंगे। फिलहाल हम बात करते हैं कि शोषण क्यों होता है। ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) का उपयोग HTTP ( HTTPS ) सहित कई अनुप्रयोगों की जानकारी सुरक्षित करने या SMTP को सुरक्षित करने के लिए किया जाता हैयदि उदाहरण के लिए सक्षम है। आरएफसी 5246 में, जो टीएलएस के लिए मानक निर्धारित करता है, एक समारोह है जिसे दिल की धड़कन के रूप में जाना जाता है। क्लाइंट और सर्वर कनेक्शन को जीवित रखने के लिए कुछ डेटा आगे-पीछे भेजते हैं ताकि बाद में इसका इस्तेमाल किया जा सके। अब व्यवहार में क्लाइंट कुछ डेटा भेजेगा और सर्वर इसे वापस भेज देगा, और सब कुछ बहुत अच्छा है। हालांकि प्रभावित ओपनएसएसएल संस्करणों में यह देखने के लिए कोई चेक नहीं है कि क्या ग्राहक ने वास्तव में डेटा की मात्रा भेजी है जो उसने कहा था। इसलिए अगर मैं इसे 1 बाइट भेजता हूं और सर्वर को बताता हूं कि मैंने वास्तव में इसे 64 केबी भेजा है तो यह खुशी से मुझे 64 बीबी भेजने वाला है। वे अन्य बाइट्स कहां से आते हैं? यही समस्या की कुंजी है। OpenSSL आपको 64 kB - 1 बाइट्स वापस भेजने जा रहा है जिसकी प्रक्रिया तक पहुँच है और जिसे आपने मूल रूप से नहीं भेजा है, इस पर निर्भर करता है कि आपका 1 बाइट कहाँ संग्रहीत है।निजी कुंजी सामग्री और जानकारी जिसे सर्वर उपयोग करने के लिए डिक्रिप्ट कर रहा है। इसके उदाहरण होंगे: पासवर्ड, क्रेडिट कार्ड की जानकारी और / या पिन

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

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

यह कब सुरक्षित होगा? यह कब सुरक्षित होगा यह जानना एक कठिन सवाल है। कुछ चीजें जो मैं देखने का सुझाव दूंगा, सार्वजनिक घोषणाएं हैं जो बताती हैं कि बग को उनके वातावरण में पैच किया गया है या वे कभी कमजोर नहीं थे, क्योंकि उन्होंने कभी प्रभावित संस्करणों का उपयोग नहीं किया। जब उन्होंने घोषणा की कि उन्होंने ओपनएसएसएल के एक नए संस्करण में अपग्रेड किया है तो मैं यह सुनिश्चित करूंगा कि वे शोषण के सार्वजनिक रिलीज की तारीख के बाद हस्ताक्षरित एक नए प्रमाण पत्र का उपयोग कर रहे हैं जो 2014-04-07 था।

** ध्यान दें कि पहले दर्ज की गई ट्रैफ़िक को डिक्रिप्ट किया जा सकता है यदि निजी कुंजी बाद में लीक हो गई थी।

मैं खुद को बचाने के लिए एक उपयोगकर्ता के रूप में क्या कर सकता हूं

अगले कुछ दिनों के लिए यदि आप ऑनलाइन बैंकिंग या ऑनलाइन मेडिकल चार्ट एक्सेस जैसी महत्वपूर्ण साइटों का उपयोग करने से बच सकते हैं तो मैं आपको ऐसा करने का सुझाव दूंगा। यदि आपको ऐसा समझना चाहिए कि आपका सत्र संभावित रूप से जोखिम में है और उस के परिणामों को स्वीकार करने के लिए तैयार रहें। इसके अलावा, संगठनों द्वारा यह घोषणा करने के बाद कि वे अब कमजोर नहीं हैं, आपको अपना पासवर्ड बदलना चाहिए ; पासवर्ड मैनेजर का उपयोग करने से मदद मिल सकती है। आपको किसी भी अन्य जानकारी को बदलने या मॉनिटर करने के लिए तैयार होना चाहिए जो आपने बैंक विवरण या क्रेडिट कार्ड नंबर का उपयोग किया था।

कार्यकर्ताओं को विशेष नोटिस

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

** ध्यान दें कि पहले से दर्ज ट्रैफ़िक को डिक्रिप्ट किया जा सकता है यदि बाद में निजी कुंजी को लीक नहीं किया गया जब तक कि पूर्ण अग्रेषित सुरक्षा (PFS) को लागू नहीं किया गया।

Been- ऐसे दावे किए गए हैं कि यह संभावना है कि निजी चाबियाँ स्मृति में नहीं होंगी, लेकिन साथ ही साथ सफल कुंजी निष्कर्षण के दावे भी किए गए हैं। इस बिंदु पर यह अनिश्चित है कि कौन सा पक्ष सही है।


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

4
हम कैसे जान सकते हैं कि नई कुंजी का उपयोग करके नए प्रमाण पत्र बनाए गए हैं?

3
Note that previously recorded traffic may be decrypted if the private key was later leaked. नहीं अगर सर्वर आगे गोपनीयता के साथ एक सिफर का उपयोग कर रहा था।
वेस

2
@ आप सही हैं कि पीएफएस सबसे अधिक संभावना है कि यातायात को सुरक्षित रखेगा। मैं लोगों को भ्रमित किए बिना स्थिति को स्पष्ट करने की एक अच्छी रेखा पर चलने की कोशिश कर रहा था। दुर्भाग्य से पीएफएस को व्यापक रूप से तैनात नहीं किया गया था।
जैकब ने

6
योग करने के लिए what is heartbleed bug xkcd.com/1354
GoodSp33d

14

इस भेद्यता से उत्पन्न जोखिम को ओवरहीप किया जा रहा है। मैं यह कहता हूं क्योंकि शून्य सबूत है कि यह भेद्यता 2 दिन पहले शोधकर्ताओं द्वारा इसके प्रकाशन से पहले ज्ञात या शोषित थी।

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

यह कहते हुए कि, मुझे नहीं लगता कि सार्वजनिक प्रेस द्वारा इस जोखिम से जुड़े जोखिम का स्तर उचित है।

व्यक्तियों को अपनी सुरक्षा के लिए क्या करना चाहिए? उन साइटों का उपयोग न करें, जो ओपनएसएसएल के असुरक्षित संस्करण चला रहे हैं।

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

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

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

- एल वीजो


9
इस उत्तर को अधिक IMO को वोट देना चाहिए। कर रहे हैं बहुत सारे हर महीने है कि लोगों को सर्वर निजी कुंजी चोरी करने की अनुमति होगी प्रकाशित कमजोरियों का है, और नहीं उपद्रव का एक बहुत उनके बारे में किया जाता है। यह एक है और अधिक औसत से OpenSSL के सर्वव्यापकता के कारण गंभीर, लेकिन यह अभी भी अति-प्रचार किया जा रहा है।
एलेस्टेयर

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

6
-1 क्योंकि यह लेखक वास्तव में उन हमलों की प्रकृति को नहीं समझता है जो मुझे नहीं लगता। एक के लिए, इस तरह की पहुंच रखने वाले हमलावर इसे गुप्त रखने और अपनी घुसपैठ के सबूतों को बाहर न आने देने के लिए बहुत मेहनत करेंगे। इस तरह की एक बग जो इंटरनेट पर लगभग आधे सुरक्षित यातायात की सुरक्षा में कटौती करती है, भेड़ियों को रोना बिलकुल नहीं है। मेरे विचार से यह बहुत गंभीर मामला है।
अण्डाकार दृश्य

19
मैं ब्रूस श्नीयर को सबसे अधिक सम्मान देता हूं, जब आईटी सुरक्षा की बात आती है। हार्टबल भेद्यता के बारे में अपने ब्लॉग पोस्ट को उद्धृत करने के लिए : "कैटास्ट्रॉफिक" सही शब्द है। 1 से 10 के पैमाने पर, यह एक 11 है । अकेले ही मेरे लिए इस मुद्दे के नीचे की दृढ़ता से असहमत होने के लिए पर्याप्त है।
एबस्ट्रैस

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

5

प्रत्येक वेबसाइट HTTPS के लिए OpenSSL लाइब्रेरीज़ का उपयोग नहीं करती है (उदाहरण के लिए GnuTLS और PolarSSL भी), और OpenSSL का प्रत्येक संस्करण असुरक्षित नहीं था (पुराने संस्करण नहीं थे)। इसका मतलब यह है कि जिन वेबसाइटों का आपने उल्लेख किया है, उनके लिए उचित मौका नहीं है क्योंकि उन्हें प्रमाणपत्रों की आवश्यकता नहीं है। अभी जारी किए गए प्रमाण पत्रों को देखकर आपको पर्याप्त नहीं बताया गया है।

कई उपकरण और साइटें हैं जो आपको यह जांचने में मदद कर सकती हैं कि क्या कोई वेबसाइट असुरक्षित है, उदाहरण के लिए: - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - https/: /www.ssllabs.com/ssltest/

दुर्भाग्य से, जैसा कि आप पहले ही बता चुके हैं, यह आपको नहीं बताता कि क्या वे थे। मुझे डर है कि यहाँ प्रमुख मुद्दा विश्वास है: एसएसबी पुस्तकालयों को सत्यापित करने के लिए कोई तरीका नहीं है जिस तरह से वे उपयोग करते हैं और बिना सूचना के उपयोग करते हैं। आपको आशा है कि उन्होंने वही किया है जो उन्हें करने की आवश्यकता है (क्योंकि यह सही बात है, या यहां तक ​​कि क्योंकि वे सार्वजनिक अपमान से डरते हैं) और अगर उन्होंने किया तो आप केवल आशा कर सकते हैं कि वे इसके बारे में खुले हैं।

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

तो मैं जो सबसे अच्छी सलाह दे सकता हूं वह सामान्य सलाह का एक टुकड़ा है: सावधान रहें कि आप इंटरनेट पर क्या छोड़ते हैं और आप अपनी व्यक्तिगत जानकारी के साथ किन वेबसाइटों पर भरोसा करते हैं।


3
अपरिहार्य PolarSSL बग के लिए प्रतीक्षा करता है प्रकट करने के लिए (यह है सूची में अगले ...)
strugee

1

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

मेरी समझ यह है कि उन्हें अभी भी आपके स्थानीय LAN और ARP स्पूफिंग या इंटरनेट राउटर के लिए झूठे मार्गों का विज्ञापन करके अपहृत / रीडायरेक्ट ट्रैफ़िक होने पर यातायात को रोकना होगा । इस भेद्यता के बिना भी इस तरह के हमले हमेशा से संभव रहे हैं।


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

ऐसा नहीं। यह एक मैन-इन-द-मिडिल हमले के रूप में अच्छी तरह से समझौता किया जा सकता है। इसके अलावा स्मृति डम्प केवल उस सत्र को प्रभावित नहीं करता, यह संभव है (स्मृति ब्लॉक की सामग्री पर निर्भर करता है) एन्क्रिप्ट नहीं किए गए उपयोगकर्ता नाम और अन्य उपयोगकर्ताओं के पासवर्ड, निजी कुंजी के अलावा सभी यातायात डिकोडिंग [MITM हमले के माध्यम से] facilite को देखने के लिए
दाविदगो

मुझे लगता है कि मुझे थोड़ा स्पष्ट होना चाहिए था कि मैं मुख्य रूप से सर्वर के पैच होने के बाद समझौता किए गए कुंजी के उपयोग की बात कर रहा था।
पीटर जेआर

0

आप LastPass Heartbleed Checker में किसी साइट के लिए URL दर्ज कर सकते हैं और यह आपको बताएगा कि साइट अभी भी असुरक्षित थी या नहीं, और जब इसका प्रमाणपत्र अपडेट किया गया था।

क्रोमब्लड नामक एक क्रोम एक्सटेंशन भी है जो आपको हार्टबल से प्रभावित साइट पर जाने पर चेतावनी देगा।

Mashable.com में अच्छी तरह से ज्ञात साइटों की एक सूची है, चाहे वे प्रभावित थे, और क्या आपको अपना पासवर्ड बदलना चाहिए। दिलचस्प बात यह है कि बैंकों और ब्रोकरेज सूची में कोई भी साइट प्रभावित नहीं हुई।


0

मैं निम्नलिखित साइट पर भी जाऊंगा:

https://www.ivpn.net/blog/heartbleed-passwords-change

उनके पास लोकप्रिय साइटों की एक सूची है जो प्रभावित हुई है और आपको अपने पासवर्ड कब और कहां बदलने चाहिए


-1

कुल मिलाकर, मैं कहूंगा कि व्यामोह को आप तक नहीं पहुंचने देंगे। वास्तविक रूप से बस यातायात को डिक्रिप्ट करने में सक्षम होने और अपना पासवर्ड प्राप्त करने के लिए वास्तव में ऐसा करने के समान नहीं है।

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

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


1
टू-फैक्टर ऑथेंटिकेशन किसी भी दुर्भावनापूर्ण पार्टी को ऐसे कुछ भी करने से नहीं रोकेगा जो इस शोषण के आसपास संभव है। मुझे यकीन नहीं है कि आप इसे लाएंगे। अपने सामाजिक खातों तक पहुँच प्राप्त करना वास्तव में किसी ऐसे व्यक्ति की चिंता नहीं है जो ओपनएसएसएल के किसी भी रास्ते में इस शोषण का लाभ उठा सकता है।
रामहाउंड

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

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

हाँ, लेकिन पासवर्ड का पुन: उपयोग करना वास्तव में एक अलग असफलता है। मेरी बात यह थी कि दो कारक बाद की गंभीरता और दीर्घायु को कम करने में मदद करते हैं, लेकिन हाँ यह वास्तविक बग का शोषण करने में मदद नहीं करेगा।
सेरेक्स

@ साइरेक्स जहां तक ​​मैं कोई भी साइट नहीं बता सकता हूं कि मैं टू-फैक्टर के उपयोग से लॉग इन करता हूं, मेरी मशीन पर कुकीज़ अमान्य हैं। यह निश्चित रूप से उनकी ओर से एक विफलता है, लेकिन मेरा कहना है, फिलहाल दो-कारक का एक रक्षक नहीं है। एक हमलावर कुकीज़ को आसानी से रोक सकता है और अपने अनुरोधों पर उनका उपयोग कर सकता है। इसके अलावा, चूंकि यह जानने का कोई तरीका नहीं है कि किसी ने इस बग (यहां तक ​​कि सिस्टम प्रशासक के लिए) का शोषण किया या नहीं, केवल सुरक्षित धारणा यह है कि इसका शोषण किया गया था। मैं उदाहरण के लिए जानता हूं कि बुधवार सुबह तक चेस.कॉम कमजोर था। दुर्भाग्य से हमलावरों को याद किया।
क्रेजीकैस्टा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.