विंडोज .NET या ASP.NET अनुप्रयोगों का उपयोग करते समय डीबी पासवर्ड स्टोर करने के लिए कहां

Question

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

.NET में, आप पासवर्ड को हार्डकोड नहीं कर सकते क्योंकि आप .NET कोड को संकुचित कर सकते हैं।

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

आप App.Config और Web.Config को एन्क्रिप्ट कर सकते हैं, लेकिन मेरा मानना ​​है कि निजी क्षेत्र उपयोगकर्ता कुंजी को एक्सेस कर सकते हैं।

मुझे लगता है कि आप डीपीएपीआई के साथ एक ही समस्या में भाग लेते हैं।

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

Answer 1

आप असेंबली में पासवर्ड स्टोर नहीं करना चाहते हैं, और पहिया को फिर से शुरू करने से केवल अधिक परेशानी होती है (और अधिक भेद्यताएं उत्पन्न होती हैं) इसके लायक है। यदि आप डेटाबेस और वेब सर्वर दोनों पर एमएस प्लेटफ़ॉर्म का उपयोग कर रहे हैं, तो इसे संभालने का सबसे आसान तरीका use a trusted connection है, और आपके एप्लिकेशन का उपयोग करने वाले पहचान के लिए SQL सर्वर पर अधिकार प्रदान करें।

दूसरा, मैं केवल let DPAPI do its job to encrypt your connection settings होगा।

Answer 2

यहां कुछ विकल्प हैं।

1. स्टोर उन्हें है कि एक उत्पन्न बीज के साथ एन्क्रिप्टेड है एक बाहरी फ़ाइल में
2. स्टोर उन्हें एन्क्रिप्टेड कॉन्फ़िग फ़ाइल में। इस बेस बीज को स्टोर करने वाले कोड को नाराज करें या इसे एक सी ++ डीएल में संग्रहित करें (डिकंपाइल करने के लिए कठोर)।

Answer 3

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

Answer 4

आप अपने डेटा की रक्षा के लिए .नेट फ्रेमवर्क के निम्न विधियों का उपयोग कर सकते हैं, वे आंतरिक रूप से DPAPI का उपयोग अपने डेटा की रक्षा करने के लिए, और आप सीधे C# या VB में उन्हें इस्तेमाल कर सकते हैं।प्रणाली DLL कॉल के साथ बेला के आसपास बिना नेट:

namespace System.Security.Cryptography 
{ 
    // Summary: 
    //  Provides methods for protecting and unprotecting data. This class cannot 
    //  be inherited. 
    public sealed class ProtectedData 
    { 
     public static byte[] Protect(byte[] userData, 
      byte[] optionalEntropy, DataProtectionScope scope); 
     public static byte[] Unprotect(byte[] encryptedData, 
      byte[] optionalEntropy, DataProtectionScope scope); 
    } 
} 

इसके इस्तेमाल के लिये अपनी परियोजना के संदर्भ System.Security जोड़ें। मैं आपके संरक्षित डेटा में एक SALT जोड़ने के लिए बाइट सरणी optionalEntropy का उपयोग करने की दृढ़ता से अनुशंसा करता हूं (बाइट सरणी में कुछ यादृच्छिक मान जोड़ें जो आपके द्वारा संरक्षित डेटा के लिए अद्वितीय हैं)।

scope के लिए आप DataProtectionScope.CurrentUser का उपयोग कर सकते हैं, जो वर्तमान उपयोगकर्ता के प्रमाण-पत्रों के साथ डेटा को एन्क्रिप्ट करेगा।

कुछ परिदृश्यों में, DataProtectionScope.LocalMachine भी उपयोगी है। इस मामले में, संरक्षित डेटा मशीन संदर्भ से जुड़ा हुआ है। इस सेटिंग के साथ कंप्यूटर पर चल रही कोई भी प्रक्रिया डेटा को असुरक्षित कर सकती है। यह आम तौर पर सर्वर-विशिष्ट अनुप्रयोगों में उपयोग किया जाता है जो सर्वर पर चलते हैं जहां अविश्वसनीय उपयोगकर्ताओं तक पहुंच की अनुमति नहीं है।

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

इन तरीकों के बारे में अधिक MSDN पर यहां पाया जा सकता:

• Windows data protection - DPAPI कार्यक्षमता के बारे में सामान्य जानकारी,
• Protected data class - ProtectedData वर्ग के विनिर्देश,
• Protect method - के उपयोग के बारे में वर्णन Protect विधि

कोड नमूने और मामले में आप अनुप्रयोगों .config फ़ाइल के कुछ हिस्सों को एनक्रिप्ट में रुचि रखते हैं, इस की जाँच:

• Encrypt passwords in config - लेख जो वेब/app.config

मैं उपयोग करने के लिए आप की सिफारिश के कुछ हिस्सों एन्क्रिप्ट करने का तरीका बताते हैं एक एसएएलटी (यानी optionalEntropy पैरामीटर का उपयोग करके) - यह इंद्रधनुष तालिका हमलों के खिलाफ सुरक्षा करता है।

---

DPAPI समाधान में से एक दोष यह है मैं उल्लेख करना चाहते हैं नहीं है: कुंजी आपके Windows क्रेडेंशियल्स, जिसका अर्थ है जो कोई भी अपने Windows क्रेडेंशियल्स की पहुंच है के आधार पर उत्पन्न होता है संभवतः सुरक्षित डेटा के उपयोग है। आपके खाते के अंतर्गत चलने वाला एक प्रोग्राम संरक्षित डेटा तक भी पहुंच सकता है।