यदि उन्हें सुरक्षित डेटाबेस में संग्रहीत किया जा रहा है तो पासवर्ड को क्यों एन्क्रिप्ट किया जाना चाहिए?


78

मेरे पास एक वेब सेवा है। अभी, मेरे पास अपने सर्वर पर एक MySQL तालिका में सादे पाठ में संग्रहीत पासवर्ड हैं । मुझे पता है कि यह सबसे अच्छा अभ्यास नहीं है, और यही कारण है कि मैं इस पर काम कर रहा हूं।

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

मैं जिस परिदृश्य के बारे में सोच सकता हूं, वह यह है कि आपको हैक किया गया है। आप कुछ घंटे पहले एक डेटाबेस को पुनर्स्थापित करते हैं और सब कुछ ठीक है। हालाँकि, यदि आपके पासवर्ड सादे हैं ... चोर के पास सभी पासवर्ड हैं और आपको उन सभी को रीसेट करना होगा। अपने उपयोगकर्ताओं के लिए परेशानी।

यदि पासवर्ड एन्क्रिप्ट किए गए थे, तो आप पिछले डेटाबेस को पुनर्स्थापित कर सकते हैं। क्या यह सही सोच है?


124
मैं एक कदम आगे जाता। इसे एन्क्रिप्ट करना पर्याप्त नहीं है। आप इसे हैश करना चाहते हैं। इस तरह, यहां तक ​​कि आपको यह जानने में भी सक्षम नहीं होना चाहिए कि आपके उपयोगकर्ताओं के सादे पासवर्ड क्या हैं।
सांता

67
@ संता का पासवर्ड हैक करना काफी नहीं है। रेसिपी को काफी अच्छा बनाने के लिए आपको
थोड़ा सा

16
कृपया इस प्रासंगिक Security.StackExchange पोस्ट पर एक नज़र डालें: सुरक्षित रूप से हैश पासवर्ड कैसे करें?
आदि

10
असंतुष्ट डीबीए कहता है ... उपयोगकर्ता से * का चयन करें, और फिर गंभीरता से भुगतान के लिए उस सूची को बेचता है। कुछ भी कभी सुरक्षित नहीं है।
जॉन रेनोर

जवाबों:


194

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

लेकिन, बहुत अधिक महत्वपूर्ण बात, यह आपके बारे में नहीं है। तथ्य यह है कि आप खराब हो सकते हैं यदि किसी के पास आपके डेटाबेस तक पूर्ण पहुंच अप्रासंगिक है। बहुत अधिक महत्वपूर्ण आपके उपयोगकर्ता का डेटा है।

यदि आप अपने डेटाबेस को पुनर्प्राप्त करते हैं, तो हैकर के पास अभी भी आपके उपयोगकर्ता के खाते तक पहुंच है।

और कौन जानता है और क्या? यदि वे Google पर समान पासवर्ड का उपयोग करते हैं तो क्या होगा? या पेपाल? क्या होगा अगर वह एक हैकर को अपनी माँ के पहले नाम, या उनके क्रेडिट कार्ड के अंतिम 4 अंक तक पहुँच देता है?

क्या होगा अगर वह उन्हें अन्य खातों में मिलता है? उपयोगकर्ता समर्थन प्रणाली के माध्यम से जाने के लिए और अधिक जानकारी प्राप्त करने के लिए इसे हैकर के सामने न रखें ।

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

संपादित करें: एक अतिरिक्त टिप्पणी, किसी भी भविष्य के पाठक को हर उत्तर और टिप्पणी को पढ़ने से बचाने के लिए ...

यदि आप एन्क्रिप्ट करने जा रहे हैं (सबसे कठिन अर्थ में) तो आपको एक सार्वजनिक / निजी कुंजी जोड़ी का उपयोग करने की आवश्यकता है , जो ठीक है लेकिन आपके और आपके उपयोगकर्ता दोनों के लिए जीवन को थोड़ा और कठिन बना देता है।

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


89
या बेहतर, यह हैश!
ब्लोर्बियरड

29
इस। "मुझे कोई और समस्या है अगर कोई मेरे डेटाबेस में मिलता है"। यह आपका डेटाबेस है, अगर आपको हैक किया जाता है तो आपको समस्या होने की उम्मीद है। लेकिन प्लेनटेक्स्ट पासवर्ड को स्टोर करके आप अपने सभी उपयोगकर्ताओं को संभावित रूप से, उनके सभी अन्य खातों के साथ समस्याएँ देते हैं। आप कितने लोगों को वास्तव में हर एक वेबसाइट पर एक अलग पासवर्ड का उपयोग करते हैं?
कार्सन 63000

13
Blorgbeard की सलाह का पालन करें, हो सकता है पढ़ने के इस । जब आपके वेब सर्वर से समझौता किया गया हो, तो पासवर्ड एन्क्रिप्ट करना सुरक्षा प्रदान नहीं करता है। पासवर्ड को डिक्रिप्ट करने की कुंजी सर्वर पर कहीं संग्रहीत होनी चाहिए। पासवर्डों को हाशिल करने का मतलब है कि इस घटना में भी कि किसी की मशीन तक पूरी पहुंच है, वे पासवर्ड को आसानी से पुनर्प्राप्त नहीं कर सकते हैं।
स्लीडपैन

7
यदि आपके सिस्टम में कोई मूल्य नहीं है तो आपको पासवर्ड को एन्क्रिप्ट करने की आवश्यकता क्यों होगी? किस बिंदु पर आपको तुलना के अलावा पासवर्ड को डिक्रिप्ट करना होगा? @pdr, आपको ओपी को एन्क्रिप्ट करने के लिए नहीं कहा जाना चाहिए, आपको उसे नमक और हैश के बारे में बताना चाहिए।
नोबल उत्थान

4
आप उनके पासवर्ड रिकवरी सवालों के जवाब भी चाहते हैं। अन्यथा उन का उपयोग अन्य साइटों में भी किया जा सकता है, जैसे पासवर्ड।
ज़ेन लिंक्स

64

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

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

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

ठीक से हैशेड और नमकीन पासवर्ड मूल रूप से वन-वे है। आप हैशेड पासवर्ड से पासवर्ड का अनुमान आसानी से नहीं लगा सकते। यहां तक ​​कि आप, जैसा कि सेवा प्रदाता यह अनुमान लगाने में सक्षम नहीं होगा, आप केवल इसे रीसेट कर सकते हैं।

इसके अलावा, जैसा कि एलिन ने कहा, कोशिश करें और अपने स्वयं के हैशिंग (या एन्क्रिप्शन) को रोल न करें। एक मानक पुस्तकालय का उपयोग करें।



13
असंतुष्ट कर्मचारियों का उल्लेख करने के लिए +1। जब आप किसी एक-व्यक्ति की दुकान या छोटी कंपनी के हों, तो उसे अनदेखा करना आसान होता है, लेकिन अंततः आपके पास डेटा के साथ काम करने वाले लोग होंगे जिन्हें आपने व्यक्तिगत रूप से वीटो नहीं किया है।

2
उपयोगकर्ताओं की एक सूची के माध्यम से लूप करने के लिए फॉरेक्स लिखना और फिर उनके पासवर्ड हैश करना कुछ मिनटों का काम है और स्पष्ट रूप से 4000 शायद ही कुछ भी हो। php.net/manual/en/function.hash.php
एलिन

3
आप "हैश और नमक" @ david25272 के साथ "एन्क्रिप्ट" शब्दों के बीच स्विच करते रहते हैं। दोनों को भ्रमित न करें, जो पूरी तरह से अलग हैं। अब ओपी एक एन्क्रिप्शन एल्गोरिथ्म की तलाश कर रहा है, न कि कोई हैश एल्गोरिथम। इसके अलावा, यह "नमक और हैश" है, "हैश और नमक" नहीं। आप हैश करने के बाद नमक नहीं खा सकते।
नोबल अपलिफ्ट

1
इसके अलावा @phpmysqlguy, सलाम और हैश एल्गोरिदम पर सुझावों के लिए मेरा जवाब पढ़ें ।
नोबल उत्थान

36

लेकिन मुझे अन्य समस्याएं हैं यदि कोई मेरे डेटाबेस में मिलता है, अर्थात डेटा को हटाना।

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

देखें, भले ही लोगों को अलग-अलग प्रणालियों पर अलग-अलग पासवर्ड का उपयोग करना चाहिए , वास्तविकता यह है कि नहीं

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


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

1
+1 इस तथ्य के लिए कि एक डेवलपर / व्यवस्थापक के रूप में आपको अपने उपयोगकर्ताओं के पासवर्ड तक पहुंच नहीं होनी चाहिए। वह अपने आप में पर्याप्त है।
मैट

21

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

इसके अलावा, सभी समझौते आपको पूर्ण शेल एक्सेस नहीं देते हैं। क्या होगा यदि एक हमलावर द्वारा उपयोग की जाने वाली भेद्यता usersमेज पर सिर्फ एक SQL-केवल इंजेक्शन है ? पासवर्डों को अनसुना करने से बस उसे बहुत अधिक पूर्ण एक्सेस मिल गया।

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


18

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

आइए परिभाषाओं पर एक नज़र डालें:

क्रिप्टोग्राफी में, एन्क्रिप्शन संदेश (या सूचना) को इस तरह से एन्कोडिंग करने की प्रक्रिया है, जिसे केवल अधिकृत पार्टियां ही पढ़ सकती हैं।

और हैशिंग:

एक हैश फ़ंक्शन किसी भी एल्गोरिथ्म है जो एक निश्चित लंबाई के डेटा के लिए मनमाने ढंग से लंबाई के डेटा को मैप करता है।

दूसरे शब्दों में, एन्क्रिप्शन एक दो-तरफ़ा रूपांतरण है और हैशिंग एक-तरफ़ा रूपांतरण है, इसलिए जब तक आप उन्हें बाद में देखने के लिए डिक्रिप्ट नहीं कर रहे हैं, यह एन्क्रिप्शन नहीं है।

इसके अलावा, सिर्फ हैश, नमक मत करो! अपने पासवर्ड को हैश करने से पहले इस पूरे पृष्ठ को पढ़ें।

हैशिंग एल्गोरिदम के रूप में, जो ओपी अब देख रहा है, मैं SHA-384 या SHA-512 जैसे किसी भी उच्च-अंत SHA-2 संस्करण का सुझाव दूंगा।

और हैशिंग के राउंड का उपयोग करना सुनिश्चित करें । एक बार हैश मत करो, कई बार हैश।

अपनी लॉगिन प्रक्रिया को अधिक सुरक्षित करने के लिए इस पृष्ठ को पढ़ने पर विचार करें ।

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

अन्य बिंदुओं PDR बनाता है कर रहे हैं मैं वास्तव में और क्या कह सकते हैं कि: लोग हैं, जो हर वेबसाइट के लिए एक ही पासवर्ड का उपयोग, हैकर्स सोशल इंजीनियरिंग का उपयोग कर अधिक जानकारी हासिल करने के लिए, आदि आदि


हैश प्लस नमक के लिए +1 । लवण बिना हैश क्रैकिंग है sooo आसान।
कोड Maverick

3
आपको पता है कि इंद्रधनुष तालिका @CodeMaverick के दूसरी तरफ क्या है? सोने का एक बर्तन।
नोबल अपलिफ्ट

पासवर्ड हैशिंग के संदर्भ में एमडी 5 में तेजी से परे कोई ज्ञात भेद्यता नहीं है, और यह एसएचए -2 पर भी लागू होता है। MD5 पर SHA-2 चुनने की तुलना में धीमी, पुनरावृत्त निर्माण का उपयोग करना कहीं अधिक महत्वपूर्ण है।
कोडइन्चोस

4
"अपने पासवर्ड को हैश करने से पहले इस पूरे पृष्ठ को पढ़ें" - उस पृष्ठ में उल्लेख किया गया है कि आपको हैशिंग के राउंड का उपयोग नहीं करना चाहिए , लेकिन एक हैशिंग विधि जिसे विशेष रूप से आवश्यकतानुसार धीमा किया गया है, जैसे PBKDF2।
झोमिनल

2
SCrypt या PBKDF2 का उपयोग करें, दोनों को मेमोरी या सीपीयू के संदर्भ में प्रदर्शन करने के लिए बहुत महंगा बनाया गया है। एक बेतरतीब ढंग से उत्पन्न नमक का उपयोग करें जिसे आप उपयोगकर्ता रिकॉर्ड पर संग्रहीत करते हैं। हैशिंग के कई राउंड न करें, जिससे बस टकराव की समस्या होती है।
tom.dietrich

14

यहां दांव पर एक महत्वपूर्ण सिद्धांत है। केवल एक व्यक्ति है जिसके पास कोई भी व्यवसाय है जो उपयोगकर्ता पासवर्ड जानता है। वह उपयोगकर्ता है। उनकी पत्नी / पति, उनके डॉक्टर या यहाँ तक कि उनके पुजारी भी नहीं।

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

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

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

एक अधिक सामान्य समाधान होगा:

उस बिंदु पर जहां एप्लिकेशन में पहली बार एक पासवर्ड प्राप्त होता है, पासवर्ड को हैशिंग फ़ंक्शन में पारित किया जाता है, साथ ही आप हैश फ़ंक्शन में रैंडम 'नमक' मान भी देते हैं।

मूल स्ट्रिंग को तब स्मृति में अधिलेखित कर दिया जाता है, और इस बिंदु पर, नमकीन हैश डेटाबेस में या डेटाबेस रिकॉर्ड के साथ तुलना में संग्रहीत किया जाता है।

यहां सुरक्षा प्रदान करने वाले प्रमुख पहलू हैं:

  1. हैश का ज्ञान सीधे प्रमाणीकरण प्रदान नहीं करता है।
  2. हैश से पासवर्ड की उलटी गणना अव्यावहारिक है।
  3. इंद्रधनुष तालिकाओं (पासवर्डों की लंबी सूची और उनकी गणना की गई हैश) का उपयोग अधिक चुनौतीपूर्ण है क्योंकि परिणामी हैश उपयोगकर्ता नाम और पासवर्ड दोनों पर निर्भर है।

6
सामान्य तौर पर यह उपयोगकर्ता नाम के बजाय यादृच्छिक नमक का उपयोग करना पसंद करता है।
कोडइन्चोस

वाह, शानदार कैच @CodesInChaos। मैंने ध्यान नहीं दिया कि प्रश्न के पहले पढ़ने के माध्यम से। हां, आपका नमक बेतरतीब ढंग से उत्पन्न होना चाहिए। यह MySQL में संग्रहीत कुछ पागल बूँद नहीं है (और यह बुरा होगा क्योंकि तब यह पोर्टेबल नहीं होगा)। अन्यथा, +1 यह कहने के लिए कि केवल उपयोगकर्ता को उपयोगकर्ता का पासवर्ड पता होना चाहिए।
नोबल उत्थान

ठीक है, आवेदन का सुझाव देने के लिए अद्यतन उत्तर का अपना यादृच्छिक नमक मूल्य है।
माइकल शॉ

4
नहीं, आवेदन में नमक मूल्य भी नहीं है। प्रत्येक संग्रहीत हैश के लिए एक अलग, दृढ़ता से यादृच्छिक, नमक मूल्य होना चाहिए। (आप उस हैश के साथ नमक स्टोर करते हैं।) यही सांख्यिकीय हमलों से बचाता है। यदि आपने पूरे एप्लिकेशन के लिए एक ही हैश का उपयोग किया है, तो समान प्लेटेक्स्ट समान मूल्य पर हैश करता है। यह हैश के रूप में उपयोगकर्ता नाम का उपयोग करने से कहीं अधिक खराब है।
बेन वोइग्ट

यह एक वेब सेवा नहीं है, लेकिन SSH कीपर प्रमाणीकरण 'शुद्ध' समाधान का उपयोग करता है, जहां सर्वर एक सार्वजनिक कुंजी संग्रहीत करता है और उपयोगकर्ता एक निजी कुंजी के साथ प्रमाणित करता है।
cpast

10

आपको "एन्क्रिप्ट" (वास्तव में, "हैश", हैशिंग की एक उचित धारणा के लिए) पासवर्ड को रक्षा की दूसरी परत के रूप में उपयोग करने की आवश्यकता है: इसका मतलब एक हमलावर को रोकने के लिए है, जिसे डेटाबेस से केवल-पढ़ने की झलक मिली, एस्केलेटिंग से रीड-राइट एक्सेस में और, ठीक है, डेटा को बदलने के लिए शुरू करते हैं। रीड-ओनली एक्सेस वाले खाते से कुछ SQL इंजेक्शन के हमले के माध्यम से, या डंपस्टर से एक पुराने हार्ड डिस्क या पुराने बैकअप टेप को पुनः प्राप्त करके वास्तविक दुनिया में केवल-आंशिक उल्लंघन होते हैं। मैंने वहां इस विषय पर लंबाई में लिखा है ।

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


एन्क्रिप्शन और हैशिंग के बीच अंतर जानने के लिए +1।
नोबल उत्थान

8

मैं यह नहीं दोहराऊंगा कि दूसरे लोगों ने क्या कहा है, लेकिन यह मानते हुए कि आपके पास PHP 5.3.8 या बेहतर है, आपको bcryptअपने पासवर्ड को संग्रहीत करने के लिए PHP देशी का उपयोग करना चाहिए । यह PHP में बनाया गया है। यदि आपके पास PHP 5.5 है, तो आप सबसे अच्छा उपलब्ध पासवर्ड स्थिरांक का उपयोग कर सकते हैं। आप 5.3 की तरह एक पुस्तकालय का उपयोग कर सकते हैं या 5.5 की तरह बेहतर व्यवहार कर सकते हैं।

स्टैक ओवरफ्लो प्रश्न आप PHP में हैशिंग पासवर्ड के लिए bcrypt का उपयोग कैसे करते हैं? इसे समझाता है, और अन्य जवाब वहाँ अधिक समझाते हैं। कृपया अपने आप को ऐसा करने के लिए प्रयास न करें।


2
दुर्भाग्य से, मैं PHP 5.3.3 का उपयोग कर रहा हूं, इसलिए आपके सुझाव लागू नहीं होंगे
phpmysqlguy

4
उन्नयन का 5.3.3 से 5.3.8 है?
gbjbaanb

रेड हैट पर कोई मौका? क्योंकि उन्होंने bcrypt करने के लिए ठीक किया है। यदि नहीं, तो ब्रिप्ट के बजाय SHA256 का उपयोग करें।
एलिन

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

एक चीज़ जो मैं जोड़ूंगा वह है कि php 5.5+ में password_hash () फ़ंक्शन के बारे में अच्छी बात यह है कि यह सैल्टिंग को हैंडल करता है और इसलिए डिफ़ॉल्ट रूप से। इससे पहले आपको आगे बढ़ने की आवश्यकता है और ircmaxell की लाइब्रेरी जैसी किसी चीज़ का उपयोग करना चाहिए जो इसे वापस भेजती है (उसने 5.5 कार्यान्वयन लिखा है)। यह मत मानो कि आप अपने आप से एक यादृच्छिक नमक उत्पन्न कर सकते हैं। यह विशेषज्ञों के लिए बहुत कठिन और सर्वोत्तम है; यादृच्छिक रूप से प्राप्त करना वास्तव में आसान है लेकिन समान परिणाम नहीं हैं जो शोषक हैं।
एलिन

7

मैं उस उत्तर में बताए गए कारणों के लिए pdr के उत्तर से सहमत हूं।

मैं निम्नलिखित जोड़ूंगा: आपको यह करना चाहिए क्योंकि यह करना आसान है और आमतौर पर किसी भी आवेदन के लिए सर्वोत्तम अभ्यास के रूप में स्वीकार किया जाता है। अधिक विशेष रूप से, पासवर्ड हमेशा नमकीन होना चाहिए और किसी भी स्थिर भंडारण पर लिखने से पहले हैशेड होना चाहिए । यहाँ एक अच्छा क्रिप्टोग्राफ़िक हैश चुनने (और कई लोकप्रिय भाषाओं में मुफ्त स्रोत कोड प्रदान करने) के महत्व पर एक अच्छा संदर्भ है: https://crackstation.net/hashing-security.htm

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


नमस्कार, और हैशिंग दोनों का उल्लेख करने के लिए +1, साथ ही एन्क्रिप्शन का उल्लेख नहीं करना , जो इस प्रश्न में भी नहीं है।
नोबल उत्थान

2

मैं जिस परिदृश्य के बारे में सोच सकता हूं, वह यह है कि आपको हैक किया गया है।

एक और परिदृश्य जो आपको सोचने की जरूरत है: किसी ने आपके डीबीए (या जो कोई भी आपके DB पर चुनिंदा क्वेरी चला सकता है) को $ 100, उन्हें उपयोगकर्ताओं के पासवर्ड देने के लिए पर्ची दी। या सामाजिक इंजीनियरों को ऐसा करने के लिए कुछ इंटर्न।

फिर वे उन पासवर्ड का उपयोग उपयोगकर्ता के जीमेल ... या वाणिज्य साइट में लॉग इन करने के लिए करते हैं ... (क्योंकि लोग हैं ... स्मार्ट से कम हम कहेंगे - और साइटों पर समान पासवर्ड का उपयोग करें)।

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


NOBODY (आपकी कंपनी के लोगों सहित) को सादा पाठ पासवर्ड पढ़ने में सक्षम होना चाहिए। कभी। उसके लिए कोई वैध व्यवसाय या तकनीकी आवश्यकता नहीं है।


2

एक के लिए, यहां तक ​​कि डेटाबेस प्रशासक को उपयोगकर्ताओं के पासवर्ड नहीं देखना चाहिए। यदि व्यवस्थापक पासवर्ड देखने और अपने उपयोगकर्ताओं के खाते में लॉगिन करने का निर्णय लेते हैं, तो उन्हें रोकना इसको रोक देगा।


1
यह कुछ भी योग्य नहीं है जो पहले से ही पहले जवाब में पोस्ट किया गया था
gnat

3
+1। उन्होंने वास्तव में कहा कि "हैशिंग", एन्क्रिप्शन के बजाय कई अन्य हैं। इसके अलावा, उन्होंने सीधे ओपी का खंडन किया जिन्होंने कहा कि वह चाहते थे कि पासवर्ड सादा उपयोगकर्ता अन्य उपयोगकर्ताओं के खातों में लॉग इन करे।
नोबल उत्थान

0

खैर, यह आश्चर्यजनक है कि किसी ने भी इसका उल्लेख नहीं किया है, फिर भी, लेकिन आपके डेटाबेस की PHYSICAL सुरक्षा के बारे में क्या ?

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

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

क्या होता है जब आपका आईटी विभाग पुराने डीबी ड्राइव को मिटा देना भूल जाता है जो आपके डीबी को आयोजित करते हैं जब वे पुराने ड्राइव को इंटर्न को "सौंपने" से पहले अनुसूचित प्रतिस्थापन करते हैं, और फिर उनके डॉर्म रूममेट पाते हैं कि क्या पीछे रह गया था, और यह पता लगा सकते हैं " बेचने "यह और कभी नहीं यह उन्हें वापस पता लगाया है?

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

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


-1

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


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

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

1
@RemcoGerlich मुख्य अवधारणा एक नॉन के रूप में जानी जाती है जिसका उपयोग रिप्ले हमले से बचने के लिए किया जाता है ।

-1

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

यदि उपयोगकर्ता नाम / पासवर्ड लोगों के एक समूह द्वारा जाना जाता है, तो यह किसी व्यक्ति की असमान रूप से पहचान करने के लिए बेकार हो जाता है , और यह पहचान की चोरी, धोखाधड़ी के लिए कई संभावित परिदृश्य बनाता है ...

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


2
असममित एन्क्रिप्शन का उपयोग करके पासवर्ड कौन संग्रहीत करता है? यह सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी है, जिसका अर्थ है कि मैं अपना पासवर्ड एन्क्रिप्ट करने के बाद भी, इसे डिक्रिप्ट किया जा सकता है और पढ़ सकता है यदि कोई व्यक्ति कभी भी अपनी निजी कुंजी प्राप्त करता है। हैशिंग के साथ, मुझे और केवल मुझे अपना पासवर्ड पता है (जब तक कि मैं इसे लिखकर या पासवर्ड मैनेजर में नहीं डालूं, जहां यह वास्तव में असममित एन्क्रिप्शन है)।
नोबल अपलिफ्ट

कृपया, सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी के लिए विकिपीडिया पृष्ठ देखें: en.wikipedia.org/wiki/Public-key_cryptography "सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी, जिसे असममित क्रिप्टोग्राफ़ी के रूप में भी जाना जाता है,"
अल्फा 1983 19

2
... हां, मैंने ऐसा कहा using asymmetric encryption? That's public-key cryptography। तुम्हारा मतलब क्या है?
नोबल उत्थान

-1

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

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


1
यह 14 से अधिक पूर्व के उत्तर में कुछ भी पर्याप्त नहीं लगता है
gnat

मैं असहमत हूं अन्यथा मैंने इसे पोस्ट नहीं किया होता। मुझे यकीन नहीं है कि मैं देख रहा हूं कि नकारात्मक टिप्पणी करने के बारे में आपकी बातचीत में क्या होता है, हालांकि, लोगों को भाग लेने के लिए हतोत्साहित करने से अलग।
लोबाती

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

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

"मान लें कि आपको हैक किया जाएगा " - इस तरह यह 2 महीने पहले पोस्ट किए गए उत्तर में लिखा गया था
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.