वास्तविकता यह है कि पासवर्ड डेटाबेस समझौता करता है कर रहे हैं कोई चिंता नहीं, इससे कोई फर्क नहीं पड़ता कि कोई कंपनी इसे स्पिन करने का प्रयास कैसे कर सकती है। लेकिन ऐसी कुछ चीजें हैं जो आप स्वयं को अपनाने के लिए कर सकते हैं, इससे कोई फर्क नहीं पड़ता कि कंपनी की सुरक्षा प्रथा कितनी खराब है।
पासवर्ड कैसे संग्रहीत किया जाना चाहिए
यहां बताया गया है कि कंपनियों को आदर्श दुनिया में पासवर्ड कैसे स्टोर करना चाहिए: आप एक खाता बनाते हैं और पासवर्ड प्रदान करते हैं। पासवर्ड को स्वयं संग्रहित करने के बजाय, सेवा पासवर्ड से "हैश" उत्पन्न करती है। यह एक अनोखा फिंगरप्रिंट है जिसे उलट नहीं किया जा सकता है। उदाहरण के लिए, पासवर्ड "पासवर्ड" कुछ ऐसा हो सकता है जो "4jfh75to4sud7gh93247g …" जैसा दिखता है। जब आप लॉग इन करने के लिए अपना पासवर्ड दर्ज करते हैं, तो सेवा उस से हैश उत्पन्न करती है और जांचती है कि हैश मान डेटाबेस में संग्रहीत मान से मेल खाता है या नहीं। किसी भी समय सेवा कभी भी डिस्क पर अपना पासवर्ड सहेजती नहीं है।
इसे रोकने के लिए, सेवाओं को अपने हैंश "नमक" चाहिए। पासवर्ड से हैश बनाने के बजाय, वे इसे बंद करने से पहले पासवर्ड के सामने या अंत में एक यादृच्छिक स्ट्रिंग जोड़ते हैं। दूसरे शब्दों में, उपयोगकर्ता पासवर्ड "पासवर्ड" दर्ज करेगा और सेवा नमक और हैश को एक पासवर्ड जोड़ देगा जो "password35s2dg" जैसा दिखता है। प्रत्येक उपयोगकर्ता खाते का अपना अद्वितीय नमक होना चाहिए, और यह सुनिश्चित करेगा कि प्रत्येक उपयोगकर्ता खाता डेटाबेस में उनके पासवर्ड के लिए एक अलग हैश मूल्य होगा। यहां तक कि यदि एकाधिक खातों ने पासवर्ड "पासवर्ड 1" का उपयोग किया है, तो अलग-अलग नमक मूल्यों के कारण उनके पास अलग-अलग हैंश होंगे। यह एक हमलावर को हरा देगा जिसने पासवर्ड के लिए हैश की गणना करने की कोशिश की थी। एक ही समय में पूरे डेटाबेस में प्रत्येक उपयोगकर्ता खाते पर लागू हैश उत्पन्न करने में सक्षम होने के बजाय, उन्हें प्रत्येक उपयोगकर्ता खाते और इसके अद्वितीय नमक के लिए अद्वितीय हैश उत्पन्न करना होगा। यह अधिक गणना समय और स्मृति ले जाएगा।
यही कारण है कि सेवाएं अक्सर चिंता न करें। उचित सुरक्षा प्रक्रियाओं का उपयोग करने वाली एक सेवा में यह कहना चाहिए कि वे नमकीन पासवर्ड हैंश का उपयोग कर रहे थे। अगर वे बस कह रहे हैं कि पासवर्ड "हैंश" हैं, तो यह अधिक चिंताजनक है। लिंक्डइन ने अपने पासवर्ड धोए, उदाहरण के लिए, लेकिन उन्होंने उन्हें नमक नहीं दिया- इसलिए यह एक बड़ा सौदा था जब लिंकडइन ने 2012 में 6.5 मिलियन शेड पासवर्ड खो दिए।
खराब पासवर्ड व्यवहार
- सादा पाठ में पासवर्ड संग्रहित करना: हैशिंग के साथ परेशान होने की बजाय, कुछ सबसे बुरे अपराधी पासवर्ड को सादे पाठ रूप में डेटाबेस में डंप कर सकते हैं। यदि ऐसे डेटाबेस से समझौता किया गया है, तो आपके पासवर्ड स्पष्ट रूप से समझौता किए गए हैं। इससे कोई फर्क नहीं पड़ता कि वे कितने मजबूत थे।
- उन्हें सलाम किए बिना पासवर्ड को धक्का देना: कुछ सेवाओं में पासवर्ड हैश हो सकता है और नमक का उपयोग न करने का विकल्प चुन सकता है। ऐसे पासवर्ड डेटाबेस लुकअप टेबल के लिए बहुत कमजोर होंगे। एक हमलावर कई पासवर्ड के लिए हैश उत्पन्न कर सकता है और फिर जांच कर सकता है कि क्या वे डेटाबेस में मौजूद हैं - अगर वे नमक का उपयोग नहीं किया जाता है तो वे प्रत्येक खाते के लिए ऐसा कर सकते हैं।
- नमक का पुन: उपयोग करना: कुछ सेवाएं नमक का उपयोग कर सकती हैं, लेकिन वे प्रत्येक उपयोगकर्ता खाता पासवर्ड के लिए एक ही नमक का पुन: उपयोग कर सकते हैं। यह व्यर्थ है- यदि प्रत्येक उपयोगकर्ता के लिए एक ही नमक का उपयोग किया जाता है, तो उसी पासवर्ड वाले दो उपयोगकर्ताओं के पास एक ही हैश होगा।
- लघु नमक का उपयोग करना: यदि केवल कुछ अंकों के लवण का उपयोग किया जाता है, तो संभवतः हर संभव नमक को शामिल करने वाले लुकअप टेबल उत्पन्न करना संभव होगा। उदाहरण के लिए, यदि नमक के रूप में एक अंक का उपयोग किया जाता है, तो हमलावर आसानी से हैश की सूचियां उत्पन्न कर सकता है जिसमें हर संभव नमक शामिल होता है।
कंपनियां हमेशा आपको पूरी कहानी नहीं बताएंगी, इसलिए यदि वे कहते हैं कि पासवर्ड धोया गया था (या धोया और नमकीन), तो वे सर्वोत्तम प्रथाओं का उपयोग नहीं कर रहे हैं। सावधानी के पक्ष में हमेशा गलती करें।
अन्य चिंताएं
यह संभावना है कि पासवर्ड डेटाबेस में नमक मान भी मौजूद है। यह बुरा नहीं है- यदि प्रत्येक उपयोगकर्ता के लिए एक अद्वितीय नमक मूल्य का उपयोग किया जाता है, तो हमलावरों को उन सभी पासवर्ड को तोड़ने के लिए बड़ी मात्रा में सीपीयू पावर खर्च करना होगा।
व्यावहारिक रूप से, बहुत से लोग स्पष्ट पासवर्ड का उपयोग करते हैं कि कई उपयोगकर्ता खातों के पासवर्ड निर्धारित करना आसान होगा। उदाहरण के लिए, यदि कोई हमलावर आपके हैश को जानता है और वे आपके नमक को जानते हैं, तो वे आसानी से यह देखने के लिए जांच सकते हैं कि आप कुछ सबसे आम पासवर्ड का उपयोग कर रहे हैं या नहीं।
यदि कोई हमलावर आपके लिए बाहर निकलता है और आपका पासवर्ड क्रैक करना चाहता है, तो वे इसे तब तक बलपूर्वक बल के साथ कर सकते हैं जब तक वे नमक मूल्य को जानते हों-जो वे शायद करते हैं।स्थानीय, ऑफ़लाइन पासवर्ड डेटाबेस तक पहुंच के साथ, हमलावर सभी ब्रूट फोर्स हमलों को नियोजित कर सकते हैं।
पासवर्ड डेटाबेस चोरी होने पर अन्य व्यक्तिगत डेटा भी लीक हो सकता है: उपयोगकर्ता नाम, ईमेल पते आदि। याहू रिसाव के मामले में, सुरक्षा प्रश्न और उत्तर भी लीक किए गए थे - जैसा कि हम सभी जानते हैं, किसी के खाते तक पहुंच चोरी करना आसान बनाता है।
सहायता, मुझे क्या करना चाहिए?
जो भी सेवा कहती है जब उसका पासवर्ड डेटाबेस चोरी हो जाता है, तो यह मानना सबसे अच्छा है कि हर सेवा पूरी तरह से अक्षम है और तदनुसार कार्य करती है।
सबसे पहले, एकाधिक वेबसाइटों पर पासवर्ड का पुन: उपयोग न करें। एक पासवर्ड प्रबंधक का प्रयोग करें जो प्रत्येक वेबसाइट के लिए अद्वितीय पासवर्ड उत्पन्न करता है। यदि कोई हमलावर यह पता लगाने का प्रबंधन करता है कि सेवा के लिए आपका पासवर्ड "43 ^ tSd% 7uho2 # 3" है और आप केवल उस विशिष्ट वेबसाइट पर उस पासवर्ड का उपयोग करते हैं, तो उन्होंने कुछ भी उपयोगी नहीं सीखा है। यदि आप हर जगह एक ही पासवर्ड का उपयोग करते हैं, तो वे आपके अन्य खातों तक पहुंच सकते हैं। यह है कि कितने लोगों के खाते "हैक" बन जाते हैं।
आपको दो-कारक प्रमाणीकरण का उपयोग करने पर भी विचार करना चाहिए, जो एक हमलावर आपका पासवर्ड सीखने पर भी आपकी रक्षा करेगा।
सबसे महत्वपूर्ण बात पासवर्ड का पुन: उपयोग नहीं कर रही है। समझौता किए गए पासवर्ड डेटाबेस आपको चोट नहीं पहुंचा सकते हैं यदि आप हर जगह एक अद्वितीय पासवर्ड का उपयोग करते हैं - जब तक कि वे आपके क्रेडिट कार्ड नंबर की तरह डेटाबेस में कुछ और महत्वपूर्ण स्टोर न करें।
