OAuth मोबाइल ऐप्स में रहस्य

Question

OAuth प्रोटोकॉल का उपयोग करते समय, आपको उस सेवा से प्राप्त एक गुप्त स्ट्रिंग की आवश्यकता होती है जिसे आप सौंपना चाहते हैं। यदि आप एक वेब ऐप में ऐसा कर रहे हैं, तो आप बस अपने डेटा बेस में या फ़ाइल सिस्टम पर गुप्त स्टोर कर सकते हैं, लेकिन मोबाइल ऐप (या उस मामले के लिए एक डेस्कटॉप ऐप) में इसे संभालने का सबसे अच्छा तरीका क्या है?

ऐप में स्ट्रिंग को स्टोर करना स्पष्ट रूप से अच्छा नहीं है, क्योंकि कोई इसे आसानी से ढूंढ सकता है और इसका दुरुपयोग कर सकता है।

एक और तरीका यह होगा कि आप इसे अपने सर्वर पर स्टोर कर सकें, और ऐप को हर रन पर लाया जाए, इसे कभी भी फोन पर स्टोर न करें। यह लगभग उतना ही बुरा है, क्योंकि आपको ऐप में URL को शामिल करना होगा।

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

एक और बात: मुझे विश्वास नहीं है कि गुप्त शुरू में एक्सेस टोकन का अनुरोध करने में शामिल है, ताकि हमारे स्वयं के सर्वर को शामिल किए बिना किया जा सके। क्या मैं सही हूँ?

Comments

क्षमा करें यदि मुझे स्पष्ट नहीं मिलता है, लेकिन एप्लिकेशन के डेटाबेस में कोड को संग्रहीत करने में क्या समस्या है? क्योंकि उपयोगकर्ता के खाते को प्रमाणित करने के बाद उन टोकन को उत्पन्न और संग्रहीत किया जाता है, इसलिए यह मान लेना सुरक्षित होना चाहिए कि उपयोगकर्ता मोबाइल डिवाइस को एक्सेस के लिए स्टोर करना चाहता है।

— प्रहार

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

— फेलिक्सज

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

— प्रहार

@poke प्रमाणीकरण कुंजी जो तब प्राप्त होती है जब उपयोगकर्ता प्रदाता के साथ आपके ऐप को मंजूरी देता है, को बचाया जाना चाहिए, लेकिन ऐप को जारी करने से पहले प्रदाता से प्राप्त गुप्त टोकन (डेस्कटॉप या मोबाइल ऐप के मामले में) नहीं होना चाहिए; यदि यह है एक वेब ऐप जिसे आप स्पष्ट रूप से सर्वर पर कुंजी स्टोर कर सकते हैं, जैसा कि प्रश्न में कहा गया है)।

— फेलिक्सज

OAuth की मेरी समझ के अनुसार-- एक डेस्कटॉप ऐप के मामले में HTTP / HTTPS ट्रैफ़िक को इस प्रकार से देखना आसान है / निगरानी करना जैसे कि ieinspector.com/httpanalyzer/index.html इसलिए आपका टोकन और टोकन सीक्रेट दोनों ही बहुत ही उपयोगी हो सकते हैं सरलता। तो एकमात्र सुरक्षा आपका उपभोक्ता-रहस्य है। अब अगर आपका ऐप के अंदर का सीक्रेट स्टोर हो जाता है और कोई व्यक्ति इसे ढूंढने में सक्षम हो जाता है, तो यह आपके ऐप के रूप में किसी अन्य ऐप को इंप्रेस करने के लिए एक बच्चे का खेल बन जाता है। अगर मैं ग़लत हूं तो मेरी गलती सुझाएं।

— वरुण

Answer 1

हां, यह OAuth डिजाइन के साथ एक मुद्दा है जिसे हम खुद सामना कर रहे हैं। हमने अपने स्वयं के सर्वर के माध्यम से सभी कॉल को प्रॉक्सी करने का विकल्प चुना। OAuth पूरी तरह से डेस्कटॉप ऐप्स के संबंध में नहीं था। उस समस्या का कोई प्रीफेक्ट समाधान नहीं है जो मैंने OAuth को बदले बिना पाया है।

यदि आप इसके बारे में सोचते हैं और सवाल पूछते हैं कि हमारे पास रहस्य क्यों हैं, तो यह ज्यादातर प्रावधान और अक्षम ऐप्स के लिए है। यदि हमारे रहस्य से छेड़छाड़ की जाती है, तो प्रदाता केवल पूरे ऐप को ही रद्द कर सकता है। चूंकि हमें अपने रहस्य को डेस्कटॉप ऐप में एम्बेड करना है, इसलिए हम छंटे हुए हैं।

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

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

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

ऑनलाइन समस्या के बारे में कुछ बातचीत कर रहे हैं:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1-de1071bf4b820c14#de1071bf4b820c142014

Twitter और Yammer का समाधान एक प्रमाणीकरण पिन समाधान है: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Comments

यह बहुत दिलचस्प है, हालांकि यह पुष्टि करता है कि मुझे क्या डर था, कि OAuth डेस्कटॉप / मोबाइल एप्लिकेशन के लिए इतना महान नहीं है। बेशक, एक हमलावर को पहले रहस्य प्राप्त करना होगा और फिर किसी की साख को भी सूँघना होगा, इसलिए यह काफी कुछ दृढ़ संकल्प लेगा। पिन समाधान डेस्कटॉप के लिए ठीक है, लेकिन मोबाइल इमो के लिए भारी-भरकम है।

— फेलिक्सज

आपकी प्रस्तावित योजना वेब सेवाओं को मूल्य-वर्धित करने में कैसे मदद करेगी, क्योंकि यह समस्या उन पर लागू नहीं होती है? इसके अलावा, मैं यह नहीं देखता कि यह नए रहस्यों को उत्पन्न करने वाले प्रदाता के साथ कैसे काम करेगा, क्योंकि आपको उन नए रहस्यों का अनुरोध करने के लिए "मास्टर रहस्य" की आवश्यकता होगी, इसलिए आपको कम से कम अपने स्वयं के सर्वर पर एक कॉल की आवश्यकता होगी (जो कि रखती है) मुख्य रहस्य)। लेकिन यह निश्चित रूप से अपने स्वयं के सर्वर के माध्यम से सभी यातायात को पार करने से बेहतर है । सरलीकरण का सबसे अधिक स्वागत है! और जैसे ही आपका प्रस्ताव आगे बढ़ता है, कृपया यहाँ अपडेट करें!

— फेलिक्सज

बस जिज्ञासु: आप कैसे निर्धारित करते हैं कि आपके प्रॉक्सी सर्वर पर कॉल करने वाली बात वैध है?

— davidtbernal

NotJim के जवाब में: आपके उपभोक्ता को बाहर निकलने की अनुमति देने में प्राथमिक जोखिम यह है कि दुर्भावनापूर्ण (या मूर्ख) एप्लिकेशन का उपयोग करके इसे विकसित किया जा सकता है, जिससे आपकी प्रतिष्ठा धूमिल होती है और एपीआई दुरुपयोग / दुरुपयोग के लिए आपके वैध आवेदन के बंद होने का खतरा बढ़ जाता है। आपके द्वारा नियंत्रित वेब एप्लिकेशन के माध्यम से आपके गुप्त की आवश्यकता वाले सभी कॉलों को अनुमानित करके, आप एक ऐसी स्थिति में हैं जहां आप दुरुपयोग के पैटर्न के लिए देख सकते हैं और उपयोगकर्ता पर पहुंच को रद्द कर सकते हैं या एपीआई से पहले टोकन स्तर तक पहुंच सकते हैं जिसे आप बंद करने का निर्णय लेते हैं। नीचे अपनी पूरी सेवा।

— क्वासिस्टिक जूल

मैं यहाँ quasistoic से सहमत हूँ, आपको oauth कॉल से निपटने के लिए एक SSL सक्षम ब्राउज़र का उपयोग करना होगा। यह कुछ कारणों से एक अच्छी बात है, जिसमें भविष्य में किसी भी सुरक्षा अपडेट को आसानी से प्रबंधित करना शामिल है, और वास्तविक एप्लिकेशन में कुछ भी समय पर अपडेट करने की आवश्यकता नहीं है। Zac एक पिन समाधान का प्रस्ताव करते हुए ट्विटर को इंगित करता है, जिसे मैंने वास्तव में भी सोचा था, क्योंकि आप कोड को सुरक्षित रूप से प्राप्त करने के लिए आवेदन पर भरोसा नहीं कर सकते। मेरा सुझाव है कि पिन के साथ एक आधुनिक एन्क्रिप्शन के साथ एक 'नॉनसे' का उपयोग करें और वेब सर्वर के माध्यम से अनुरोधों को गुप्त करें।

— मार्क

Answer 2

OAUth 2.0 के साथ, आप सर्वर पर गुप्त स्टोर कर सकते हैं। एक्सेस टोकन प्राप्त करने के लिए सर्वर का उपयोग करें जिसे आप फिर ऐप में स्थानांतरित करते हैं और आप ऐप से सीधे संसाधन तक कॉल कर सकते हैं।

OAuth 1.0 (Twitter) के साथ, API को API कॉल करने के लिए आवश्यक है। सर्वर के माध्यम से कॉल को सम्‍मिलित करना यह सुनिश्चित करने का एकमात्र तरीका है कि गोपनीयता से समझौता न किया जाए।

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

(मैं OAuth 2.0 कल्पना का संपादक हूं)

Comments

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

— चेसो

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

— डिक हार्ड्ट

@ डिकहार्ट लेकिन इस दर्शनीय में आप यह कैसे सुनिश्चित करते हैं कि मोबाइल एप्लिकेशन वास्तव में आपका ऐप है न कि कोई धोखाधड़ी?

— राफेल मेम्ब्रेन्स

Answer 3

एक समाधान कोड में OAuth रहस्य को हार्ड कोड करने के लिए हो सकता है, लेकिन नहीं एक सादे स्ट्रिंग के रूप में । इसे किसी तरह से स्थगित करें - इसे खंडों में विभाजित करें, वर्णों को एक ऑफसेट द्वारा स्थानांतरित करें, इसे घुमाएं - इनमें से कोई भी या सभी चीजें करें। एक पटाखा आपके बाइट कोड का विश्लेषण कर सकता है और स्ट्रिंग्स का पता लगा सकता है, लेकिन ऑबफ्यूजन कोड का पता लगाना मुश्किल हो सकता है।

यह एक मूर्खतापूर्ण समाधान नहीं है, लेकिन एक सस्ता है।

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

Comments

हां मुझे लगता है कि यह उचित है। किसी को पहले उपभोक्ता रहस्य को निकालने और फिर कुछ करने के लिए लोगों की साख को छीनने के लिए बहुत अधिक दृढ़ संकल्प लेना होगा। हाई-प्रोफाइल ऐप्स के लिए, मुझे यकीन नहीं है कि यह पर्याप्त होगा, लेकिन औसत ऐप के लिए मुझे लगता है कि आप सही हैं कि आपको एक बहुत मामूली सुरक्षा खतरे के खिलाफ कार्यान्वयन समय को संतुलित करना होगा।

— फेलिक्सज

यह सब लेता है एक उपयोगकर्ता के लिए प्रयास करना और फिर अपने रहस्य को प्रकाशित या साझा करना है। एक बार जब आपका रहस्य बाहर हो जाता है, तो आपकी सेवा का जोखिम दुरुपयोग के लिए पूरी तरह से बंद हो जाता है, और यह पूरी तरह से आपके नियंत्रण से बाहर है।

— क्वासिस्टिक जूल

स्थगन सुरक्षा नहीं है। यह किसी भी सुरक्षा से बिल्कुल भी बदतर नहीं है, क्योंकि यह डेवलपर को सुरक्षा की झूठी भावना देता है। en.wikipedia.org/wiki/Security_through_obscurity

— पॉल लेगाटो

"Obfuscation सुरक्षा बिल्कुल नहीं है। यह किसी भी सुरक्षा से बिल्कुल भी बदतर नहीं है, क्योंकि यह डेवलपर को सुरक्षा की झूठी भावना देता है।" बकवास। कोई भी यह नहीं कह रहा है कि अच्छी सुरक्षा के लिए आक्षेप करना पड़ता है। लेकिन अगर मैं अपने apk के साथ एक OAuth रहस्य वितरित कर रहा हूं, तो निश्चित रूप से नहीं की तुलना में इसे बेहतर करना है। Obfuscation वह है जो Google इन-एप्स की कुंजी / रहस्य संग्रहीत करते समय सुझाता है। अगर और कुछ नहीं, तो ये उपाय आकस्मिक हैकर्स को बे पर रखते हैं, जो कुछ भी नहीं से बेहतर है। आपकी तरह कंबल वाले बयान बिना किसी सुरक्षा के अपूर्ण सुरक्षा को समान करते हैं। यह सच नहीं है। अपूर्ण सिर्फ अपूर्ण है।

— शाम

Obfuscation मदद नहीं करता है, क्योंकि कोई फर्क नहीं पड़ता कि आप कितना शिफ्टिंग या एन्कोडिंग करते हैं, फिर भी आप एक साथ कुंजी का निर्माण करते हैं और अपने एपीआई अनुरोध का निर्माण करने के लिए उपयोग करते हैं। यह HTTPS एन्क्रिप्शन से पहले आपके द्वारा भेजे जा रहे अनुरोध को डंप करने के लिए सही स्थानों पर गतिशील रूप से हुक एपीआई के लिए काफी सरल है। तो कृपया, अपने ऐप में गुप्त कुंजी तब तक एम्बेड न करें जब तक कि वास्तव में कोई संभावित विकल्प न हो।

— C0deH4cker

Answer 4

आवेदन के अंदर रहस्य को स्टोर न करें।

आपके पास एक सर्वर होना चाहिए जिसे https (स्पष्ट रूप से) पर एप्लिकेशन द्वारा एक्सेस किया जा सकता है और आप उस पर रहस्य संग्रहीत करते हैं।

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

फिर यदि आपको सेवा (फेसबुक, गूगल, ट्विटर, आदि) से कोई संवेदनशील जानकारी प्राप्त करने की आवश्यकता है, तो एप्लिकेशन आपके सर्वर से पूछेगा और आपका सर्वर इसे तभी आवेदन देगा जब यह सही तरीके से जुड़ा हो।

सर्वर पर संग्रहीत करने के अलावा वास्तव में कोई विकल्प नहीं है। क्लाइंट साइड पर कुछ भी सुरक्षित नहीं है।

ध्यान दें

उस ने कहा, यह केवल दुर्भावनापूर्ण ग्राहक के खिलाफ आपकी रक्षा करेगा लेकिन ग्राहक आपके प्रति दुर्भावनापूर्ण नहीं है और अन्य दुर्भावनापूर्ण ग्राहकों के खिलाफ नहीं है (फ़िशिंग ...

OAuth डेस्कटॉप / मोबाइल की तुलना में ब्राउज़र में बहुत बेहतर प्रोटोकॉल है।

Comments

यह हैकर के जीवन को आसान नहीं बनाता है ?! क्योंकि अब, सर्वर संसाधनों तक पहुंचने के लिए हमें तकनीकी रूप से क्लाइंट आईडी की आवश्यकता होती है, क्योंकि सर्वर वैसे भी अनुरोध के रहस्य को जोड़ देगा। क्या मैं कुछ भूल रहा हूँ?

— हुडी इलफ़ेल्ड

@HudiIlfeld हाँ आप कुछ याद कर रहे हैं: क्लाइंट को सर्वर में लॉगिन करने की आवश्यकता है। जब तक वह लॉगिन नहीं करता है, तब तक सर्वर कुछ भी वापस नहीं करेगा। इसे प्रबंधित करने का एक तरीका यह है कि पहली बार क्रेडेंशियल भेजने के बाद, सर्वर क्लाइंट को एक टोकन लौटाए और फिर क्लाइंट हर भविष्य के अनुरोध के साथ इस एक्सेस टोकन को भेजें। यहां कई विकल्प हैं।

— गुडरडेन

Answer 5

ऑथराइजेशन कोड ग्रांट टाइप का एक नया एक्सटेंशन है, जिसे कोड एक्सचेंज (PKCE) के लिए प्रूफ की कहा जाता है । इसके साथ, आपको एक ग्राहक रहस्य की आवश्यकता नहीं है।

PKCE (RFC 7636) सार्वजनिक ग्राहकों को सुरक्षित करने की एक तकनीक है जो क्लाइंट सीक्रेट का उपयोग नहीं करती है।

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

से https://oauth.net/2/pkce/

अधिक जानकारी के लिए, आप पूर्ण RFC 7636 या इस संक्षिप्त परिचय को पढ़ सकते हैं ।

Answer 6

यहाँ कुछ सोचने के लिए है। Google वेब एप्लिकेशन के लिए OAuth ... की दो विधियाँ प्रदान करता है, जहाँ आप डोमेन पंजीकृत करते हैं और एक अद्वितीय कुंजी उत्पन्न करते हैं, और स्थापित ऐप के लिए जहाँ आप कुंजी "अनाम" का उपयोग करते हैं।

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

Answer 7

OAuth 2.0 के साथ आप बस एक्सेस टोकन प्राप्त करने के लिए क्लाइंट साइड फ्लो का उपयोग कर सकते हैं और आगे के सभी अनुरोधों को प्रमाणित करने के लिए इस एक्सेस टोकन का उपयोग कर सकते हैं। तो फिर तुम एक रहस्य की जरूरत नहीं है।

इसे कैसे लागू किया जा सकता है, इसका एक अच्छा विवरण यहां पाया जा सकता है: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Comments

बशर्ते सेवा "क्लाइंट साइड फ्लो" का समर्थन करती है। कई लोगों को इस एक्सेस टोकन को प्राप्त करने के लिए क्लाइंट आईडी और क्लाइंट सीक्रेट की आवश्यकता नहीं होती है।

— डेमियन येरिक

Answer 8

मेरे पास OAuth के साथ एक टन का अनुभव नहीं है - लेकिन क्या हर अनुरोध के लिए न केवल उपयोगकर्ता की पहुंच टोकन की आवश्यकता है, बल्कि एक आवेदन उपभोक्ता कुंजी और गुप्त भी है? इसलिए, यहां तक ​​कि अगर कोई मोबाइल डिवाइस चुराता है और इससे डेटा को खींचने की कोशिश करता है, तो उन्हें एक एप्लिकेशन कुंजी और गुप्त की आवश्यकता होगी और साथ ही वास्तव में कुछ भी करने में सक्षम होना चाहिए।

मैंने हमेशा सोचा था कि OAuth के पीछे का इरादा ऐसा था कि हर टॉम, डिक और हैरी के पास मैशअप था जो आपके ट्विटर क्रेडेंशियल्स को स्पष्ट में संग्रहीत नहीं करता था। मुझे लगता है कि यह उस समस्या को हल करता है जबकि यह सीमाएँ है। इसके अलावा, यह वास्तव में मन में iPhone के साथ डिजाइन नहीं किया गया था।

Comments

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

— फेलिक्सज

OAuth 1 को प्रत्येक अनुरोध पर हस्ताक्षर करने की आवश्यकता है। OAuth 2 को केवल पहुंच टोकन की आवश्यकता है। टोकन प्राप्त करते समय कुंजी और रहस्य दोनों की आवश्यकता होती है।

— डिक हार्ड्ट

Answer 9

मैं फेलिक्सिज से सहमत हूं। बेसिक ऑथ की तुलना में OAuth बेहतर है, फिर भी मोबाइल ऐप्स के लिए एक अच्छा उपाय है। मैं एक मोबाइल ऐप को Google App Engine ऐप में प्रमाणित करने के लिए OAuth का उपयोग करने के साथ खेल रहा हूं। तथ्य यह है कि आप मोबाइल डिवाइस पर उपभोक्ता रहस्य को विश्वसनीय ढंग से प्रबंधित नहीं कर सकते हैं, इसका मतलब है कि डिफ़ॉल्ट 'अनाम' पहुंच का उपयोग करना है।

Google App Engine OAuth कार्यान्वयन का ब्राउज़र प्राधिकरण चरण आपको एक ऐसे पृष्ठ पर ले जाता है, जहाँ इसमें पाठ होता है जैसे: "साइट <कुछ-साइट> नीचे सूचीबद्ध उत्पाद (उत्पादों) के लिए आपके Google खाते तक पहुँच का अनुरोध कर रहा है"

YourApp (yourapp.appspot.com) - Google से संबद्ध नहीं है

आदि

कॉलबैक url में उपयोग किए जाने वाले डोमेन / होस्ट नाम से यह <कुछ-साइट> लेता है जो आप आपूर्ति करते हैं जो एंड्रॉइड पर कुछ भी हो सकता है यदि आप कॉलबैक को इंटरसेप्ट करने के लिए एक कस्टम योजना का उपयोग करते हैं। इसलिए यदि आप 'अनाम' पहुंच का उपयोग करते हैं या आपके उपभोक्ता रहस्य से समझौता किया जाता है, तो कोई भी एक उपभोक्ता लिख ​​सकता है जो उपयोगकर्ता को आपके जीए ऐप तक पहुंच प्रदान करने में मूर्ख बनाता है।

Google OAuth प्राधिकरण पृष्ठ में बहुत सारी चेतावनियाँ हैं, जिनमें गंभीरता के 3 स्तर हैं जो इस आधार पर हैं कि आप 'अनाम', उपभोक्ता रहस्य या सार्वजनिक कुंजी का उपयोग कर रहे हैं।

औसत उपयोगकर्ता के लिए बहुत डरावना सामान जो तकनीकी रूप से समझदार नहीं है। मुझे उस तरह के सामान के साथ उच्च साइनअप पूर्णता प्रतिशत की उम्मीद नहीं है।

यह ब्लॉग पोस्ट स्पष्ट करता है कि उपभोक्ता रहस्य वास्तव में इंस्टॉल किए गए ऐप्स के साथ कैसे काम करता है। http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Answer 10

मैं भी मोबाइल OAuth प्रमाणीकरण के लिए एक समाधान के साथ आने की कोशिश कर रहा हूं, और सामान्य रूप से आवेदन बंडल के भीतर रहस्यों को संग्रहीत करना।

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

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

क्या वह काम करेगा?

Comments

अच्छा सोचा, लेकिन नहीं। पटाखा बस बाइनरी को ओएस स्थिरांक के पते की ओर इशारा करता है।

— ग्रेब

Answer 11

यहाँ मैं मोबाइल एप्लिकेशन में आपकी oAuth जानकारी संग्रहीत करने के सुरक्षित तरीके का जवाब देता हूं

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Answer 12

फेसबुक OAuth को सख्ती से बोलना (अभी तक) लागू नहीं करता है, लेकिन उन्होंने आपके लिए अपने iPhone ऐप में अपने रहस्य को एम्बेड नहीं करने का एक तरीका लागू किया है: https://web.archive.org/web/20091223092924/http://wiki। developers.facebook.com/index.php/Session_Proxy

OAuth के लिए, हाँ, जितना मैं इसके बारे में सोचता हूं, हम थोड़ा भरवां हैं। शायद यह इसे ठीक कर देगा।

Comments

wiki.developers.facebook.com मर चुका है।

— ह्यूगो

Answer 13

इनमें से कोई भी समाधान क्लाइंट हेड को http हेडर में देखने के लिए अपने मोबाइल डिवाइस (या एमुलेटर) से भेजे गए पैकेट को सूँघने से निर्धारित हैकर को नहीं रोकता है।

एक समाधान एक गतिशील रहस्य हो सकता है जो एक निजी 2-वे एन्क्रिप्शन कुंजी और एल्गोरिथ्म के साथ एन्क्रिप्टेड टाइमस्टैम्प से बना है। सेवा तब रहस्य को मिटा देती है और निर्धारित करती है कि समय का मोहर +/- 5 मिनट है।

इस तरह, भले ही रहस्य से समझौता किया गया हो, हैकर केवल अधिकतम 5 मिनट के लिए ही इसका उपयोग कर पाएगा।

Answer 14

जैसा कि दूसरों ने उल्लेख किया है, डिवाइस पर स्थानीय रूप से गुप्त भंडारण के साथ कोई वास्तविक मुद्दा नहीं होना चाहिए।

उसके शीर्ष पर, आप हमेशा एंड्रॉइड के यूनिक्स-आधारित सुरक्षा मॉडल पर भरोसा कर सकते हैं: केवल आपका आवेदन उस तक पहुंच सकता है जो आप फ़ाइल सिस्टम पर लिखते हैं। बस अपने ऐप के डिफॉल्ट SharedPreferences ऑब्जेक्ट के लिए जानकारी लिखें।

गुप्त प्राप्त करने के लिए, किसी को Android फ़ोन पर रूट एक्सेस प्राप्त करना होगा।

Comments

जैसा कि किसने उल्लेख किया है? यदि आपको प्रहार की टिप्पणी का मतलब है, तो मेरे उत्तर को गुप्त देखें! = प्रमाणीकरण कुंजी। बाद को सुरक्षित रूप से संग्रहीत किया जा सकता है, पूर्व नहीं कर सकता। मुझे Android के बारे में पता नहीं है, लेकिन iPhone तक रूट एक्सेस प्राप्त करना कठिन नहीं है। ध्यान दें कि गुप्त एप्लिकेशन के सभी उदाहरणों पर समान है, इसलिए एक हमलावर को केवल एक बाइनरी तक पहुंच प्राप्त करनी होगी। और यहां तक ​​कि अगर वे डिवाइस पर रूट एक्सेस हासिल नहीं कर सकते हैं, तो वे किसी अन्य में बाइनरी पर अपने हाथ प्राप्त कर सकते हैं और गुप्त टोकन को इससे बाहर निकाल सकते हैं।

— फेलिक्सज

बस जोड़ने के लिए यह बहुत आसान है Android फोन के रूप में अच्छी तरह से रूट करने के लिए

— kg बात फ्रिज