2017-04-02 9 views
6

यह मूर्खतापूर्ण प्रश्न की तरह लग सकता है, क्योंकि पाठ्यक्रम के पासवर्ड को धोने की आवश्यकता होती है और मूल को कभी भी स्टोर नहीं किया जाता है।क्या एपीआई रहस्यों को धोया जाना चाहिए?

हालांकि, एपीआई रहस्यों के लिए, आम तौर पर मैं उन्हें साइन अप करते समय स्पष्ट रूप से प्रदर्शित करता हूं।

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

निश्चित रूप से एपीआई कुंजी पासवर्ड के रूप में संवेदनशील हैं?

क्या यह प्रदाता पक्ष से है, तो आप आश्वस्त हो सकते हैं कि पर्याप्त मजबूत पासवर्ड उत्पन्न किया जा रहा है? यदि ऐसा है, तो यह कोई सुरक्षा प्रदान नहीं करता है कि आपके डेटाबेस से समझौता किया गया है।

या शायद यह इसलिए है क्योंकि यदि आप टोकन आधारित प्रमाणीकरण का उपयोग कर रहे हैं, तो आप या तो पासवर्ड अनुदान प्रकार कर रहे हैं, जिसके लिए आपको क्लाइंट आईडी और गुप्त, या रीफ्रेश टोकन के साथ अपने क्रेडेंशियल भेजने की आवश्यकता है, इसलिए उपयोगकर्ता पहले ही समझौता किया गया है?

उत्तर

4

मैं इस के लिए कुछ संभव जवाब कल्पना कर सकते हैं:

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

बीटीडब्ल्यू, मैं आखिरी बिंदु के बारे में बहुत गंभीर हूं। सच्चाई यह है कि बहुत अच्छे विचार वास्तविकता नहीं बन जाते हैं जब तक कि उनके पीछे समर्थन का एक महत्वपूर्ण द्रव्यमान न हो। उदाहरण के तौर पर, मैंने एक बार संबंधित विषय - protecting user confidential information by hashing it in the database के बारे में ब्लॉग किया था, लेकिन एक वैध तरीके से जब यह वैध उपयोगकर्ता लॉग इन करता है तो इसे पुनर्प्राप्त किया जा सकता है। मैंने एशले मैडिसन को एक उदाहरण के रूप में उपयोग किया - उस मामले में, हैकर्स ईमेल पते के बाद अधिक थे , फोन नंबर, और पासवर्ड से भौतिक पते। तो जब हैकर्स ने डेटाबेस को छीन लिया, तो वे तुरंत वही चाहते थे जो वे चाहते थे, और वे बीसीआरपीटी एन्कोडेड पासवर्ड के बारे में कम ख्याल रख सकते थे (वास्तव में, कुछ पुराने पासवर्ड केवल एमडी 5 के साथ एन्कोड किए गए थे!) दुर्भाग्य से, इस तरह की अवधारणाओं में पर्याप्त नहीं है उन्हें एक वास्तविकता बनाने के लिए धक्का। वास्तविक दुनिया में भी शून्य-ज्ञान वेब डिज़ाइन बहुत कम हैं।

+0

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

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

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