जब भी आपको किसी सेवा के पासवर्ड डेटाबेस को लीक करने की चिंता होती है तो आपको चिंता क्यों करनी चाहिए

“हमारा पासवर्ड डेटाबेस कल चोरी हो गया था। लेकिन चिंता न करें: आपके पासवर्ड एन्क्रिप्ट किए गए थे। ”हम नियमित रूप से याहू जैसे कल से ऑनलाइन इस तरह के बयान देखते हैं। लेकिन क्या हमें वास्तव में फेस वैल्यू पर ये आश्वासन लेना चाहिए?

वास्तविकता यह है कि पासवर्ड डेटाबेस समझौता करता है कर रहे हैं एक चिंता का विषय है, कोई फर्क नहीं पड़ता कि कैसे एक कंपनी इसे स्पिन करने की कोशिश कर सकती है। लेकिन कुछ चीजें हैं जो आप खुद को इन्सुलेट करने के लिए कर सकते हैं, भले ही किसी भी कंपनी की सुरक्षा प्रथाओं का कितना बुरा हो.

कैसे पासवर्ड संग्रहीत किया जाना चाहिए

यहां बताया गया है कि कंपनियों को एक आदर्श दुनिया में पासवर्ड कैसे स्टोर करना चाहिए: आप एक खाता बनाते हैं और एक पासवर्ड प्रदान करते हैं। पासवर्ड को स्वयं संग्रहीत करने के बजाय, सेवा पासवर्ड से एक "हैश" उत्पन्न करती है। यह एक अनूठा फिंगरप्रिंट है जिसे उलटा नहीं किया जा सकता है। उदाहरण के लिए, पासवर्ड "पासवर्ड" कुछ ऐसा हो सकता है जो "4jfh75to4sud7gh93247g ..." की तरह दिखता है। जब आप लॉग इन करने के लिए अपना पासवर्ड दर्ज करते हैं, तो सेवा उसमें से एक हैश उत्पन्न करती है और जाँचती है कि क्या हैश मूल्य डेटाबेस में संग्रहीत मूल्य से मेल खाता है या नहीं। किसी भी बिंदु पर सेवा कभी भी अपने पासवर्ड को डिस्क पर सहेजती नहीं है.

अपने वास्तविक पासवर्ड को निर्धारित करने के लिए, डेटाबेस तक पहुंच के साथ एक हमलावर को सामान्य पासवर्ड के लिए हैश की पूर्व-गणना करनी होगी और फिर जाँच करें कि क्या वे डेटाबेस में मौजूद हैं। हमलावर पासवर्डों से मेल खाने वाली हैश की बड़ी-बड़ी सूचियों के लुकअप के साथ ऐसा करते हैं। हैश की तुलना तब डेटाबेस से की जा सकती है। उदाहरण के लिए, एक हमलावर "पासवर्ड 1" के लिए हैश को जानता होगा और फिर देखेगा कि डेटाबेस में कोई भी अकाउंट उस हैश का उपयोग कर रहा है या नहीं। यदि वे हैं, तो हमलावर को पता है कि उनका पासवर्ड "पासवर्ड 1" है.

इसे रोकने के लिए, सेवाओं को अपने हैश को "नमक" करना चाहिए। पासवर्ड से ही हैश बनाने के बजाय, वे पासवर्ड के सामने या अंत में एक यादृच्छिक स्ट्रिंग जोड़ते हैं, इसे हैशिंग से पहले। दूसरे शब्दों में, एक उपयोगकर्ता पासवर्ड "पासवर्ड" दर्ज करेगा और सेवा में नमक और हैश एक पासवर्ड होगा जो "पासवर्ड 35s2dg" की तरह दिखता है। प्रत्येक उपयोगकर्ता खाते का अपना विशिष्ट नमक होना चाहिए, और यह सुनिश्चित करेगा कि प्रत्येक उपयोगकर्ता खाता। डेटाबेस में उनके पासवर्ड के लिए एक अलग हैश मान होगा। यहां तक कि अगर कई खातों ने पासवर्ड "पासवर्ड 1" का उपयोग किया, तो उनके पास अलग-अलग नमक मूल्यों के कारण अलग-अलग हैश होंगे। यह एक हमलावर को पराजित करेगा जिसने पासवर्ड के लिए पूर्व-संकलन की कोशिश की थी। एक बार में पूरे डेटाबेस में हर उपयोगकर्ता खाते पर लागू होने वाली हैश उत्पन्न करने में सक्षम होने के बजाय, उन्हें प्रत्येक उपयोगकर्ता खाते और उसके अद्वितीय नमक के लिए अद्वितीय हैश उत्पन्न करना होगा। यह अधिक गणना समय और स्मृति ले जाएगा.

यही कारण है कि सेवाएं अक्सर चिंता नहीं करने के लिए कहती हैं। उचित सुरक्षा प्रक्रियाओं का उपयोग करते हुए एक सेवा को कहना चाहिए कि वे नमकीन पासवर्ड हैश का उपयोग कर रहे थे। यदि वे बस कह रहे हैं कि पासवर्ड "हैशेड" हैं, तो यह अधिक चिंताजनक है। उदाहरण के लिए लिंक्डइन ने अपने पासवर्ड को हैशड किया, लेकिन उन्होंने उन्हें नमक नहीं डाला, इसलिए 2012 में लिंक्डइन ने 6.5 मिलियन हैशेड पासवर्ड खो दिए तो यह एक बड़ी बात थी।.

खराब पासवर्ड प्रैक्टिस

यह लागू करने के लिए सबसे मुश्किल काम नहीं है, लेकिन कई वेबसाइट अभी भी इसे कई तरीकों से गड़बड़ करने का प्रबंधन करती हैं:

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

कंपनियां हमेशा आपको पूरी कहानी नहीं बताएंगी, इसलिए भले ही वे कहें कि एक पासवर्ड हैशेड (या हैशेड और नमकीन) है, वे शायद सर्वोत्तम प्रथाओं का उपयोग नहीं कर रहे हैं। हमेशा सावधानी की ओर से गलती.

अन्य चिंताएं

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

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

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

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

मदद, मुझे क्या करना चाहिए?

जब भी कोई सेवा कहती है कि उसका पासवर्ड डेटाबेस चोरी हो गया है, तो यह मान लेना सबसे अच्छा है कि हर सेवा पूरी तरह से अक्षम है और तदनुसार कार्य करती है.

सबसे पहले, कई वेबसाइटों पर पासवर्ड का पुन: उपयोग न करें। एक पासवर्ड प्रबंधक का उपयोग करें जो प्रत्येक वेबसाइट के लिए अद्वितीय पासवर्ड उत्पन्न करता है। यदि कोई हमलावर यह पता लगाने का प्रबंधन करता है कि किसी सेवा के लिए आपका पासवर्ड "43 ^ tSd% 7uho2 # 3" है और आप केवल उस एक विशिष्ट वेबसाइट पर उस पासवर्ड का उपयोग करते हैं, तो उन्होंने कुछ उपयोगी नहीं सीखा है। यदि आप हर जगह एक ही पासवर्ड का उपयोग करते हैं, तो वे आपके अन्य खातों तक पहुंच सकते हैं। इस तरह से कई लोगों के खाते "हैक" हो जाते हैं।

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

आपको दो-कारक प्रमाणीकरण का उपयोग करने पर भी विचार करना चाहिए, जो एक हमलावर द्वारा आपका पासवर्ड जानने पर भी आपकी रक्षा करेगा.

सबसे महत्वपूर्ण बात पासवर्ड का पुन: उपयोग नहीं करना है। यदि आप हर जगह एक अद्वितीय पासवर्ड का उपयोग करते हैं, तो कंप्रोमाइज्ड पासवर्ड डेटाबेस आपको नुकसान नहीं पहुंचा सकते - जब तक कि वे डेटाबेस में कुछ और स्टोर न करें, जैसे आपका क्रेडिट कार्ड नंबर.

इमेज क्रेडिट: फ्लिकर, विकिमीडिया कॉमन्स पर मार्क फालार्डो