पोस्टग्रेस्क्ल डेस एन्क्रिप्ट

क्रिप्ट और डेस पुराने सायफर हैं और इनका उपयोग नहीं किया जाना चाहिए

सादा पुराना डीईएस एक अप्रचलित एल्गोरिदम है। आप वास्तव में उपयोगी रूप से इसकी तुलना AES128 से नहीं कर सकते; यह शिकायत करने जैसा है कि SHA256 हैश MD5 हैश से बड़ा है - हाँ, यह है, लेकिन उनमें से केवल एक ही हमलावर को थोड़ी देर के लिए धीमा कर सकता है। DES को 1999 में भी व्यापक रूप से कमजोर माना जाता था और नए अनुप्रयोगों में कभी भी उपयोग नहीं किया जाना चाहिए। इसका इस्तेमाल न करें।

मुझे नहीं लगता कि एन्क्रिप्शन विधि की तलाश करना एक अच्छा विचार है जो "सबसे छोटा डेटा आकार संभव प्रदान करता है" - क्योंकि यह मूल रूप से डेस का उपयोग करके डेटा एन्क्रिप्ट करने के लिए समय की बर्बादी है। ROT13 (सीज़र साइफर) का उपयोग क्यों न करें? "एन्क्रिप्टेड" परिणाम इनपुट के आकार के समान है, अफ़सोस है कि एन्क्रिप्शन को 3 साल के बच्चे द्वारा तोड़ा जा सकता है।

क्रिप्ट एक समान विंटेज का है। पुराना UNIX क्रिप्ट हैशिंग एल्गोरिथम है ... बुजुर्ग ... और किसी भी नए आवेदन के लिए पूरी तरह से अनुपयुक्त। हैश कम से कम SHA256 होना चाहिए, वास्तव में।

क्रिप्ट एकतरफा हैश है

क्रिप्टेड डेटा को डिक्रिप्ट करने का तरीका जानने में सक्षम नहीं होने के लिए:क्रिप्ट एन्क्रिप्शन एल्गोरिथम नहीं है, यह एक क्रिप्टोग्राफ़िक हैश फ़ंक्शन है या "वन वे हैश"। संग्रहीत नमकीन पासवर्ड प्रमाणीकरण के लिए हैश, चैलेंज-प्रतिक्रिया प्रमाणीकरण में उपयोग के लिए , आदि। आप गुप्त डेटा को डिक्रिप्ट नहीं कर सकते।

आकार के साथ डील करें

एक सभ्य क्रिप्टोग्राफिक फ़ंक्शन का उपयोग करें और आकार में वृद्धि के साथ रहें। bf या aes128 सबसे कमजोर के बारे में हैं जिनका आप उचित रूप से उपयोग कर सकते हैं।

व्यक्तिगत रूप से मैं ऐप में अपना एन्क्रिप्शन/डिक्रिप्शन करना पसंद करता हूं, डीबी में नहीं। यदि यह डीबी में किया जाता है तो चाबियाँ pg_stat_statements . द्वारा प्रकट की जा सकती हैं , लॉग में log_statement . द्वारा या त्रुटियां, आदि। बेहतर है कि कुंजी कभी भी संग्रहीत डेटा के समान स्थान पर न हो।

अधिकांश प्रोग्रामिंग भाषाओं में अच्छे क्रिप्टोग्राफ़िक रूटीन होते हैं जिनका आप उपयोग कर सकते हैं।

कोई और सलाह देना मुश्किल है क्योंकि आपने वास्तव में यह नहीं बताया है कि आप क्या एन्क्रिप्ट कर रहे हैं, क्यों, आपकी आवश्यकताएं क्या हैं, खतरे क्या हैं, आदि।

पासवर्ड?

अगर आप पासवर्ड स्टोर कर रहे हैं, तो आप शायद इसे गलत कर रहे हैं।

• यदि संभव हो, तो किसी और को प्रमाणीकरण करने दें:

  • इंटरनेट के लिए OAuth या OpenID

  • इंट्रानेट के लिए SSPI, Kerberos/GSSAPI, सक्रिय निर्देशिका, LDAP बाइंड, SASL, HTTP DIGEST, आदि

• यदि आपको वास्तव में स्वयं को प्रमाणित करना है, तो पासवर्ड में नमक जोड़ें और परिणाम हैश करें। हैश और नमक को स्टोर करें। जब आपको पासवर्ड की तुलना करनी होती है, तो उपयोगकर्ता के नए प्लेनटेक्स्ट को उसी नमक से नमक करें जिसे आपने संग्रहीत हैश के लिए उपयोग किया था, नया पासवर्ड + नमक हैश करें, और देखें कि क्या हैश वही है जो आपने संग्रहीत किया है। अगर ऐसा है, तो उन्होंने सही पासवर्ड दिया है।

• आपको लगभग निश्चित रूप से क्लीयरटेक्स्ट पासवर्ड पुनर्प्राप्त करने की आवश्यकता नहीं है। इसके बजाय एक सुरक्षित पासवर्ड रीसेट लागू करें। यदि आप वास्तव में, वास्तव में, उन्हें एन्क्रिप्ट करने और कुंजी भंडारण और प्रबंधन के बारे में ध्यान से सोचने के लिए एईएस जैसे शालीनता से सुरक्षित एल्गोरिदम का उपयोग करना चाहिए। pgcrypto के साथ कुंजी संग्रहण/प्रबंधन के बारे में SO पर अन्य पोस्ट देखें।

यह भी देखें:

• पीजीपी निजी कुंजी और पासफ़्रेज़ को संग्रहीत/पुनर्प्राप्त करने की सुरक्षित विधि?