यदि आप महसूस करते हैं कि आपका ईमेल होस्टिंग प्रदाता आपके पासवर्ड देख सकता है तो आप क्या करेंगे?

31

हमें अपने होस्टिंग प्रदाता से पिछले साल हमारे एक खाते के बारे में एक ईमेल मिला था- यह समझौता किया गया था और स्पैम के बजाय उदार मदद देने के लिए इस्तेमाल किया गया था।

जाहिरा तौर पर, उपयोगकर्ता ने अपने पासवर्ड को अपने नाम की भिन्नता के लिए रीसेट कर दिया था (अंतिम नाम कुछ ऐसा है जिसका आप शायद पहली बार अनुमान लगा सकते हैं।) वह तुरंत एक सप्ताह के भीतर हैक हो गया- उसके खाते ने 270,000 स्पैम ईमेलों का एक जलप्रलय भेजा- और बहुत जल्दी अवरुद्ध कर दिया।

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

हालाँकि, मुझे कुछ इस तथ्य से भी अधिक था कि हमारे एक खाते से समझौता किया गया था।

हमारे होस्टिंग प्रदाता, मददगार होने के प्रयास में, वास्तव में हमें निम्नलिखित ईमेल में पासवर्ड उद्धृत करते हैं :

यहाँ छवि विवरण दर्ज करें

मैं हैरान हूं। हम जल्द ही अपने अनुबंध को नवीनीकृत करने जा रहे हैं- और यह एक डीलब्रेकर की तरह लगता है।

एक होस्टिंग प्रदाता के लिए किसी खाते पर उपयोग किए जाने वाले वास्तविक पासवर्ड का पता लगाना कितना आम है?

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

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

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

इस पर आपके विचार सुनने के लिए उत्सुक।

— ऑस्टिन '' डेंजर '' पॉवर्स
स्रोत

4

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

— एंड्रयू बी

1

मैं एक तथ्य के लिए जानता हूं कि उपयोगकर्ता वेब इंटरफेस के माध्यम से पासवर्ड सेट करता है। उन्होंने इसे सर्वर पर रिकॉर्ड से ऊपर खींच लिया- कार्यालय में किसी ने भी उनसे फोन पर इसके बारे में बात नहीं की है (इसके अलावा, मेरा मानना है कि इस प्रदाता के पास वैसे भी केवल ईमेल का समर्थन है)

— ऑस्टिन '' डेंजर '' पॉवर्स

3

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

— मडहैटर

19

प्लेनटेक्स्ट पासवर्ड का भंडारण खराब है (जैसे Time to find a new providerखराब!) - बहुत से लोग इसे करते हैं लेकिन फिर भी: बीएडी। हालांकि एक अनएन्क्रिप्टेड ईमेल में आपको पासवर्ड भेजा जा रहा है ? मेरी सारी की सारी । यह सुरक्षा के लिए आकस्मिक उपेक्षा दर्शाता है। भागो, कुछ सामान्य ज्ञान के साथ एक नए प्रदाता के लिए, चलना नहीं ...

— voretaq7

2

मैं @MadHatter ने जो कहा है, उस पर विस्तार करना चाहता हूं: यहां के बहुत से लोग "स्टोरटेक्स्ट पासवर्ड को स्टोर करने" के विचार पर ध्यान केंद्रित कर रहे हैं। साधारण तथ्य यह है कि अगर मैं POP / IMAP सर्वर, SSH सर्वर, या कुछ और जिसमें आप अपना पासवर्ड टाइप कर सकते हैं, चला रहे हैं, तो इसे उस पासवर्ड को लॉग करने के लिए कॉन्फ़िगर किया जा सकता है जब आप इसे टाइप करते हैं , भले ही वह हो या न हो। मैं हैशड या क्लियरटेक्स में चीजों को स्टोर कर रहा हूं। Google आपका पासवर्ड देख सकता है और ड्रॉपबॉक्स आपका पासवर्ड देख सकता है और फेसबुक आपके पासवर्ड को देख सकता है और आगे। आप या तो अपने प्रदाता पर भरोसा करते हैं या इसे स्वयं होस्ट करते हैं।

— लार्क्स

33

हां, आईएसपी और ईमेल सेवा प्रदाताओं के लिए अपने पासवर्ड को सादे पाठ या एक प्रारूप में संग्रहीत करना आम बात है, जो सादे पाठ के लिए आसानी से पुनर्प्राप्त करने योग्य है।

इसका कारण पीपीपी (डायलअप और डीएसएल), आरडीआईयूएस (डायलअप, 802.1x, आदि) और पीओपी (ईमेल) के साथ उपयोग किए गए प्रमाणीकरण प्रोटोकॉल के साथ करना है।

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

उदाहरण के लिए PPP या RADIUS प्रमाणीकरण CHAP का उपयोग कर सकता है, जो प्रमाणीकरण डेटा को पारगमन में सुरक्षित करता है, लेकिन ISP द्वारा एक सादे पाठ पासवर्ड को संग्रहीत करने की आवश्यकता होती है। इसी प्रकार APOP एक्सटेंशन के साथ POP3 तक।

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

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

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

यह भी देखें कि क्या मुझे यह विश्वास करना गलत है कि पासवर्ड कभी भी रिकवर नहीं होने चाहिए (एक तरह से हैश)? हमारी बहन साइट पर आईटी सुरक्षा

— माइकल हैम्पटन
स्रोत

2

APOP का बहुत अधिक मृत प्रोटोकॉल है, और MSCHAPv2 को स्पष्ट रूप से पासवर्ड जानने के लिए सर्वर की आवश्यकता नहीं है - मुझे नहीं लगता कि इन दिनों एक सेवा प्रदाता के पास स्पष्ट पासवर्ड रखने का एक टन कारण है।

— शेन मैडेन

1

@ShaneMadden तुम सही हो; यह MSCHAP के बजाय CHAP है। और हाँ ये प्रोटोकॉल मृत के निकट हैं, लेकिन सेवा प्रदाता जो हमेशा के लिए रहे हैं वे अभी भी विरासत सेवाओं के लिए उनका उपयोग कर रहे हैं।

— माइकल हैम्पटन

हाँ - हालाँकि मैं यह सोचना चाहूँगा कि विरासत सेवा प्रदाताओं में से एक का पुराना पुराना LDAP है, जो क्लियरटेक्स्ट पासवर्डों से भरा है {crypt}(लोगों द्वारा लिया गया दृष्टिकोण, जो मैंने अतीत में देखा है। )। हालांकि यह सिर्फ इच्छाधारी सोच हो सकती है।

— शेन मैडेन

1

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

— orlp

1

@ नाइटक्रैकर आप जो भी डेटा ट्रांसफर करने जा रहे हैं उसकी तुलना में (एन्क्रिप्टेड के रूप में अच्छी तरह से, मुझे आशा है) प्रमाणीकरण डेटा की छोटी राशि वास्तव में आपको इतना परेशान नहीं करना चाहिए

— तोबियस किंजलर

12

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

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

— लम्बी गर्दन
स्रोत

28

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

— ऑस्टिन '' डेंजर '' पावर्स

7

वे या तो सादे पाठ में पासवर्ड संग्रहीत करने या किसी प्रकार के प्रतिवर्ती एन्क्रिप्शन का उपयोग करने की संभावना रखते हैं।

जैसा कि आपने surmised किया है, यह बहुत बुरा है।

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

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

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

— शेन मैडेन
स्रोत

1

मैं उनसे कुछ सवाल पूछूंगा और अगर वे कुछ भी दिलचस्प कहते हैं तो यहां पोस्ट करेंगे। मेरी सबसे बड़ी चिंता यह है कि वे संभावित रूप से 1) हमारे किसी भी ईमेल को पढ़ सकते हैं 2) हमारे ईमेल पढ़ने में, एक व्यक्तिगत ईमेल खाते का संदर्भ देखें 3) यदि कोई उपयोगकर्ता काम और व्यक्तिगत ईमेल के लिए एक ही पासवर्ड का उपयोग करता है, तो उनका व्यक्तिगत ईमेल हो सकता है। समझौता भी किया जाए।

— ऑस्टिन '' डेंजर '' पॉवर्स

@ Austin''Danger''Powers "संभावित रूप से 1) हमारे किसी भी ईमेल को पढ़ सकता है " कोई भी होस्ट ऐसा कर सकता है - कोई अपवाद नहीं (मेल सामग्री को स्वयं प्रेषक द्वारा एन्क्रिप्ट नहीं किया गया था - लेकिन यह एक अलग कहानी है)।

— orlp

मैंने सोचा था कि आमतौर पर केवल शीर्ष-स्तरीय समर्थन के लिए ही संभव है। यदि पासवर्ड को देखने से उनके किसी भी सपोर्ट प्रतिनिधि को कुछ हो सकता है, तो हमारे ईमेल के माध्यम से बेईमान / ऊब कर्मचारी को प्रहार करने का जोखिम बढ़ जाता है।

— ऑस्टिन '' डेंजर '' शक्तियों

5

अन्य सभी उत्तर महान हैं और बहुत अच्छे ऐतिहासिक बिंदु हैं।

हालाँकि, हम उस युग में रहते हैं जहाँ सादे पाठ में पासवर्ड संग्रहीत करने से भारी वित्तीय समस्याएँ पैदा होती हैं और यह पूरी तरह से व्यवसायों को नष्ट कर सकता है। असुरक्षित ईमेल के माध्यम से सादे पाठ में पासवर्ड भेजना भी एनएसए की उम्र में हास्यास्पद लगता है जो सभी पास-थ्रू डेटा को चूस रहा है।

आपको इस तथ्य को स्वीकार करने की आवश्यकता नहीं है कि कुछ पुराने प्रोटोकॉल को सादे पाठ में पासवर्ड की आवश्यकता होती है। यदि हम सभी इस तरह की सेवाओं को स्वीकार करना बंद कर देते हैं, तो शायद सेवा प्रदाता इसके बारे में कुछ करेंगे और अंतत: प्राचीन प्रौद्योगिकी को हटा देंगे।

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

मैं दूसरे ईमेल प्रदाता पर स्विच करूंगा। "सुरक्षित ईमेल प्रदाता" पर खोज से कई परिणाम मिलते हैं।

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

— ओलेक्सी
स्रोत

1

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

— ऑस्टिन '' डेंजर '' पॉवर्स

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

— ऑस्टिन '' डेंजर '' पॉवर्स

1

क्या वे अधिकतम लंबाई की आवश्यकता को लागू करते हैं? यह सादा पासवर्ड स्टोरेज के लिए लगभग हमेशा एक कैनरी है।

— मेल्स

1

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

— रोब मोइर

1

@RobM: बिल्कुल सही। क्या उपयोग यह प्रदाता पूछ अगर वे मानते हैं कि उनके है खुद सेवा सुरक्षित है? उनमें से 100% "हाँ" कहेंगे। एक सामान्य शब्द के लिए एक वेब खोज करना जैसे कुल समय बर्बाद करना है। ऐसा लगता है कि वास्तव में पूरे मामले पर संपर्क करने का एक भोला तरीका है: " क्या आपके सिस्टम सुरक्षित हैं? ठीक है, शानदार। आपको यह स्पष्ट करने के लिए धन्यवाद। उस मामले में हम बिना किसी हिचकिचाहट के आपकी सेवाओं की सदस्यता लेंगे। "

— ऑस्टिन '' डेंजर '' पॉवर्स

3

मेरी सिफारिश छोड़ने की है, और अगले लोगों से पूछें कि उनकी नीतियां पहले क्या हैं!
यदि आप अच्छा महसूस कर रहे हैं, तो आप पुराने प्रदाताओं को बता सकते हैं कि आप क्यों छोड़ रहे हैं।

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

उपयोग किए गए हैश एल्गोरिथ्म और GPU के आधार पर, एक आधुनिक पासवर्ड क्रैकिंग कंप्यूटर के बारे में 100 मिलियन प्रति सेकंड से एक अरब हैश के माध्यम से मंथन करने की उम्मीद की जा सकती है। के अनुसार इस , (जो एक सा यह सोचता है कि क्या एक कंप्यूटर / सुपर कंप्यूटर कर सकते हैं पर दिनांकित है), कि साधन किसी भी 6-चार पासवर्ड सेकंड में फटा जा सकता है। सभी विभिन्न एल्गोरिदम (MD5, SHA-1, SHA-256, SHA-512, ब्लोफिश, आदि) में 7 और 8 char हैश के लिए तालिकाओं में डिस्क स्थान की अयोग्य मात्रा का उपभोग होगा (एहसास है कि आपको उन्हें SSD पर संग्रहीत करने की आवश्यकता है) (एक्सेस स्पीड के लिए, एक मैग्नेटिक प्लैटर नहीं) और आप देख सकते हैं कि क्यों जीपीयू का उपयोग करते हुए शब्दकोश आधारित हमले पासवर्डों को अधिक तेज़ी से प्राप्त करने वाले हैं।

इस दृश्य में आने वाले लोगों के लिए एक अच्छा लेख यह है कि मैं कैसे अर्स टेक्निका में पासवर्ड क्रैकर बन गया ।

— निकोलस शैंक्स
स्रोत

यदि आपका दूसरा पैराग्राफ वास्तव में सच है, तो इसका मतलब है कि नमकीन बेकार हो गया। क्या यह आपकी व्यक्तिगत राय है या तथ्यों पर आधारित है?

— टोबियास किंजलर

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

— निकोलस शैंक्स

2

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

— टोबियास किंजलर

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

— निकोलस शैंक्स

1

अच्छी तरह से उस मामले में मैं सहमत हूं, लेकिन एक खराब / अप्रचलित / कमजोर हैश (जैसे एमडी 5) केवल एक सुरक्षा प्रासंगिक संदर्भ में अक्षम्य है।

— टोबियास किन्ज़लर

1

यह मेरे लिए हुआ!

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

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

कोई कारण नहीं है कि यह आपको, हमारी कंपनी को खुश करना चाहिए!

इस कंपनी की सुरक्षा के बारे में मेरा संदेह था, जब यह सुरक्षा के बारे में आया था, तो उनके साथ काम करने के वर्षों में मैंने यहाँ और वहाँ देखा। लेकिन मैंने हमेशा खुद को आश्वस्त किया कि यह कोई बड़ी बात नहीं थी या शायद मुझसे गलती हुई। मुझसे गलती नहीं हुई, और न ही आप!

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

अपनी प्रकृति पर विश्वास रखें! आलस से बाहर निकलने पर या अपने मौजूदा सेटअप "ठीक काम करता है" पर हिरन को पास न दें। कम लटके हुए सुरक्षा ओवरसाइट्स का सबसे अधिक नुकसानदायक हिस्सा जैसे स्पष्ट पाठ में पासवर्ड संग्रहीत करना, अनुचित तरीके से सर्वर को कॉन्फ़िगर करना, आदि यह है कि वे अपनी तकनीकी संस्कृति में एक सामान्य अक्षमता और / या आलस्य से बात करते हैं, और यह एक ऐसी संस्कृति है जिसे मैं अपनी कंपनी के मिशन को गंभीर नहीं बनाना चाहता। कहीं भी सेवा अनुबंध।

— मैट सुरबियन
स्रोत

0

मैं एक वैकल्पिक स्पष्टीकरण देख सकता हूं, जहां आपका पासवर्ड वास्तव में आपके प्रदाता के सर्वर पर हैशेड है।

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

यह आपके प्रदाता की तुलना में आसान लगता है जब डेटाबेस के रिकॉर्ड से भरा होता है कि किसने और कैसे अपना पासवर्ड बदला है। आप जानते हैं ओकाम का रेजर ...;)

— पेटा सीटेक
स्रोत