ओएथ सुरक्षित नहीं है या मुझे समझ में नहीं आया?

Question

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

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

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

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

बीटीडब्ल्यू ओएथ प्रोटोकॉल में सुरक्षा प्रवाह था http://oauth.net/advisories/2009-1/) और मुझे पूरा यकीन है कि और भी कुछ हैं, लेकिन कोई भी उन्हें ढूंढने की परवाह नहीं करता है।

Answer 1

मैं 'आप इसे समझ में नहीं आया' के साथ जाने जा रहा हूं। (आपकी रक्षा में, बहुत कम लोग करते हैं।)

चलो स्पष्ट हो जाएं: सत्र निर्धारण फिक्स हमला आप प्रभावित OAuth 1.0 का जिक्र कर रहे हैं, लेकिन OAuth 1.0a में हल किया गया था, जो RFC 5849 बन गया। ओएथ 1.0 के कोई बड़े कार्यान्वयनकर्ता नहीं हैं - प्रमुख कार्यान्वयनकर्ताओं ने या तो ओएथ 1.0 ए/आरएफसी 5849 लागू किया है या उन्होंने ओएथ 2.0 ड्राफ्ट में से एक को लागू किया है।

उपयोगकर्ता नाम/पासवर्ड विरोधी पैटर्न के लिए, OAuth 1.0a किसी एक्सेस टोकन के लिए उपयोगकर्ता नाम और पासवर्ड का आदान-प्रदान करने के लिए तंत्र प्रदान नहीं करता है। OAuth 2.0 करता है, लेकिन केवल स्थापित अनुप्रयोगों के समर्थन के प्रयोजनों के लिए। ध्यान रखें कि एक स्थापित एप्लिकेशन बस वास्तव में चाहता था कि keylog (या समान) सकता है। जब सुरक्षा की बात आती है, तो सभी शर्त बंद हो जाती हैं यदि कोई एप्लिकेशन पहले से ही क्लाइंट की मशीन पर मूल रूप से चल रहा है और अनसुलझा हुआ है। लेकिन यह वास्तव में एक बहुत ही अलग परिदृश्य है जिसके बारे में आप बात कर रहे हैं। OAuth 1.0a और OAuth 2.0 दोनों में वेब अनुप्रयोग उपयोगकर्ता नाम और पासवर्ड को कभी भी स्पर्श नहीं करते हैं।

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

प्रोटोकॉल के साथ security considerations कई हैं, लेकिन यदि आप वास्तव में सूची पढ़ते हैं, तो यह अनिवार्य रूप से उन सुरक्षा समस्याओं की एक ही सूची है जो इंटरनेट पर लगभग हर साइट को प्रभावित करते हैं। ये सुरक्षा विचार सभी बहुत प्रसिद्ध और बहुत अच्छी तरह से समझा जाता है। मेरे ज्ञान के लिए, वर्तमान में प्रदाताओं के खिलाफ कोई ज्ञात शोषक हमले नहीं हैं जो इन सभी सुरक्षा विचारों को सही ढंग से संबोधित करते हैं।

प्वाइंट होने के नाते, आप किसी भी विकल्प के मुकाबले किसी तीसरे पक्ष को अधिकृत करने के लिए OAuth 1.0a या OAuth 2.0 का उपयोग करके अधिक सुरक्षित हैं। यदि आप इनके साथ सहज महसूस नहीं करते हैं, तो समाधान सरल है: अपने खाते तक पहुंचने के लिए तीसरे पक्ष को अधिकृत न करें। निश्चित रूप से बहुत सारे कारण हैं कि आप ऐसा क्यों नहीं करना चाहते हैं।

Answer 2

ऐसा लगता है जैसे आप सुरक्षित नहीं हैं के बारे में उलझन में हैं। जैसा कि मैं इसे समझता हूं, ओएथ प्रोटोकॉल स्वयं, अगर सही तरीके से कार्यान्वित किया जाता है, तो सुरक्षित है। यह सिर्फ इतना है कि अनुचित रूप से कार्यान्वित करना आसान है, और उपयोगकर्ता भ्रमित हो जाते हैं क्योंकि वे वास्तव में नहीं समझते कि वे क्या कर रहे हैं।

उदाहरण के लिए, लिंक्डइन क्या कर रहा है सब गलत है। मैं उन्हें इस तरह से अपनी जीमेल खाता जानकारी कभी नहीं दूंगा। मुझे अपनी जीमेल खाता जानकारी प्रदान करने के लिए, मैं यह देखने पर जोर देता हूं कि मेरा ब्राउज़र Google के साथ SSL का उपयोग कर रहा है और इसलिए पृष्ठ का रूट फ्रेम Google से आता है।

फिर Google पर भरोसा करने का मामला सही तरीके से मुझे बताता है कि किस एक्सेस का अनुरोध किया जा रहा है और किसके द्वारा। अगर मुझे ऐसा करने पर भरोसा नहीं है, तो मुझे ओथ का उपयोग नहीं करना चाहिए।