मैं एक ऐसी वेबसाइट तैयार कर रहा हूं जिसमें मोबाइल साथी (केवल आईफोन केवल) होगा। वेबसाइट एक एएसपी.NET एमवीसी 3 आवेदन होगा। आईफोन एप्लिकेशन में सेवाओं का पर्दाफाश करने के लिए मेरे पास एएसपी.Net वेब एपीआई साइट (एमवीसी 4) भी होगी। आईफोन ऐप के पास उपयोगकर्ता से उपयोगकर्ता नाम और पासवर्ड कैप्चर करने और JSON शीर्षलेखों में वेब एपीआई को भेजने के लिए अपना स्वयं का फॉर्म होगा।मोबाइल (आईफोन) ऐप से एएसपी.Net वेब एपीआई (मेरे डिजाइन पर फीडबैक अनुरोध) से प्रमाणीकरण अनुरोध
मैं विचार के बाद शुरुआत से सुरक्षा पर विचार करना चाहता हूं। मैं किसी भी माध्यम से सुरक्षा विशेषज्ञ नहीं हूं। मैंने यह देखने के लिए एक अच्छा सौदा किया है कि वेब सेवा से मोबाइल एप्लिकेशन क्लाइंट के प्रमाणीकरण को कैसे प्रबंधित किया जा रहा है। मुझे लगता है कि मैं एक सभ्य समाधान के साथ आया हूं जिसमें तीसरे पक्ष के ओथ में शामिल नहीं है।
मैं किसी भी और सभी राय, सलाह, आलोचना और सामान्य डब्ल्यूटीएफ की सराहना करता हूं कि आप में से कोई भी पेशकश कर सकता है। :)
मेरे सबसे बड़ी चिंता कर रहे हैं:
- सुनिश्चित करना है कि वेब एपीआई की जाने वाली कॉल के लिए अधिकृत हैं
- पुनरावृत्ति के दौरे का जोखिम (इसलिए नीचे कॉल में timestamps)
को न्यूनतम आईफोन ऐप इस प्रकार विकसित किया जाएगा:
आईफोन ऐप में दो तारों को हार्ड-कोड किया गया है (प्रत्येक उपयोगकर्ता के लिए समान मान):
- अनुप्रयोग ID
यह एक स्ट्रिंग है कि ग्राहक है कि वेब एपीआई (iPhone, Android, विंडोज फोन, आदि) तक पहुँच रहा है के प्रकार की पहचान करने के लिए प्रयोग किया जाता है। - एप्लिकेशन का हैशिंग नमक
यह एक स्ट्रिंग है जिसका प्रयोग उपयोगकर्ता-अज्ञात अनुरोधों के लिए नमक हैश के लिए किया जाता है।
दो तार iPhone एप्लिकेशन के स्थानीय डेटाबेस में संग्रहीत हैं (प्रत्येक उपयोगकर्ता के लिए अद्वितीय मान):
- एपीआई उपयोगकर्ता पहुँच टोकन
इस ग्राहक के लिए प्रदान की एक स्ट्रिंग (टोकन) है सफल प्रमाणीकरण पर वेब एपीआई द्वारा और ग्राहक को प्रत्येक अनुरोध में उपयोगकर्ता नाम और पासवर्ड भेजने के बिना वेब एपीआई तक पहुंचने की अनुमति देता है। - उपयोगकर्ता की हैशिंग नमक
यह एक स्ट्रिंग है स्थापित उपयोगकर्ता खाते के विरुद्ध किए गए अनुरोधों के लिए नमक हैश करने के लिए इस्तेमाल किया जाता है।
iPhone निम्नलिखित तरीके से वेब एपीआई के लिए कॉल कर देगा:
एपीआई विधि: खाता बनाएँ
क्लाइंट भेजता है:
- नया खाता डेटा (प्रयोक्ता नाम , पासवर्ड, पहला नाम, अंतिम नाम, आदि ..)
- आवेदन आईडी
- यूटीसी टाइमस्टैम्प
- यूटीसी टाइमस्टैम्प + आवेदन आईडी हैश आवेदन के हैशिंग नमक के साथ
एपीआई रिटर्न नमकीन:
- नई उपयोगकर्ता की हैशिंग नमक
विचार यहाँ है कि, एक खाता बनाते समय , मैं एप्लिकेशन के हार्डकोडेड नमक का उपयोग कर सकता हूं क्योंकि यह एक बड़ा सुरक्षा जोखिम नहीं है यदि वह नमक कभी बाहर निकलता है (अपघटन या कुछ अन्य माध्यमों के माध्यम से)।
लेकिन उपयोगकर्ता के डेटा तक पहुंचने और संशोधित करने के तरीकों के लिए मैं केवल उस उपयोगकर्ता द्वारा स्वामित्व वाले नमक का उपयोग करूंगा ताकि इसका उपयोग हमलावर द्वारा दूसरों का प्रतिरूपण करने के लिए नहीं किया जा सके।
एपीआई विधि: जाओ खाता
(खातों वेब साइट पर बनाए गए, लेकिन अभी तक iPhone पर समन्वयित किया नहीं किया गया है के लिए उपयोगकर्ता के हैशिंग नमक प्राप्त करने के लिए प्रयोग किया जाता है यह तब होता है जब कोई उपयोगकर्ता की कोशिश करता है जब। आईफोन और आईफोन पर लॉग इन करता है यह पता लगाता है कि उसके पास उस उपयोगकर्ता नाम के लिए कोई रिकॉर्ड नहीं है।)
क्लाइंट भेजता है:
- प्रयोक्ता नाम
- पासवर्ड (अनुप्रयोग के हैशिंग नमक के साथ टुकड़ों में बांटा)
- अनुप्रयोग ID
- यूटीसी टाइमस्टैम्प यूटीसी टाइमस्टैम्प + आवेदन आईडी
- हैश आवेदन के हैशिंग साथ नमकीन नमक
एपीआई रिटर्न:
- मौजूदा उपयोगकर्ता की हैशिंग नमक
एपीआई विधि: प्रवेश करें (प्रमाणित)
क्लाइंट भेजता है:
- प्रयोक्ता नाम
- पासवर्ड (साथ टुकड़ों में बांटा उपयोगकर्ता के हैशिंग नमक)
- अनुप्रयोग ID
- यूटीसी टाइमस्टैम्प यूटीसी टाइमस्टैम्प + आवेदन आईडी
- हैश उपयोगकर्ता की हैशिंग नमक के साथ नमकीन
एपीआई रिटर्न:
- एपीआई उपयोगकर्ता पहुँच टोकन
एपीआई विधि: कोई भी आदेश (यानी पोस्ट, अद्यतन प्रोफाइल आदि बनाएँ, संदेश प्राप्त, ...)
क्लाइंट भेजता है:
- कमान डाटा
- एपीआई उपयोगकर्ता पहुँच टोकन
- अनुप्रयोग ID
- यूटीसी टाइमस्टैम्प
- के हैश यूटीसी टाइमस्टैम्प + एप्लिकेशन आईडी + एपीआई उपयोगकर्ता एक्सेस टोकन उपयोगकर्ता के हैशिंग नमक के साथ नमकीन
आपका प्रश्न जो मेरे लिए उपयोगी है, क्योंकि मैं कुछ ऐसा करने की कोशिश कर रहा हूं। मेरे पास एक सवाल है - जब कोई उपयोगकर्ता खाता बनाता है, तो आप उन्हें बिना किसी परेशानी के उपयोगकर्ता नाम और पासवर्ड भेज रहे हैं। ठीक लगता है क्योंकि यह सिर्फ एक बार है। लेकिन अगर फोन पहले से बनाए गए खाते में लॉगिन करने का प्रयास करता है, तो आप ऐप नमक के साथ अपना उपयोगकर्ता नाम और पासवर्ड हैश करें। क्या यह वास्तव में इसे फिर से भेजने से कहीं ज्यादा बेहतर है? मेरा मतलब है, मुझे पता है कि यह थोड़ा बेहतर है, लेकिन दो बार बिना छेड़छाड़ की जानकारी भेजना एक बार भेजने से ज्यादा असुरक्षित नहीं है। या क्या मैं कुछ न कुछ भूल रहा हूं? –
@AndrewBSchultz, आप सही हैं, और मैं उस पहले कॉल पर एन्क्रिप्ट नहीं कर रहा था। चूंकि यह एसएसएल है और चूंकि प्रारंभिक कॉल केवल एक बार होता है, एक्सपोजर का नगण्य जोखिम होता है। – Stoop
"अनछुए" जानकारी भेजना किसी भी समय असुरक्षित है। लेकिन वास्तविक बिंदु यह है कि संपूर्ण एपीआई एसएसएल के साथ सुरक्षित है, इसलिए सभी स्थानान्तरण एन्क्रिप्टेड हैं। सर्वर से क्लाइंट को उपयोगकर्ता के नमक को पास करना संदिग्ध है। इसका क्या मतलब है, वास्तव में? अन्य चीजों के अलावा, इसका मतलब है कि आप कई स्थानों पर पासवर्ड हैश की गणना कर रहे हैं, जिससे आपके पासवर्ड को हैशिंग एल्गोरिदम को अपग्रेड करना बहुत मुश्किल हो जाता है जब आप पाते हैं कि आपका मौजूदा टूटा हुआ है (और अंत में आप करेंगे)। एसएसएल के साथ सुरक्षित उपयोगकर्ता नाम और पासवर्ड पास करें, और सर्वर को हैशिंग करना है। – Craig