WordPress और DB में WordPress विकल्प DB में यूजरनेम और पासवर्ड कैसे स्टोर करें?


19

मैं वर्तमान में एक प्लगइन विकसित कर रहा हूं और संभावना है कि मैं इसे सार्वजनिक प्लगइन रिपॉजिटरी पर जारी करने की संभावना से अधिक कर दूंगा ताकि अन्य इसका उपयोग कर सकें।

प्लगइन एक एपीआई का उपयोग करेगा और इस एपीआई का उपयोग करने के लिए आपको एक उपयोगकर्ता नाम और पासवर्ड पारित करने की आवश्यकता है। तो मेरे प्लगइन को डेटाबेस में इन लॉगिन क्रेडेंशियल को संग्रहीत करने की आवश्यकता है। मैं इन्हें सादे पाठ में संग्रहीत नहीं करना चाहता, हालाँकि API को सादे पाठ में इनकी आवश्यकता होती है।

तो मेरा सवाल यह है कि मैं इन संवेदनशील जानकारी को कैसे संग्रहीत करूं? हाशिंग बाहर है, इसलिए इसे किसी प्रकार का एन्क्रिप्शन होना चाहिए।

वर्डप्रेस में एक अनोखी कुंजी है जिसका उपयोग किया जा सकता है जो ब्लॉग से ब्लॉग पर अलग होगा? एन्क्रिप्ट और डिक्रिप्ट करने के लिए मुझे किस php फ़ंक्शन का उपयोग करना चाहिए? मैं ऐसे कार्यों की तलाश कर रहा हूं जो सभी WP इंस्टॉल पर संभावित कार्य से अधिक होंगे।


3
यह थोड़े नायाब है। इससे कोई फर्क नहीं पड़ता है कि अगर आप प्रतिवर्ती होने की आवश्यकता है तो आप कितना एन्क्रिप्ट करते हैं। यदि WP इसे डिक्रिप्ट कर सकता है और WP से छेड़छाड़ की जाती है तो एन्क्रिप्शन कोई मायने नहीं रखता।
12

लेकिन आपके एपीआई को पासवर्ड जानने की आवश्यकता क्यों है? क्या यह पर्याप्त नहीं है अगर एपीआई जानता है कि उपयोगकर्ता पासवर्ड जानता है?
onetrickpony 13

1
@ एक चाल टट्टू - पासवर्ड को संग्रहीत करने की आवश्यकता है ताकि उपयोगकर्ता के हस्तक्षेप के बिना प्रक्रिया को स्वचालित किया जा सके।
ब्रैडी

1
@Rarst - मुझे पता है कि अगर WP से छेड़छाड़ की जाती है तो पासवर्ड हैं। मैं इसे रोक नहीं सकता। मैं क्या रोक सकता है कि अगर एक एसक्यूएल डंप प्राप्त होता है तो पासवर्ड सादे पाठ में नहीं होते हैं।
ब्रैडी

@ ब्रैडी हां, अगर केवल एसक्यूएल डंप से समझौता किया जाता है तो एन्क्रिप्शन मदद करेगा। हालाँकि मुझे ऐसे परिदृश्य की संभावना नहीं है। यदि आपके पास डेटाबेस एक्सेस है तो WP के साथ भी समझौता करना तुच्छ है।
दुर्लभ

जवाबों:


4

जब मैं पिछले उत्तरों से सहमत होता हूं, तो आपके द्वारा पूछे गए प्रश्न का उत्तर देने के लिए, जो मन में आता है वह wp-config.php के लिए इनमें से किसी एक स्थिरांक का उपयोग करना है:

परिभाषित करना ('AUTH_KEY', 'redacted');
परिभाषित करें ('SECURE_AUTH_KEY', 'redacted');
परिभाषित ('लॉगगेड_आईएन_केवाई', 'रीडैक्टेड');
परिभाषित करें ('NONCE_KEY', 'redacted');

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

एन्क्रिप्शन / डिक्रिप्शन फ़ंक्शंस के लिए - एक त्वरित Google खोज कोड के साथ निम्नलिखित सूची देता है जो बिल को फिट करने के लिए प्रकट होता है: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- एन्क्रिप्शन डिक्रिप्शन-php-कार्य /

फ़ंक्शन एन्क्रिप्शन ($ input_string, $ कुंजी) {
    $ iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = hash ('sha256', $ key, TRUE);
    वापसी base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ h_key, $ input_string, MCRYPT_MODE_ECB, $ iv));
}

फ़ंक्शन डिक्रिप्ट ($ एन्क्रिप्टेड_इनपुट_स्ट्रिंग, $ कुंजी) {
    $ iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = hash ('sha256', $ key, TRUE);
    ट्रिम (mcrypt_decrypt (MCRYPT_RIJNDAEL_256, $ h_key, base64_decode ($ एन्क्रिप्टेड_input_string), MCRYPT_MODE_ECB, $ iv));
}

यहां उपयोग किए गए एईएस एन्क्रिप्शन के कुछ दस्तावेज यहां दिए गए हैं: http://www.chilkatsoft.com/p/php_aes.asp


4

यह वास्तव में OAuth के लिए तैयार किया गया था।

से OAuth होमपेज :

सेवा प्रदाता डेवलपर्स के लिए ...

यदि आप समर्थन कर रहे हैं ...

  • वेब अनुप्रयोग
  • सर्वर-साइड एपीआई
  • मैशप

यदि आप अपने उपयोगकर्ताओं की ओर से संरक्षित डेटा संग्रहीत कर रहे हैं, तो उन्हें इसका उपयोग करने के लिए वेब पर अपने पासवर्ड नहीं फैलाने चाहिए। अपने खाता क्रेडेंशियल्स की सुरक्षा करते हुए अपने उपयोगकर्ताओं को उनके डेटा तक पहुंच प्रदान करने के लिए OAuth का उपयोग करें।

OAuth का लाभ यह है कि आपको उपयोगकर्ता के पासवर्ड को संग्रहीत करने की आवश्यकता नहीं है। जब वे पहली बार प्लगइन स्थापित करते हैं, तो उन्हें एप्लिकेशन के माध्यम से उपयोगकर्ता नाम और पासवर्ड के साथ लॉग इन करने के लिए कहा जाता है (आमतौर पर एपीआई के रूप में एक ही सर्वर पर होस्ट किया गया पृष्ठ और एक पृष्ठ में अनुप्रेषित, एक मोटा बॉक्स, या एक आइफ्रेम) ।

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

यदि आप कार्रवाई में इसका एक उदाहरण देखना चाहते हैं, तो Jetpack की जाँच करें ।

जब आप प्लगइन को सक्रिय करते हैं, तो यह शिकायत करता है कि यह जुड़ा नहीं है। जब आप इसे "कनेक्ट" करते हैं, तो आप WordPress.com के माध्यम से अपनी साख दर्ज करते हैं और वर्डप्रेस और उनके एपीआई के बीच OAuth इंटरैक्शन सेट करते हैं।

लेकिन आपको केवल एक बार ऐसा करना होगा और आपके WordPress.com उपयोगकर्ता नाम / पासवर्ड को आपके स्थानीय वर्डप्रेस डेटाबेस में कभी संग्रहीत नहीं किया जाएगा।


1
यह उपयोग करने के लिए अच्छा होगा, लेकिन मैं जिस एपीआई के साथ काम कर रहा हूं वह मेरा नहीं है और उनके पास कोई OAuth सिस्टम नहीं है।
ब्रैडी

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

0

यह एक महत्वपूर्ण मुद्दा है, क्योंकि कई सेवाएं अभी भी OAuth का समर्थन नहीं करती हैं और विकल्प डेटाबेस में पासवर्ड संग्रहीत करना उन्हें हर एक Wordpress प्लगइन के लिए पठनीय बनाता है (ऊपर मेरी टिप्पणी देखें)।

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

मूल विचार जो मुझे लगता है कि पासवर्ड एन्क्रिप्ट करना संभव है, निम्नलिखित है:

प्रत्येक उपयोगकर्ता के पास गुप्त जानकारी का एक टुकड़ा होता है: उनका वर्डप्रेस पासवर्ड। तीसरे पक्ष की सेवाओं के लिए क्रेडेंशियल को स्टोर करना संभव होना चाहिए, यह एक गुप्त व्युत्पन्न रूप से कूटबद्ध किया गया है जो पासवर्ड और केवल उन्हें डिक्रिप्ट करता है जब उपयोगकर्ता लॉग इन होता है।

इस तरह से वर्डप्रेस फ़ाइलों और डेटाबेस की एक प्रति से पासवर्ड चोरी करना कम से कम असंभव होना चाहिए। यह क्रेडेंशियल्स चोरी करने वाले अन्य प्लगइन्स की समस्या को हल नहीं कर सकता है, क्योंकि हर प्लगइन लॉगिन के दौरान सादे टेक्स्ट पासवर्ड को कैप्चर कर सकता है।

वास्तव में डिक्रिप्शन करना आसान है: मान लीजिए कि हमारे पास पहले से ही डेटाबेस में संग्रहीत तृतीय-पक्ष सेवा का एक एन्क्रिप्टेड संस्करण है, हम 'authenticate'फिल्टर में हुक कर सकते हैं या wp_authenticate()फ़ंक्शन को अधिलेखित करके , सादे पाठ उपयोगकर्ता पासवर्ड का एक नमकीन हैश उत्पन्न कर सकते हैं (द्वारा का अर्थ है wp_hash_password(), उस पासवर्ड को स्टोर करें जिसमें एन्क्रिप्शन कुंजी के रूप में पासवर्ड कहीं निजी है जब तक कि उपयोगकर्ता लॉग आउट नहीं करता ( 'wp_logout'कुंजी को हटाने के लिए हुक का उपयोग करें) और हर बार इसका उपयोग करने के लिए हमें डेटाबेस में एन्क्रिप्टेड मूल्य को डिक्रिप्ट करने के लिए तीसरे पक्ष के पासवर्ड की आवश्यकता होती है।

हालांकि मुझे यह महसूस करना चाहिए कि यह काम करना संभव है, फिर भी कई अनसुलझी समस्याएं हैं:

  1. एन्क्रिप्शन कैसे करें? संभावित रूप से कोई भी सादा पाठ पासवर्ड संग्रहीत कर सकता है जब तक कि उपयोगकर्ता लॉग आउट नहीं करता है और फिर से और एन्क्रिप्शन के दौरान करता है 'authenticate'। उपयोगकर्ता को तब तक लॉग इन करने के लिए संकेत दिया जा सकता है जब तक कि यह कम न हो जाए।
  2. कुंजी कहां संग्रहीत करें और लॉग आउट के दौरान इसे कैसे हटाएं? क्या मैं सही ढंग से समझता हूं कि 'authenticate'केवल तभी चलाया जाता है जब उपयोगकर्ता वास्तव में लॉग इन करता है?
  3. मामले में अब हैशेड पासवर्ड स्टोर करने का तरीका है, हो सकता है कि कोई व्यक्ति सत्र कुकी से एक कुंजी प्राप्त कर सकता है?
  4. पासवर्ड परिवर्तन को कौन संभाल सकता है? ऐसा लगता है कि इस तरह के पासवर्ड परिवर्तन को पकड़ना संभव है , और तीसरे पक्ष के पासवर्ड को फिर से नए पासवर्ड से प्राप्त कुंजी के साथ फिर से एन्क्रिप्ट करना होगा।
  5. क्या बहु उपयोगकर्ता सहायता प्रदान करने का एक तरीका है? आदर्श रूप से एक व्यवस्थापक उपयोगकर्ता चाहेगा कि सेटिंग में तीसरे पक्ष के पासवर्ड सेट करने में सक्षम हो, जिसके बाद कम विशेषाधिकार प्राप्त उपयोगकर्ताओं द्वारा तीसरे पक्ष की सेवाओं के साथ बातचीत करने के लिए मुकदमा किया जा सकता है, आदर्श रूप से उन पासवर्ड का खुलासा किए बिना भी। इसके लिए, व्यवस्थापक उपयोगकर्ता को उन सभी उपयोगकर्ताओं के लिए एक कुंजी बनाने में सक्षम होने की आवश्यकता होगी जो अन्य उपयोगकर्ता केवल अपने लिए उत्पन्न कर सकते हैं। क्या यह किसी तरह संभव है?
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.