उपयोगकर्ता की जानकारी और उपयोगकर्ता लॉगिन और पासवर्ड को सबसे अच्छी तरह से स्टोर करने के लिए कैसे करें

Question

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

नोट: मेरी पोस्ट को स्पष्ट करने के लिए, मैं पासवर्ड (हैश, नमक, आदि) को सुरक्षित करने की तकनीक को समझता हूं। मुझे बस पता है कि अगर मैं अपने जीवन के अन्य हिस्सों (निवेश, डेटा बैकअप, यहां तक ​​कि व्यक्तिगत भंडारण) से प्रथाओं का पालन कर रहा हूं, जो कि सबसे बुरी स्थिति परिदृश्य (तालिका या आग) में है, जिसमें तालिकाओं के बीच विभाजित जानकारी आपकी सुरक्षा की क्षमता प्रदान करती है अतिरिक्त डेटा।

Answer 1

पासवर्ड संग्रह न करें। यदि यह कभी डिस्क पर बैठा है, तो इसे चोरी किया जा सकता है। इसके बजाय, पासवर्ड हैश स्टोर करें। Use the right hashing algorithm, जैसे bcrypt (जिसमें नमक शामिल है)।

EDIT: ओपी ने जवाब दिया है कि वह उपर्युक्त मुद्दे को समझता है।

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

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

Answer 2

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

Answer 3

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

Answer 4

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

मैं ज्यादातर समय कहेंगे मैं एक एकल तालिका में कुछ इस तरह करते हैं:

UserID, FirstName, LastName, Email, Password, TempPassword 

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

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

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

Answer 5

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

यदि आप की दुकान चाहिए साख:

• एक प्रतिवर्ती प्रपत्र की दुकान मत करो; SHA-256 जैसे मान्यता प्राप्त एल्गोरिदम का उपयोग करके हैश स्टोर करें। एक प्रतिष्ठित भरोसेमंद स्रोत से क्रिप्टोग्राफ़िक सॉफ़्टवेयर का उपयोग करें - अपने आप को घुमाने के लिए प्रयास न करें, आपको यह भी गलत लगेगा।
• प्रत्येक क्रेडेंशियल सेट के लिए, हैश डेटा के साथ एक नमक स्टोर करें; इसका उपयोग हैश को "प्राइम" करने के लिए किया जाता है जैसे कि दो समान पासवर्ड समान हैश उत्पन्न नहीं करते हैं - क्योंकि यह बताता है कि पासवर्ड समान हैं।
• एक सुरक्षित यादृच्छिक जनरेटर का उपयोग करें। कमजोर यादृच्छिकता एन्क्रिप्शन से संबंधित सुरक्षा विफलताओं का नंबर एक कारण है, सिफर एल्गोरिदम नहीं।

आप प्रतिवर्ती साख की दुकान चाहिए:

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

Answer 6

पासवर्ड को क्रिप्टोग्राफ़िक हैश के रूप में संग्रहीत किया जाना चाहिए, जो एक गैर-परिवर्तनीय ऑपरेशन है जो सादे पाठ को पढ़ने से रोकता है। उपयोगकर्ताओं को प्रमाणीकृत करते समय, पासवर्ड इनपुट उसी हैशिंग प्रक्रिया और हैश की तुलना में किया जाता है।

एक तेज़ और सस्ता हैश जैसे एमडी 5 या SHA1 के उपयोग से बचें; उद्देश्य एक हमलावर के लिए इंद्रधनुष सारणी (हैश टकराव के आधार पर) की गणना करने के लिए महंगा बनाना है; एक तेज़ हैश इसका विरोध करता है। एक महंगा हैश का उपयोग प्रमाणीकरण परिदृश्यों में कोई समस्या नहीं है, क्योंकि इसका हैश के एक रन पर कोई प्रभाव नहीं पड़ेगा।

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

आपका पासवर्ड हैश कॉलम निश्चित लंबाई हो सकता है; आपके क्रिप्टोग्राफिक हैश को आउटपुट मान चाहिए जो निश्चित लंबाई में एन्कोड किया जा सकता है, जो सभी हैंश के लिए समान होगा।

जहां भी संभव हो, अपना पासवर्ड प्रमाणीकरण तंत्र रोलिंग से बचें; मौजूदा समाधान का उपयोग करें, जैसे bcrypt।

पासवर्ड को संभालने का तरीका और आपको अपनी चिंता करने की आवश्यकता के बारे में एक उत्कृष्ट स्पष्टीकरण http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes पर पाया जा सकता है।

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

Answer 7

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

हालांकि, ध्यान दें कि यह अधिक प्रश्न करने की आवश्यकता के खर्च पर आ सकता है, इसलिए प्रदर्शन प्रदर्शन हुआ।

Answer 8

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