मुझे नहीं पता कि उपयोगकर्ता के पासवर्ड हैश के साथ डेटा एन्क्रिप्ट करने में बहुत समझदारी है, विशेष रूप से यदि आप हैश को डेटाबेस में ही रखते हैं। उस स्थिति में जो कोई भी एन्क्रिप्टेड डेटा तक पहुंच सकता है, वह पासवर्ड हैश तक भी पहुंच सकता है और डेटा को डिक्रिप्ट कर सकता है।
एक अन्य दृष्टिकोण कुछ उपयोगकर्ता-विशिष्ट डेटा के साथ नमकीन एप्लिकेशन-विशिष्ट कुंजी के साथ डेटा को एन्क्रिप्ट करना होगा। हालांकि, फिर आपको एक और समस्या का सामना करना पड़ता है:एप्लिकेशन कुंजी को सुरक्षित रूप से कैसे स्टोर करें। उस प्रश्न के लिए मुझे एक आसान उत्तर नहीं पता है, लेकिन इसे अपने स्रोत कोड में रखना शायद काफी अच्छा है यदि आपको डर है कि आपके डेटाबेस डेटा से समझौता किया जा सकता है, लेकिन स्रोत कोड स्वयं नहीं, उदा। यदि आपका डेटाबेस ऑफ-साइट संग्रहीत है (अमेज़न S3 सोचें)।
यदि आप डेटाबेस में केवल पासवर्ड का हैश रखते हैं, तो उपयोगकर्ता के पासवर्ड के साथ ऐप कुंजी को नमकीन करने में मदद मिलती है, लेकिन एक और सुरक्षा दोष पेश कर सकता है:आपको एप्लिकेशन सत्र में उपयोगकर्ता के पासवर्ड को स्पष्ट टेक्स्ट में रखना होगा।
तकनीकी समाधान के लिए, यह काफी सरल है और नमूना कोड उपलब्ध है . पासवर्ड हैश के साथ नमकीन एप्लिकेशन पासवर्ड के साथ डेटा को एन्क्रिप्ट करने के लिए आप इसे निम्नानुसार संशोधित कर सकते हैं:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
किसी भी मामले में आपको अपना एप्लिकेशन पासवर्ड कहीं स्टोर करना होगा, इसलिए मुझे नहीं लगता कि कोई आसान तरीका है जो पूर्ण सुरक्षा प्रदान करता है।
एक और तरीका जिसके बारे में मैं सोच सकता हूं कि उपयोगकर्ता से एक छोटा पिन मांगना है जिसे आप एन्क्रिप्शन कुंजी के रूप में उपयोग कर सकते हैं। पिन डेटाबेस में संग्रहीत नहीं किया जाएगा, लेकिन हर बार जब आप उनका डेटा एक्सेस करते हैं तो आपको उपयोगकर्ता से इसके लिए पूछना होगा।
और निश्चित रूप से आपको एन्क्रिप्शन की व्यवहार्यता के बारे में सोचना होगा। आप डिक्रिप्शन के बिना इसे इंडेक्स या सर्च नहीं कर पाएंगे। यह शायद डेटा के सीमित सेट (जैसे क्रेडिट कार्ड नंबर) के लिए आवश्यक है, लेकिन मैं इसके साथ बहुत दूर नहीं जाऊंगा।
