एपीआई प्रमाणीकरण डिजाइन और हैकबिलिटी

Question

प्रश्न: क्या यह एपीआई प्रमाणीकरण तकनीक आसानी से हैकबल है?

apiKey = "123456789" 
apiCallId = "1256341451" 
apiSecret = "67d48e91ab2b7471d4be2a8c2e007d13" 
sig = md5(apiKey + apiCallId + apiSecret) = 09c297a354219f173bfc49c2e203ce03 

जहां

• apiKey: एक अनूठा पूर्णांक है कि मूल्य में वृद्धि हो रही किया जाना चाहिए (उदाहरण के लिए यूनिक्स समय स्टाम्प)
• apiSecret: उपयोगकर्ता
• apiCallId के लिए कुछ अद्वितीय पहचानकर्ता स्ट्रिंग केवल ज्ञात उपयोगकर्ता के लिए, और हमें - यूआरएल
• sig में पारित नहीं किया गया: इस API कॉल के "अनावश्यक" हस्ताक्षर - MD5 हैश

उदाहरण API कॉल:

http://api.domain.com/?apiKey=123456789&apiCallId=1256341451&sig=09c297a354219f173bfc49c2e203ce03&param1=x&param2=y 

यह API एक सत्र की आवश्यकता नहीं है, और नहीं बनाया गया है एक 3 पार्टी एक उपयोगकर्ता की ओर से उपयोग करने के लिए। इसके बजाए, इसका उपयोग उपयोगकर्ता द्वारा स्वयं किया जाना है।

मुझे वास्तव में इसकी सादगी पसंद है। apiCallId की अनूठी होने की आवश्यकता है, और हमेशा बढ़ने का मतलब है sig का पुन: उपयोग करना संभव नहीं है, इसलिए मुझे लगता है कि यह सुरक्षित है (रीप्ले हमलों के खिलाफ संरक्षित), लेकिन मैं एक विशेषज्ञ नहीं हूं।

अन्य एपीआई sig की गणना करते समय वर्णानुक्रमित क्रमबद्ध सभी जीईटी पैरामीटर का उपयोग करते हैं, लेकिन मुझे नहीं लगता कि apiCallId सहित यह क्यों आवश्यक है।

कृपया इसे लागू करने और रिलीज़ होने से पहले इसे आजमाएं और हैक करें।

मैं किसी भी प्रतिक्रिया, सुझाव और सुरक्षा शिक्षा का स्वागत करता हूं।

Answer 1

पैरामीटर की जांच न करने के अलावा, जो आप कर रहे हैं, वह काफी हद तक लगता है (जो एक बहुत बड़ी समस्या होगी)।

कुछ जो जो इसे कॉपी बुद्धिमान हो सकता है अपने डिजाइन के समान है Amazon Web Services Request Authentication Scheme

विशेष मेकअप में है सुनिश्चित करें कि मानदंडों के लिए आपके एन्कोडिंग स्कीम स्पष्ट और उलटी है, एक बिंदु पर अमेज़ॅन screwed this up। उनकी गलतियों से सीखें। :)

क्रिप्टोग्राफ़िक रूप से बोलते हुए, आप जो कर रहे हैं उसे हस्ताक्षर नहीं बल्कि एक संदेश प्रमाणीकरण कोड (मैक) कहा जाता है। एक मैक को गुप्त कुंजी साझा करने वाले किसी भी व्यक्ति द्वारा बनाया और सत्यापित किया जा सकता है (शब्द 'हस्ताक्षर' आमतौर पर डीएसए या आरएसए जैसी सार्वजनिक कुंजी योजनाओं के लिए आरक्षित है)। एमडी 5 (msg || के) एक ज्ञात और उचित रूप से सीन मैक है; मुझे यकीन नहीं है कि क्या आप इसे दुर्घटना या उद्देश्य से चूक गए हैं, लेकिन एक विधि जो सतह पर बराबर होती है, एमडी 5 (के || msg), काफी असुरक्षित है, क्योंकि एमडी 5 (और अधिकांश अन्य हैश में एक quirk फ़ंक्शंस) डिज़ाइन किए गए हैं, यदि आप एच (एम) को जानते हैं तो आप किसी भी एम 2 के लिए आसानी से एच (एम || एम 2) की गणना कर सकते हैं - इसलिए यदि आप एमडी 5 (के || param1 = 5) का उपयोग कर रहे थे, तो कोई इसे तार से खींच सकता है और फिर एमडी 5 (के || param1 = 5, param2 = 666) बनाएँ। (यह आपकी रुचि रखने की तुलना में शायद थोड़ा अधिक तकनीकी है, लेकिन इसे length extension property कहा जाता है)।

हालांकि एमडी 5 (के || msg) शायद 'ठीक' है, तो आप एचएमएसी जैसे कुछ का उपयोग करना बेहतर कर रहे हैं, क्योंकि इसे वास्तव में मैक के रूप में डिजाइन किया गया था। एमडी 5 में बहुत सारी समस्याएं हैं लेकिन मैक के रूप में इसके उपयोग को सीधे प्रभावित करने के लिए कुछ भी नहीं है (अभी तक - एमडी 4 इस तरह से तोड़ दिया गया है)। तो भविष्य के प्रूफिंग (और ऑडिट-प्रूफिंग) के लिए एसएचए -1 या एसएचए -256 के साथ एचएमएसी का उपयोग करें। यहां तक ​​कि यदि आप क्रिप्टो लाइब्रेरी में नहीं खींचना चाहते हैं, तो एचएमएसी काफी सरल है और SHA-1 और SHA-2 के लिए ज्ञात मान उपलब्ध हैं ताकि आप अपना कोड देख सकें।

Answer 2

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

MD5 (वर्णमाला पैरामीटर की सूची + APiKEY + callID + Secert + someLonginternalKey)

यकीन नहीं अगर मैं अपने प्रश्न का उत्तर लेकिन thats एपीआई के लिए सुरक्षा करने का एक और तरीका है

Answer 3

नहीं। अन्य पैरामीटर की अखंडता (आपके उदाहरण में param1 और param2) सुरक्षित नहीं है। एक हमलावर कॉल को रोक सकता है और इसे बदल सकता है क्योंकि उसे अग्रेषित करने से पहले उसे पसंद है। apiCallId केवल पहली कॉल के बदलाव की प्रतिलिपि रोकता है।

मैं कोई विशेषज्ञ नहीं हूं। अगर मैंने तुरंत देखा, तो शायद अन्य समस्याएं छिपी हुई हैं।

Answer 4

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

यदि आप रीप्ले हमले को रोकना चाहते हैं, तो आपको प्रत्येक अनुरोध में किसी प्रकार की यादृच्छिकता की आवश्यकता है। तो मैं निम्नलिखित सुझाव है:

सर्वर -> एपीआई: Nonce (= कुछ यादृच्छिक संख्या)

एपीआई -> सर्वर: पूर्वी नौसेना कमान (अस्थायी रूप से + डिजिटल हस्ताक्षर)

इस एन्क्रिप्टेड है सर्वर की सार्वजनिक कुंजी और डिजिटल हस्ताक्षर सर्वर की निजी कुंजी के साथ रखा गया है।

अब आपके पास रीप्ले हमला नहीं हो सकता है। हालांकि मध्य हमले में एक आदमी की समस्या अभी भी है, लेकिन इसे ठीक करना इतना छोटा नहीं है (लेकिन काफी करने योग्य)। तो सुरक्षा के स्तर के आधार पर आप चाहते हैं कि आप अपने तकनीकी उपायों को अनुकूलित कर सकें।