एपीआई कुंजी और गुप्त का उपयोग क्यों करें?

Question 1

मुझे कई एपीआई मिले जो उपयोगकर्ता को एपीआई कुंजी और एक गुप्त दोनों देते हैं । लेकिन मेरा सवाल यह है कि दोनों में क्या अंतर है?

मेरी नजर में, एक कुंजी पर्याप्त हो सकती है। कहो कि मेरे पास एक कुंजी है और केवल मैं और सर्वर इसे जानते हैं। मैं इस कुंजी के साथ एक HMAC हैश बनाता हूं और एक एपीआई कॉल करता हूं। सर्वर पर, हम एचएमएसी हैश को फिर से बनाते हैं और भेजे गए हैश के साथ तुलना करते हैं। यदि यह समान है, तो कॉल प्रमाणित है।

तो दो कुंजियों का उपयोग क्यों करें?

संपादित करें: या क्या एपीआई कुंजी का उपयोग एपीआई रहस्य को देखने के लिए किया जाता है?

Question 2

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

RSA सुरक्षा 2 मिलान कुंजी पर आधारित है। प्रत्येक उपयोगकर्ता के लिए एक सार्वजनिक कुंजी है, और हर कोई इसे जान सकता है (चाहिए)। एक निजी कुंजी भी है जो केवल उपयोगकर्ता को पता होनी चाहिए। सार्वजनिक कुंजी द्वारा एन्क्रिप्ट किया गया एक संदेश केवल निजी कुंजी, और वीजा वर्सा द्वारा डिक्रिप्ट किया जा सकता है।

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

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

एन्क्रिप्शन का यह रूप काफी कंप्यूटर गहन है, इसलिए कभी-कभी क्या किया जाता है RSA तकनीक के साथ एक बार "गुप्त कुंजी" को एन्क्रिप्ट करने के लिए, फिर गुप्त कुंजी के साथ शेष संदेश को एन्क्रिप्ट करें, फिर दूसरे फैशन में मेरे हस्ताक्षर को एन्क्रिप्ट करें। आप इस प्रक्रिया को उल्टा कर देते हैं, यदि संदेश और हस्ताक्षर पठनीय हैं, तो आप और केवल आप इसे पढ़ सकते हैं और आपको सुनिश्चित किया जाता है कि मैंने संदेश भेज दिया है।

या

आप अधिक विस्तृत विवरण के लिए इस लिंक पर जा सकते हैं।

एपीआई कीज़ और सीक्रेट कीज़ कैसे काम करते हैं?

Question 3

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

"कुंजी" आपकी उपयोगकर्ता आईडी है, और "गुप्त" आपका पासवर्ड है। वे सिर्फ "कुंजी" और "गुप्त" शब्दों का उपयोग करते हैं, क्योंकि उन्होंने इसे लागू किया है।

Question 4

सरल उत्तर, अगर मैंने इसे सही ढंग से समझा ...

यदि आप एन्क्रिप्शन के लिए अपनी एपीआई कुंजी का उपयोग करते हैं, तो सेवा को कैसे पता चलेगा कि कौन उनसे संपर्क कर रहा है? वे उस संदेश को कैसे डिक्रिप्ट करेंगे?

आप एपीआई कुंजी का उपयोग यह बताने के लिए करते हैं कि आप कौन हैं, यह वही है जो आप सादे पाठ में भेज रहे हैं। SECRET कुंजी जिसे आप किसी को नहीं भेजते हैं । आप बस इसे एन्क्रिप्शन के लिए उपयोग करते हैं। फिर आप एन्क्रिप्टेड संदेश भेजें। आप उस कुंजी को नहीं भेजते हैं जिसका उपयोग एन्क्रिप्शन के लिए किया गया था, जो उद्देश्य को हरा देगा।

Question 5

रहस्य और (सार्वजनिक) कुंजी क्या है, यह बताने वाले उत्तर हैं। यह एक सार्वजनिक-निजी कुंजी जोड़ी है जिसे वे भ्रमित करने वाले नाम देते हैं। लेकिन कोई नहीं कहता है कि एपीआई को दोनों की आवश्यकता क्यों है, और कई एपीआई आपको केवल एक रहस्य देते हैं! मैंने कभी भी किसी एपीआई के डॉक्स की व्याख्या नहीं की है कि उनके पास दो कुंजी क्यों हैं, इसलिए मैं जो सबसे अच्छा कर सकता हूं वह है अटकलें ...

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

लेकिन कई - वास्तव में यह सबसे अधिक लगता है - एपीआई आपके पास अनुरोधों में दोनों चाबियाँ भेजते हैं क्योंकि लोगों को अपने स्वयं के हस्ताक्षर करने की तुलना में आसान है; अन्यथा शुद्ध cURL उदाहरण नहीं हो सकते हैं! उस स्थिति में, उनका अलग होना व्यर्थ है। मुझे लगता है कि अलग-अलग कुंजियाँ सिर्फ उसी स्थिति में होती हैं जब वे एपीआई का उपयोग करके बाद में उनका लाभ उठाते हैं। या कुछ के पास एक ग्राहक पुस्तकालय है जो इसे अधिक सुरक्षित तरीके से कर सकता है।

Question 6

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

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

जानकारी का एक दूसरा टुकड़ा, या "गुप्त" होने से, आप पहले "कुंजी" का उपयोग करके उपयोगकर्ता या क्रेडेंशियल को देख सकते हैं, जो किसी समय के हमले के लिए असुरक्षित हो सकता है, फिर समय-सुरक्षित तुलना फ़ंक्शन का उपयोग करके मान का मान जांचें रहस्य"।

यहाँ पायथन के उस कार्य को लागू करना है:

https://github.com/python/cpython/blob/cd8295ff758891f21084a6a5ad3403d35dda38f7/Modules/_operator.c#L727

और यह परिवाद में उजागर किया गया है hmac(और शायद अन्य):

https://docs.python.org/3/library/hmac.html#hmac.compare_digest

यहां एक बात ध्यान देने वाली है कि मुझे नहीं लगता कि इस तरह का हमला उन मूल्यों पर काम करेगा जो देखने से पहले हैशेड या एन्क्रिप्ट किए गए हैं, क्योंकि जिन मूल्यों की तुलना की जा रही है, उनमें हर बार इनपुट स्ट्रिंग परिवर्तनों में एक चरित्र के बेतरतीब ढंग से बदलाव होते हैं। मुझे यहाँ इसकी अच्छी व्याख्या मिली ।

तब एपीआई कुंजियाँ संग्रहीत करने के लिए समाधान होंगे:

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

इनमें से, मुझे लगता है कि 3 सुरक्षा और सुविधा का सबसे अच्छा संतुलन है। मैंने इसे कई वेबसाइटों पर लागू किया है जब कुंजियाँ जारी की जा रही हैं।

इसके अलावा, मैं किसी भी वास्तविक सुरक्षा विशेषज्ञों को इस उत्तर की आलोचना करने के लिए आमंत्रित करता हूं। मैं बस इसे एक और चर्चा बिंदु के रूप में बाहर निकालना चाहता था।