मैं अपने डेटाबेस में किसी तृतीय पक्ष webservice पर पासवर्ड सुरक्षित रूप से कैसे संग्रहीत करूं?

Question

मुझे हमारे कॉन्फ़िगरेशन डेटाबेस में एक तृतीय-पक्ष पासवर्ड स्टोर करने की आवश्यकता है, इसलिए उपयोगकर्ता हमारी लॉगिन जानकारी को उस वेब सेवा के लिए सहेज सकता है जिसे हमारे सर्वर के माध्यम से एक्सेस किया जा सकता है।

मुझे वेब सेवा में पासवर्ड पास करने की ज़रूरत है, इसलिए मैं सिर्फ पासवर्ड नहीं है और हैश स्टोर कर सकता हूं। मुझे सेवा भेजने के लिए वास्तविक पासवर्ड प्राप्त करने में सक्षम होना चाहिए।

सुरक्षा कारणों से, मैं उस पासवर्ड को एन्क्रिप्ट करना चाहता हूं जिसे हम डेटाबेस में संग्रहीत कर रहे हैं। ऐसा लगता है कि पासवर्ड एन्क्रिप्ट करने के बारे में मैं जो कुछ भी देखता हूं, वह कहता है "हैश, इसे एन्क्रिप्ट न करें!" लेकिन मुझे नहीं लगता कि इस मामले में लागू होता है।

मैं सोच रहा हूँ अगर यह VB.NET कोड में एन्क्रिप्शन/डिक्रिप्शन संभाल या SQL सर्वर का उपयोग यह पूरा करने के लिए (से मैं क्या here देखते हैं, यह एसक्यूएल में यह करने के लिए कम से कम संभव है करने के लिए बेहतर है, लेकिन मैं मुझे यकीन नहीं है कि क्या यह समझ में आता है। मुझे यह पता लगाने के लिए और अधिक शोध करना होगा कि तैनाती के मुद्दे क्या होंगे)।

Answer 1

मैं जॉर्ज स्टॉकर से सहमत हूं। यदि आप मौजूदा प्रोटोकॉल का उपयोग कर सकते हैं - इसके साथ जाएं (इससे संभावित मुद्दों और सुरक्षा भेद्यता दस गुना कम हो जाएगी)।

बस मामले में, यदि आप विकल्प से बाहर हैं (किसी प्रोटोकॉल का उपयोग नहीं कर सकते हैं)। आप केवल किसी उपयोगकर्ता द्वारा अपने सर्वर पर कुछ करता है 3 पार्टी वेबसर्वर का उपयोग करने की जरूरत है, मैं निम्नलिखित की सिफारिश करेंगे:

• अपने डीबी

• में पासवर्ड की दुकान मत करो के लिए एक पासवर्ड के साथ कुकी बनाएं तृतीय पक्ष सेवा और कुछ गुप्त कुंजी के साथ एन्क्रिप्ट करें। इस कुकी को किसी उपयोगकर्ता को वापस भेजें।

• जैसे ही उपयोगकर्ता आपकी वेबसाइट पर वापस आ जाता है, आपको कुकीज़ मिल जाएगी, इसे डिक्रिप्ट करेंगी, कुकी से पासवर्ड प्राप्त करें और तृतीय पक्ष webservice तक पहुंचने के लिए इसका उपयोग करें।

तो, मामले में, अगर किसी को अपने सर्वर को हैक जाएगा और डेटाबेस की प्रतिलिपि बनाएगा, वे 3 पार्टी webservices के लिए पासवर्ड की जरूरत नहीं होगी। मामले में, अगर कोई उपयोगकर्ता कंप्यूटर को हैक कर देगा, तो सभी कुकीज़ एन्क्रिप्ट की गई हैं, इसलिए वे उनके साथ कुछ भी करने में सक्षम नहीं होंगे।

इसकी एकमात्र सुरक्षा कमजोरी, अगर कोई आपके सर्वर में कुछ कोड इंजेक्ट करने में सक्षम होगा और सक्रिय उपयोगकर्ता सत्रों से पासवर्ड कैप्चर करेगा।

Answer 2

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

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

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