सबसे अच्छा तरीका डेटाबेस

Question

मैं एक परियोजना प्रमाणीकरण नहीं है पर काम कर रहा हूँ में पासवर्ड स्टोर करने के लिए (उपयोगकर्ता नाम/पारित)

यह भी एक डेटाबेस से कनेक्ट करता है तो मैं मैं वहाँ उपयोगकर्ता नाम और पासवर्ड संग्रहीत करेंगे लगा लेकिन ऐसा लगता है कि डीबी

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

Answer 1

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

• How to best store user information and user login and password
• Best practices for storing database passwords
:

तो, जबकि यह एक अच्छी बात है कि आप इस बारे में सोच रहे है और यह एक अच्छा सवाल है, यह वास्तव में इन सवालों (कम से कम) का डुप्लिकेट है

• Salting Your Password: Best Practices?
• Is it ever ok to store password in plain text in a php variable or php constant?

clari करने के लिए नमक बिट पर थोड़ी देर के लिए, पासवर्ड को आसानी से धोने के साथ खतरा और यह संग्रह करना है कि अगर एक अपराधी को आपके डेटाबेस को पकड़ लिया जाता है, तो वे अभी भी पासवर्ड का "डिक्रिप्ट" करने में सक्षम होने के लिए rainbow tables के रूप में जाने जाते हैं। कम से कम जो इंद्रधनुष तालिका में दिखाई देते हैं)। इसके आस-पास पहुंचने के लिए, डेवलपर्स salt को पासवर्ड में जोड़ते हैं, जो सही तरीके से किए जाने पर इंद्रधनुष के हमलों को आसानी से करने में असमर्थ बनाता है। ध्यान दें कि एक आम गलतफहमी बस सभी पासवर्डों के लिए एक ही अद्वितीय और लंबी स्ट्रिंग जोड़ना है; जबकि यह भयानक नहीं है, हर पासवर्ड में अद्वितीय लवण जोड़ने के लिए सबसे अच्छा है। Read this for more.

Answer 2

(मैं विचार है कि इस जानकारी DB में जमा नहीं किया जा एक अच्छा कारण प्रदान किया जा सकता है, तो के लिए खुला रहा हूँ) मैं करूंगा MD5/SHA1 पासवर्ड अगर आप उल्टा करने के लिए सक्षम होने के लिए की जरूरत नहीं है हैश जब उपयोगकर्ता लॉगिन करते हैं, तो आप केवल दिए गए पासवर्ड को एन्क्रिप्ट कर सकते हैं और इसे हैश से तुलना कर सकते हैं। इस मामले में हैश टकराव लगभग असंभव हैं, जब तक कि किसी को डेटाबेस तक पहुंच प्राप्त न हो और एक हैश को देख सकें, उनके पास पहले से ही टकराव है।

Answer 3

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

सब कुछ इस प्रयोजनों के लिए, asp.net membership

Answer 4

शा -512 जैसे सुरक्षित एल्गोरिदम का उपयोग करके, एक महत्वपूर्ण कठोर नमकीन हैश के रूप में।

Answer 5

सबसे अच्छा सुरक्षा अभ्यास पासवर्ड को स्टोर नहीं करना है (एन्क्रिप्टेड भी नहीं), लेकिन एन्क्रिप्टेड पासवर्ड के नमकीन हैश (पासवर्ड प्रति अद्वितीय नमक के साथ) को स्टोर करने के लिए।

इस तरह यह एक सादा टेक्स्ट पासवर्ड पुनर्प्राप्त करना असंभव है (व्यावहारिक रूप से) असंभव है।

Answer 6

पृष्ठभूमि आप कभी ... वास्तव में ... उपयोगकर्ता के पासवर्ड को जानने की आवश्यकता नहीं है। आप बस एक आने वाले उपयोगकर्ता को सत्यापित करना चाहते हैं कि खाते के लिए पासवर्ड पता है।

हैश यह: एक मजबूत हैश फ़ंक्शन के माध्यम से उपयोगकर्ता पासवर्ड हैश (एक तरफा एन्क्रिप्शन) स्टोर करें। "सी # एन्क्रिप्ट पासवर्ड" की खोज उदाहरणों का एक भार देती है।

हैश फ़ंक्शन का उत्पादन करने के विचार के लिए online SHA1 hash creator देखें (लेकिन SHA1 को हैश फ़ंक्शन के रूप में उपयोग न करें, SHA256 जैसे कुछ मजबूत उपयोग करें)।

अब, एक हैश किए गए पासवर्ड का अर्थ है कि आप (और डेटाबेस चोर) उस हैश को मूल पासवर्ड में वापस करने में सक्षम नहीं होना चाहिए।

इसका उपयोग कैसे करें: लेकिन, आप कहते हैं, मैं डेटाबेस में संग्रहीत इस मैश किए हुए पासवर्ड का उपयोग कैसे करूं?

जब उपयोगकर्ता लॉग इन करता है, तो वे आपको उपयोगकर्ता नाम और पासवर्ड (इसके मूल पाठ में) सौंपेंगे, आप केवल उसी हैश कोड का उपयोग हैश को संग्रहीत संस्करण प्राप्त करने के लिए टाइप किया गया है।

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

अतिरिक्त क्रेडिट:

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

उत्तर: हाँ ... हाँ वे कर सकते हैं।

तो, आपको अपने पासवर्ड 'नमक' करना चाहिए। देखें Wikipedia article on salt

देखें "How to hash data with salt" C# example

Answer 7

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

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

यह उपयुक्त नहीं हो सकता है, तो सवाल में आवेदन आंतरिक उपयोग के लिए विशुद्ध रूप से है, हालांकि

RPX एक आवेदन में OpenID समर्थन intergrate के लिए एक अच्छा आसान तरीका प्रदान करता है।

Answer 8

मैं लेख Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes [मृत लिंक, copy at the Internet Archive] और How To Safely Store A Password लेखों को पढ़ने की पूरी तरह से अनुशंसा करता हूं।

बहुत सारे कोडर, स्वयं शामिल हैं, लगता है कि वे सुरक्षा और हैशिंग को समझते हैं। अफसोस की बात है कि हम में से अधिकांश बस नहीं करते हैं।