उपयोगकर्ता खाता प्रमाणीकरण और पासवर्ड को संभालने का सबसे अच्छा तरीका

Question

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

उदाहरण:

1. डेटाबेस में उपयोगकर्ता नाम/पासवर्ड भंडारण। यह एक बुरा विचार है क्योंकि किसी भी डेटाबेस के पास पहुंचने वाले उपयोगकर्ता नाम और पासवर्ड देख सकते हैं। और इसलिए इसका इस्तेमाल करें।

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

विंडोज/* निक्स इसे कैसे संभालता है?

Answer 1

यह कई साल पहले यूनिक्स में एक आम मुद्दा था, और प्रमाणीकरण घटकों (पासवर्ड हैश, पासवर्ड हैश नमक) से उपयोगकर्ता पहचान घटकों (उपयोगकर्ता नाम, यूआईडी, खोल, पूर्ण नाम, आदि) को अलग करके हल किया गया था। पहचान घटक विश्व स्तर पर पठनीय हो सकते हैं (और वास्तव में, यदि यूआईडी को उपयोगकर्ता नामों में मैप किया जाना चाहिए), लेकिन प्रमाणीकरण घटक उपयोगकर्ताओं के लिए पहुंच योग्य नहीं होना चाहिए। किसी उपयोगकर्ता को प्रमाणीकृत करने के लिए, एक विश्वसनीय सिस्टम है जो उपयोगकर्ता नाम और पासवर्ड स्वीकार करेगा, और "प्रमाणीकृत" या "प्रमाणीकृत नहीं" का एक सरल परिणाम लौटाएगा। यह सिस्टम प्रमाणीकरण डेटाबेस तक पहुंच के साथ एकमात्र एप्लिकेशन होना चाहिए, और समय पर हमलों से बचने में मदद करने के लिए उत्तर देने से पहले यादृच्छिक समय (शायद 0.1 और 3 सेकंड के बीच) का इंतजार करना चाहिए।

Answer 2

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

Answer 3

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

यूनिक्स स्टोर एक टेक्स्ट फ़ाइल/आदि/छाया में हैश, जो केवल विशेषाधिकार प्राप्त उपयोगकर्ताओं तक पहुंच योग्य है। पासवर्ड नमक के साथ एन्क्रिप्ट किया जाता है।

Answer 4

यह एक बेहतर तरीका है, लेकिन डेटाबेस में पासवर्ड हैश को दूसरे खाते के हैश के साथ स्थानांतरित करके एक्सेस किया जा सकता है जिसे आप ऑथ जानकारी जानते हैं।

इसके आसपास वास्तव में कोई रास्ता नहीं है। कोई भी जो पासवर्ड फ़ाइल तक पहुंच लिखने के लिए कंप्यूटर का पूरा नियंत्रण रखता है।

Answer 5

आप ओपनआईडी का उपयोग कर सकते हैं और कोई गोपनीय उपयोगकर्ता पासवर्ड सहेज सकते हैं। किसने कहा कि यह केवल वेबसाइटों के लिए है?

Answer 6

मैं 2 के साथ जाऊंगा लेकिन कुछ नमक का उपयोग करूंगा। कुछ स्यूडोकोड:

SetPassword(user, password) 
    salt = RandomString() 
    hash = Hashfunction(salt+password) 
    StoreInDatabase(user, salt, hash) 

CheckPassword(user, password) 
    (salt, hash) = GetFromDatabase(user) 
    if Hashfunction(salt+password) == hash 
     return "Success" 
    else 
     return "Login Failed" 

यह एक अच्छी तरह से ज्ञात हैश फंक्शन (जैसे MD5 या SHA-1 के रूप में), एक पुस्तकालय में लागू उपयोग करने के लिए महत्वपूर्ण है। अपना खुद का रोल न करें या इसे से लागू करने का प्रयास करें, यह सिर्फ गलत होने का जोखिम नहीं है।

@ ब्रायन आर बॉन्डी: नमक का उपयोग करने का कारण यह है कि शब्दकोश को जोड़ना कठिन होता है, हमलावर एक शब्दकोश नहीं है और सभी पासवर्ड के खिलाफ प्रयास कर सकता है, इसके बजाय उसे नमक + शब्दकोश और हैश लेना पड़ता है , जो स्टोरेज आवश्यकताएं फैलता है। यदि आपके पास 1000 सबसे कमऑन पासवर्ड का एक शब्दकोश है और हैश उन्हें 16 केबी की तरह कुछ चाहिए लेकिन यदि आप दो यादृच्छिक अक्षरों को जोड़ते हैं तो आपको 62 * 62 * 16 केबी ≈ 62 एमबी मिलती है।

अन्यथा आप किसी प्रकार का One-time passwords उपयोग कर सकते हैं मैंने ओटीपीडब्ल्यू के बारे में अच्छी बातें सुनी हैं लेकिन इसका इस्तेमाल किया है।डेटाबेस में

स्टोर उपयोगकर्ता नाम, पासवर्ड हैश और ईमेल पता:

Answer 7

सामान्य दृष्टिकोण ईमेल के साथ विकल्प दो उपयोग करने के लिए है।

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

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

Answer 8

उपयोगकर्ता नाम और पासवर्ड एक साथ हैश करें। इस तरह, यदि दो उपयोगकर्ताओं के पास एक ही पासवर्ड है, तो हैश अभी भी अलग होंगे। अगर आपको लगता है कि मार्ग जाने का निर्णय

Answer 9

जेफ एटवुड, कुछ अच्छी हैशिंग के विषय में पोस्ट:

• Rainbow Hash Cracking
• You're Probably Storing Passwords Incorrectly

Answer 10

यह बहुत से अनुप्रयोगों के लिए एक गैर समस्या है क्योंकि डेटाबेस तक पहुंच प्राप्त करना शायद किसी भी हमलावर का सबसे आम लक्ष्य है। इसलिए यदि उनके पास पहले से ही डेटाबेस तक पहुंच है तो वे अभी भी एप्लिकेशन में लॉगिन क्यों करना चाहते हैं? :)

Answer 11

यदि 'प्रणाली' एक सार्वजनिक वेबसाइट RPX सबसे आम प्रदाताओं, OpenId, फेसबुक, गूगल, आदि जैसे के लिए एक लॉगिन/उपयोगकर्ता खाता सेवाओं के साथ प्रदान कर सकते हैं

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