2011-10-07 13 views
8

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

मैं, मूल उपयोगकर्ता, उपयोगकर्ताओं की सामग्री, अवधि तक पहुंच नहीं लेना चाहता हूं।

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

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

ऐसा कर रहा है कि उपयोगकर्ता केवल मेरे सर्वर (और यहां तक ​​कि मुझे भी) पर अपनी सामग्री तक पहुंच नहीं सकता है?

+0

मुझे आश्चर्य है कि hushmail.com यह कैसे करता है। – SQLMason

+0

यहां उनके एन्क्रिप्शन पर एक श्वेत पत्र है: http://www.hushmail.com/public_documents/Hush%20Encryption%20Engine%20White%20Paper.pdf –

+0

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

उत्तर

11

प्रक्रिया:

  1. एक यादृच्छिक गुप्त उनकी सामग्री एन्क्रिप्ट करने के लिए उत्पन्न करें।
  2. उनके प्रदत्त पासवर्ड का उपयोग करके # 1 से यादृच्छिक रहस्य एन्क्रिप्ट करें।
  3. अपना पासवर्ड एक तरफा हैश (नमक, शायद बहु-हैश के रूप में) के रूप में स्टोर करें।

पासवर्ड परिवर्तन की स्थिति:

  1. पुन: उत्पन्न चरण # 2 से मूल्य।
  2. चरण # 3 से हैश-कैश पुन: उत्पन्न करें।

लॉग इन करने पर :

  1. हैश पासवर्ड और # 3 चरण में बनाया गया हैश के खिलाफ जाँच करें।
  2. यदि पासवर्ड मिलान करता है - वास्तविक प्रदान किया गया पासवर्ड # 2 से यादृच्छिक रहस्य डिक्रिप्ट करने के लिए।
  3. # 1 में एन्क्रिप्टेड डेटा अनलॉक करने के लिए # 2 से यादृच्छिक रहस्य का उपयोग करें।

नोट्स:

  • कोई भी यादृच्छिक रहस्य जानने के बिना डेटा को डिकोड कर सकते हैं (# 1)। यादृच्छिक रहस्य केवल उपयोगकर्ता के वास्तविक पासवर्ड (# 2) (ब्रूट-बल से कम) के साथ अनलॉक किया जा सकता है। उपयोगकर्ता का वास्तविक पासवर्ड केवल एक तरफा हैश फॉर्म (# 3) में जाना जाता है ताकि आप इसकी पुष्टि कर सकें, लेकिन इसे डीकोड नहीं कर सकता और # 2 पुनर्प्राप्त नहीं कर सकता।
  • एक भूल गई पासवर्ड प्रक्रिया संभव नहीं है (आप # 3 को पुन: उत्पन्न कर सकते हैं, लेकिन # 2 में यादृच्छिक कुंजी अब खो गई है क्योंकि सब कुछ उनके वॉल्ट में बंद है)।
  • प्रत्येक बार जब वे अपना पासवर्ड बदलते हैं, तो केवल # (2) से केवल (सरल/त्वरित) यादृच्छिक रहस्य को बदलने के लिए आपको चरण # 1 में सबकुछ फिर से एन्क्रिप्ट नहीं करना पड़ता है।
  • यदि आप उनके प्रदत्त पासवर्ड को कैश करते हैं, या चरण 1 पर उत्पन्न यादृच्छिक रहस्य, या उनकी (डिक्रिप्ट) सामग्री कहीं भी आप डेटा लीक का कारण बन सकते हैं।
+1

आपने इसे जेनरेट किया है, लेकिन जब तक आप इसे स्टोर नहीं करते हैं - नहीं। इसे समझने का एकमात्र तरीका यह है कि एन्क्रिप्टेड फॉर्म को # 2 से डीकोड करने के लिए अपना पासवर्ड रखना है। या ब्रूट फोर्स के माध्यम से;) आप इस चरण में अपने पासवर्ड से हैश का उपयोग कर सकते हैं लेकिन आप * आपके द्वारा स्टोर किए गए हैंडहेड फॉर्म का उपयोग नहीं कर सकते हैं (अन्यथा हाँ- आप इसे अपना पासवर्ड जानने के बिना इसे डीकोड कर सकते हैं) – Rudu

+0

क्षमा करें, मैंने अपनी टिप्पणी हटा दी क्योंकि मैंने एक सवाल पूछा जिसे मैंने जवाब दिया था कि मैंने आपकी पोस्ट को और अधिक बारीकी से पढ़ा था। मुझे आपका विचार पसंद है। –

+0

क्या यादृच्छिक गुप्त क्लाइंट पक्ष उत्पन्न करना संभव नहीं है? इस तरह आप वास्तव में सुनिश्चित करते हैं कि आपको गुप्त –

-1

आप इस बात पर हैं कि आपको एक कुंजी के रूप में अपने पासवर्ड का उपयोग करने की आवश्यकता है।

मैं ecryptfs के साथ बंदर नहीं होगा क्योंकि एक एन्क्रिप्टेड फ़ाइल सिस्टम सबसे अच्छा समाधान नहीं है। आप नहीं चाहते कि एक उपयोगकर्ता का डेटा उसी कुंजी के साथ एन्क्रिप्ट किया जाए जो किसी अन्य उपयोगकर्ता ने उपयोग किया हो।

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

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

आप अपने डेटाबेस में नमक मान को अनएन्क्रिप्टेड स्टोर कर सकते हैं।

+1

eCryptfs के साथ, प्रत्येक उपयोगकर्ता का डेटा अपनी कुंजी के साथ एन्क्रिप्ट किया जा सकता है। –

संबंधित मुद्दे

 संबंधित मुद्दे