सुरक्षित रूप से ओपनआईडी पहचानकर्ताओं और ओथ टोकन को संग्रहीत करना

मैं एक वेब ऐप बना रहा हूं जो यूट्यूब के साथ ओपनआईडी लॉग इन और ओथ टॉकेंस का उपयोग करेगा। मैं वर्तमान में डेटाबेस में सादा पाठ में ओपनआईडी पहचान और ओथ टोकन/टोकन रहस्य संग्रहित कर रहा हूं।सुरक्षित रूप से ओपनआईडी पहचानकर्ताओं और ओथ टोकन को संग्रहीत करना

क्या इन मानों को सादे पाठ के रूप में स्टोर करना अनुचित है? मैं ओपनआईडी पहचानकर्ता के लिए एक तरफा एन्क्रिप्शन का उपयोग कर सकता हूं लेकिन मुझे नहीं पता कि यह आवश्यक है या नहीं। ओथ टोकन के लिए, मुझे दो-तरफा एन्क्रिप्शन का उपयोग करना होगा क्योंकि मेरा ऐप कुछ उपयोगों के लिए सत्र टोकन प्राप्त करने पर निर्भर करता है।

क्या ओपनआईडी पहचान को एन्क्रिप्ट करना आवश्यक है? क्या कोई उपयोगकर्ता के खाते तक पहुंच प्राप्त करने के लिए इसका उपयोग कर सकता है?

स्रोत

2009-12-10 Matt McCormick

सबसे पहले, वहाँ है कि consumer_key और consumer_secret एक पंजीकृत आवेदन है। एक access_token कि उपयोगकर्ता की "पासवर्ड" माना जाता है और सिर्फ अपने आवेदन उपयोगकर्ता की ओर से कार्रवाई करने की अनुमति होगी:

जब उपयोगकर्ताओं को प्रमाणित और "अनुमति दें" अपने पंजीकृत आवेदन, आप वापस मिलता है।

तो, अपने डेटाबेस से केवल उपयोगकर्ता के access_token प्राप्त करने से अधिक सहायता नहीं होगी यदि उनके पास consumer_key और consumer_secret पूर्ण पहुंच के लिए भी नहीं है।

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

यह सिर्फ जब आप अद्यतन या एक उपयोगकर्ता की ओर से उपयोगकर्ता के संसाधन स्वामी को परिवर्तन करने की आवश्यकता है। उपयोगकर्ता को अपनी साइट पर लॉग-इन रखने के लिए, सत्रों का उपयोग करें।

स्रोत

2009-12-29 00:13:31 Feha

+28

यह मामला नहीं है यदि आप भालू टोकन के साथ OAuth 2.0 का उपयोग कर रहे हैं।उपयोगकर्ता डेटा तक पहुंचने के लिए आपको केवल एक एक्सेस टोकन (ऑथ टोकन) चाहिए। कुछ सावधान रहना। – FajitaNachos

यहां विचार के दो स्कूल हैं।

पहला तर्क यह है कि: आपको OAuth टोकन को पासवर्ड जैसे व्यवहार करना चाहिए। यदि कोई आपके डेटाबेस तक पहुंचने के लिए था, तो सभी ओपनआईडी/ओथ जोड़े प्राप्त करें और एक मैन-इन-द-बीच हमले चलाएं, वे आपकी साइट पर किसी भी उपयोगकर्ता का प्रतिरूपण कर सकते हैं।

दूसरा तर्क यह है: जब तक किसी व्यक्ति के पास आपके डेटाबेस तक पहुंच हो और एक मैन-इन-द-बीच हमले चलाने के लिए आपके नेटवर्क तक पर्याप्त पहुंच हो, तो आप वैसे भी हो।

मैं व्यक्तिगत रूप से सावधानी के पक्ष में गलती करता हूं और उन्हें एन्क्रिप्ट करता हूं; यह पासवर्ड के लिए एक मानक अभ्यास है, इसलिए आप स्वयं को उस छोटी सी अतिरिक्त मन की शांति भी दे सकते हैं।

इस बीच, गूगल यह सलाह है: "। टोकन सर्वर पर संग्रहीत किसी भी अन्य संवेदनशील जानकारी के रूप में के रूप में सुरक्षित रूप से इलाज किया जाना चाहिए"

स्रोत: http://code.google.com/apis/accounts/docs/OAuth.html

और वेब पर कुछ यादृच्छिक पुरुष विशिष्ट कार्यान्वयन सलाह है:

वे एक नियमित रूप से डिस्क फ़ाइल पर हैं, तो उन्हें फाइल सिस्टम अनुमतियों का उपयोग कर की रक्षा सुनिश्चित करें कि वे ' एन्क्रिप्टेड, और पासवर्ड को अच्छी तरह से छिपाएं
यदि वे डेटाबेस में हैं, तो फ़ील्ड एन्क्रिप्ट करें, कुंजी अच्छी तरह से स्टोर करें, और डेटाबेस तक पहुंच को सुरक्षित रखें सावधानी से। *
यदि वे एलडीएपी में हैं, तो वही करें।

http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/

स्रोत

2009-12-10 07:51:42

मामला किसी में अभी भी इस ट्रैक कर रहा है - मैं इस तरह सामान को एनक्रिप्ट करने के विचार करने के लिए बहुत सहानुभूति हूँ, लेकिन यह मेरे नौसिखिया मस्तिष्क कि हम सिर्फ एक अन्य स्तर पर बंद समस्या धक्का रहे हमलों - हम एन्क्रिप्ट कर सकते हैं, लेकिन अब हमें कहीं भी एन्क्रिप्शन गुप्त रखना है, और आईटी चोरी के खिलाफ सुरक्षा करना है। क्या इसे सिर्फ वेबूट के बाहर कहीं भी फाइल में रखना पर्याप्त है? –

वेब्रूट के बाहर एक फ़ाइल जो वेब सर्वर उपयोगकर्ता तक नहीं पहुंच सकता है (यदि वे उस तरह से प्राप्त होते हैं)। या एक अलग पीकेआई आधारभूत संरचना जो सभी प्रकार की जटिल हो जाती है। यह एक हमलावर के खिलाफ सुरक्षा करता है जो डेटाबेस को डंप करने का तरीका ढूंढता है लेकिन पूरे फाइल सिस्टम नहीं - एक एसक्यूएल इंजेक्शन हमले के माध्यम से कहें। –

अद्यतन के लिए धन्यवाद; यही वह दिशा है जिसे मैं जा रहा हूं। –

OpenID URL एन्क्रिप्टेड नहीं किया जाना चाहिए क्योंकि यह आपकी "खुला आईडी" सचमुच, हर कोई मूल्य पता होना चाहिए। इसके अलावा, यूआरएल को डेटाबेस में एक इंडेक्स होना चाहिए और डेटाबेस में इंडेक्स को एन्क्रिप्ट करना हमेशा मुश्किल होता है।

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

स्रोत

2009-12-10 12:27:15

बिल्कुल सही नहीं है। ओपनआईडी यूआरएल जरूरी नहीं हैं। आरपी के बीच सहसंबंध को रोकने के लिए, Google निर्देशित पहचान का उपयोग करता है ताकि प्रत्येक आरपी को एक ही उपयोगकर्ता के लिए एक अद्वितीय ओपनआईडी मिल सके। यदि इन सभी को सार्वजनिक किया गया था तो सचमुच सभी को मूल्यों को पता था, सहसंबंध फिर से संभव होगा। –

ओपी बैक-एंड डेटाबेस के बारे में बात कर रहा है। यह सार्वजनिक था, आपके पास सौदा करने के लिए बहुत अधिक गोपनीयता समस्याएं हैं। –

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

यह भी मामले आप एक OAuth सर्वर चला रहे हैं हो सकता है, तो आप अभी भी उस अनुरोध की पुष्टि करने के लिए मूल टोकन/गुप्त की जरूरत है।

आप अभी भी इस तरह के एईएस के रूप में एक 2 रास्ता एन्क्रिप्शन एल्गोरिथ्म का उपयोग कर सुरक्षा के मामले में अपने डेटाबेस या डेटाबेस बैकअप के साथ छेड़छाड़ करने के लिए प्रस्ताव दिया उन्हें एन्क्रिप्ट सकता है आप चाहते हैं।

स्रोत

2009-12-11 18:01:01 Pelle

अन्य उत्तरों का कहना है कि उन्हें पासवर्ड के रूप में व्यवहार करें, लेकिन यह जवाब अच्छा है जिसमें यह इंगित करता है कि आपको 2 तरीके एन्क्रिप्शन एल्गोरिदम की आवश्यकता है। हैश किए गए पासवर्ड के साथ आप हैश पासवर्ड के खिलाफ उपयोगकर्ता प्रकार और जांच कर सकते हैं। टोकन और रहस्यों के साथ आपको मूल पाठ को फिर से प्राप्त करने की आवश्यकता है। – paulmorriss

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

@ लेकेंस्टेन शायद एईएस, जो एक तरफा क्रिप्टोग्राफिक हैश फ़ंक्शन की तुलना में दो-तरफा है। जब आप एक ही वातावरण में दोनों का उपयोग करते हैं तो सार्वजनिक-निजी कुंजी क्रिप्टोग्राफ़ी आपको बहुत कुछ नहीं खरीदती है। – skeggse

हां, ये संतुलित एन्क्रिप्टेड किया जाना चाहिए (जैसे कि, सीबीसी मोड में एईएस 256) एक डेटाबेस में आराम से। इन टोकन को एन्क्रिप्ट करने का एक आसान तरीका एक सेवा रीस्टफुल एपीआई के रूप में SecureDB एन्क्रिप्शन का उपयोग कर रहा है।

प्रकटीकरण: मैं सिक्योर डीबी पर काम करता हूं।

स्रोत

2015-09-21 18:26:33 Rettel

सुरक्षित रूप से ओपनआईडी पहचानकर्ताओं और ओथ टोकन को संग्रहीत करना

उत्तर

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