क्या मुझे Android ऐप द्वारा संग्रहीत OAuth उपभोक्ता रहस्य को रोकना चाहिए?

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

क्या मुझे इसे अस्पष्ट करने के लिए कदम उठाने चाहिए (जैसे, rot13 या obfuscated जावा कोड में संग्रहीत)? या क्या मुझे वास्तव में ऐसा करने से बचना चाहिए, क्योंकि इससे सुरक्षा की झूठी भावना पैदा होगी?

लोग आमतौर पर एंड्रॉइड ऐप्स में ओथ गुप्त को वितरित/स्टोर कैसे करते हैं? रहस्य चोरी और दुर्व्यवहार के लिए कितना आम है?

स्रोत

2011-08-19 Pēteris Caune

मेरे पास बैकएंड पर मेरे आईओएस ऐप और नोडजेएस + एक्सप्रेसजेएस + पासपोर्टजेएस के साथ एक ही रणनीति है। मैं आईओएस से उपयोगकर्ताओं को प्रमाणीकृत करने के लिए ट्विटर रिवर्स ऑथ का उपयोग करता हूं। लेकिन इसे सुरक्षित करने और उपयोगकर्ताओं को हेडर्स में क्या पता लगाने के लिए मध्य में HTTP पैकेट को स्नीफ करने से रोकते हैं, मैं डेटा को एन्क्रिप्ट करने के लिए अपने सर्वर पर HTTPS का उपयोग करने की योजना बना रहा हूं। अपने ऐप में अपनी गोपनीयता कुंजी एम्बेड करने से बचने के लिए इसे जांचें: https: //dev.twitter।com/docs/ios/use-reverse-auth – Maziyar

नोट: रिवर्स ऑथ केवल आईओएस –

असली सवाल

आप अपने सबसे अच्छे करना चाहिए रहस्य की रक्षा के लिए एक हमलावर क्या यह चोरी से प्राप्त करता है ... लेकिन अंत में, एक बेहद प्रेरित हैकर हमेशा एक स्थापित अनुप्रयोग में इसे करने के लिए मिल सकता है। तो यह गुप्त बनाम निष्कर्षण की कठिनाई का मूल्य है।

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

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

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

संक्षेप में, आगे बढ़ें और इसे खराब करें। यह चोट नहीं पहुंचाता है। प्रॉक्सी पैटर्न का भी उपयोग करने पर विचार करें। और शायद ट्विटर को पता चले कि उनकी सुरक्षा नीतियां "महान नहीं हैं"।

स्रोत

2011-08-20 14:31:52

उत्तर के लिए धन्यवाद। जिस ऐप पर मैं काम कर रहा हूं वह उच्च प्रोफ़ाइल सोशल ऐप नहीं होने वाला है, इससे ट्वीट करना एक साइड फीचर है। तो मुझे लगता है कि मैं कुछ obfuscation के साथ जाना होगा, लेकिन प्रॉक्सी पैटर्न की अतिरिक्त जटिलता छोड़ देंगे। –

जानकारियों में से किसी के द्वारा मेरे अंक को मजबूत करने के लिए बढ़िया। जबकि प्रॉक्सीइंग समस्या को कहीं और ले जाती है, एक हैकर को अपने प्रॉक्सी का दुरुपयोग करने के लिए एक विशिष्ट प्रोग्राम लिखना होगा। हकीकत में, वे बस अन्य ऐप्स से उपभोक्ता रहस्यों को फसल लेंगे - वहां [दस लाख से अधिक तृतीय-पक्ष ऐप्स] हैं (http://techcrunch.com/2011/08/19/twitter-releases-bootstrap-a-set-of- टूल-टू-बिल्ड-वेब-ऐप-का उपयोग कर-सीएसएस /? utm_source = फीडबर्नर और utm_medium = फ़ीड और utm_campaign = फ़ीड% 3 ए + टेकक्रंच +% 28 टेकक्रंच% 2 9) सब के बाद। –

ट्विटर ऐप्स में एक कॉलबैक यूआरएल है, क्या यह हैकर्स को डेटा चोरी करने वाले वेब ऐप्स बनाने से रोकने के लिए पर्याप्त होगा? यह आपके द्वारा अपनी ऐप सेटिंग्स में सेट किया गया डोमेन होना चाहिए अन्यथा यह आपके द्वारा भेजे जाने वाले कुछ भी अधिकृत नहीं करेगा। – Maziyar

-3

0Auth का मुख्य बिंदु यह है कि आप डिवाइस पर किसी भी कीमती संवेदनशील जानकारी को स्टोर नहीं करते हैं - इसलिए डिवाइस पर गुप्त स्टोर करना ठीक है (वास्तविक उपयोगकर्ता प्रमाण-पत्र बेहतर)। मामले आपके डिवाइस रहस्य चोरी हो जाने में, उपयोगकर्ता हमेशा की आवश्यकता के बिना पहुँच को अमान्य कर सकते हैं उसकी साख

स्रोत

2011-08-19 13:17:50

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

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

मुझे लगता है कि इस जवाब ने ओथ टोकन के साथ उपभोक्ता रहस्यों को भ्रमित कर दिया है। –

बदलने के लिए मैं निश्चित रूप से OAuth लेखकों में से एक, Eran हैमर-Lahav, जो किसी अन्य article dissecting Twitter's OAuth secret problems का हवाला देते द्वारा this analysis पढ़ा होगा।

मेरी सलाह कुंजी को खराब करना होगा ताकि इसे छोटा रूप से निकाला जा सके और आपको चांसर्स और स्पैमर से सुरक्षित होना चाहिए।

हैमर-लाहव की राय यह है कि ओथ रहस्यों को निरस्त नहीं किया जाना चाहिए और आंकड़ों को इकट्ठा करने के लिए इसका उपयोग किया जाना चाहिए। उम्मीद है कि ट्विटर इस सलाह का पालन कर रहे हैं।

स्रोत

2011-08-19 14:04:10

लेख कहता है "स्थापित अनुप्रयोगों में क्लाइंट रहस्यों का उपयोग न करें", और आपकी सलाह विपरीत है ... –

@ ग्राहम ग्रेट प्वाइंट - मुझे थोड़ा स्पष्ट होना चाहिए था। यदि ओपी आगे बढ़ने की योजना बना रहा है तो obfuscation * * अपमानजनक है। अन्यथा, मुझे लगता है कि आपको एक कार्यान्वयन की आवश्यकता है जहां गुप्त सर्वर पर गुप्त संग्रह किया जाता है और वेब सेवा OAuth कॉल के लिए प्रॉक्सी के रूप में कार्य करती है। मुझे नहीं पता कि इस दृष्टिकोण के लिए सर्वोत्तम अभ्यास क्या हैं। –

क्या मुझे Android ऐप द्वारा संग्रहीत OAuth उपभोक्ता रहस्य को रोकना चाहिए?

उत्तर

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