नई एपीआई कुंजी बनाने के लिए सबसे अच्छा तरीका क्या है?

Question

तो अब के आसपास विभिन्न सेवाओं के बहुत से, गूगल एपीआई, ट्विटर एपीआई, फेसबुक एपीआई, आदि।

प्रत्येक सेवा की एक API कुंजी होती है, जैसे:

AIzaSyClzfrOzB818x55FASHvX4JuGQciR9lv7q

सभी कुंजियाँ लंबाई में भिन्न होती हैं और जिन वर्णों में वे होते हैं, मैं सोच रही हूँ कि एपीआई कुंजी बनाने के लिए सबसे अच्छा तरीका क्या है?

मैं एक विशिष्ट भाषा के लिए नहीं कह रहा हूं, बस चाबियाँ बनाने के लिए सामान्य दृष्टिकोण, क्या उन्हें उपयोगकर्ताओं के ऐप, या एक हैश, या एक यादृच्छिक स्ट्रिंग के हैश, आदि के विवरण का एक एन्क्रिप्शन होना चाहिए, क्या हमें हैश एल्गोरिथ्म के बारे में चिंता करनी चाहिए (MSD, SHA1, bcrypt) आदि?

संपादित करें: मैंने कुछ दोस्तों (ईमेल / ट्विटर) से बात की है और उन्होंने छीन लिए गए डैश के साथ बस GUID का उपयोग करने की सिफारिश की है।

हालांकि यह मेरे लिए थोड़ा हैकिंग लगता है, लेकिन कुछ और विचारों को पाने की उम्मीद है।

Comments

मैंने यहाँ अधिक विवरणों में उत्तर दिया है .. कुंजियाँ बनाना और इसे hmac के रूप में उपयोग करना

— Anshu Kumar

Answer 1

क्रिप्टोग्राफी के लिए डिज़ाइन किए गए एक यादृच्छिक संख्या जनरेटर का उपयोग करें। फिर बेस -64 नंबर को एनकोड करें।

यह एक C # उदाहरण है:

var key = new byte[32];
using (var generator = RandomNumberGenerator.Create())
    generator.GetBytes(key);
string apiKey = Convert.ToBase64String(key);

Comments

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

— जेम्स विर्ज़बा

एक बेतरतीब ढंग से उत्पन्न एपीआई कुंजी को संग्रहीत करने में एक हैशेड पासवर्ड संग्रहीत करने के समान सुरक्षा विशेषताएं हैं। ज्यादातर मामलों में, यह ठीक है। जैसा कि आप सुझाव देते हैं, यह संभव है कि बेतरतीब ढंग से उत्पन्न संख्या को नमक माना जाए और इसे सर्वर सीक्रेट के साथ हैशिंग किया जाए; हालाँकि, ऐसा करने से, आप हर सत्यापन पर हैश ओवरहेड को उकसाते हैं। सभी API कुंजियों को अमान्य किए बिना सर्वर रहस्य को अमान्य करने का कोई तरीका भी नहीं है।

— एडवर्ड ब्रे

अच्छा समाधान है, लेकिन आपको एपीके से पहले var कीवर्ड की आवश्यकता है :) शायद var apiKey = Convert.ToBase64String (कुंजी);

— दाविद ओहिया

@ JohnM2 राइट। मैं इसे खुले-आम छोड़ रहा था, क्योंकि apiKeyइसे कहीं और घोषित किया जा सकता था। मैंने स्पष्टता के लिए प्रकार जोड़ा।

— एडवर्ड ब्रे

@JamesWierzba अगर हमला आपके डेटाबेस में पहले से ही है, तो उन्हें आपके एपीआई तक असुरक्षित पहुंच प्राप्त करना संभवतः आपकी चिंताओं से कम है ...

— जॉन स्टोरी

Answer 2

API कुंजियों में वे गुण होने चाहिए जो वे:

• विशिष्ट API उपयोगकर्ता की विशिष्ट पहचान करें - "API कुंजी" का "कुंजी" भाग
• उस उपयोगकर्ता को प्रमाणित करें - अनुमान नहीं लगाया जा सकता है / जाली है
• यदि कोई उपयोगकर्ता दुर्व्यवहार करता है, तो उसे रद्द किया जा सकता है - आम तौर पर वे एक डेटाबेस में कुंजी डालते हैं जो एक रिकॉर्ड हटाए जा सकते हैं।

आमतौर पर आपके पास हज़ारों या लाखों API कुंजियाँ नहीं होतीं, इसलिए उन्हें इसकी आवश्यकता नहीं होती है:

• विश्वसनीय रूप से एपीआई उपयोगकर्ता के बारे में जानकारी संग्रहीत करें क्योंकि यह आपके डेटाबेस में संग्रहीत किया जा सकता है।

जैसे, API कुंजी जनरेट करने का एक तरीका दो जानकारी लेना है:

1. विशिष्टता की गारंटी के लिए एक सीरियल नंबर
2. कुंजी को पैड करने के लिए पर्याप्त यादृच्छिक बिट्स

और एक निजी रहस्य का उपयोग करके उन पर हस्ताक्षर करें।

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

एक अच्छा GUID जनरेटर एक वृद्धावस्था काउंटर का एक बहुत अच्छा सन्निकटन है, यदि आपको कई डेटा केंद्रों से कुंजी उत्पन्न करने की आवश्यकता है या सीरियल नंबर असाइन करने के लिए एक अच्छा वितरित तरीका नहीं है।

---

या एक यादृच्छिक स्ट्रिंग का हैश

हैशिंग जालसाजी को नहीं रोकता है। हस्ताक्षर करना इस बात की गारंटी है कि कुंजी आपके पास से आई है।

Comments

क्या आपके एल्गोरिथ्म का हस्ताक्षर करने वाला कदम आवश्यक है यदि एक क्लाइंट द्वारा प्रस्तुत एपीआई कुंजी को एपीआई प्रदान करने वाले सर्वर पर पहले से पंजीकृत एपीआई कुंजी के डेटाबेस के खिलाफ जांच की जाती है? यदि सर्वर एक प्रदान करने वाली कुंजी है, तो हस्ताक्षर करने की तरह यह बेमानी होगा।

— सैपनीन

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

— माइक सैम्युअल

@MikeSamuel यदि एपीआई कुंजी पर हस्ताक्षर किए गए हैं और आप डेटाबेस के लिए एक गोल यात्रा नहीं करते हैं तो तब क्या होता है जब कुंजी को निरस्त कर दिया जाता है लेकिन फिर भी एपीआई का उपयोग किया जाता है?

— अभ्युदय जैन

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

— माइक सैमुअल

Answer 3

मैं यूयूआईडी का उपयोग करता हूं, बिना डैश के निचले मामले में स्वरूपित।

सृजन आसान है क्योंकि अधिकांश भाषाओं ने इसे बनाया है।

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

Comments

यह न समझें कि यूयूआईडी का अनुमान लगाना कठिन है; उन्हें सुरक्षा क्षमताओं के रूप में उपयोग नहीं किया जाना चाहिए (UUID कल्पना RFC4122 खंड 6 )। एपीआई कुंजी को एक सुरक्षित यादृच्छिक संख्या की आवश्यकता होती है, लेकिन यूयूआईडी सुरक्षित रूप से अप्राप्य नहीं हैं ।

— एडवर्ड ब्रे

@EdwardBrey UUID uuid = UUID.randomUUID();जावा में क्या है ? क्या आप कह रहे हैं कि यादृच्छिक पर्याप्त अच्छा नहीं है?

— माइक्रो

@MicroR एक यादृच्छिक UUID केवल तभी सुरक्षित होता है जब इसे बनाने के लिए उपयोग किया जाने वाला यादृच्छिक संख्या जनरेटर क्रिप्टोग्राफिक रूप से सुरक्षित हो और 128 बिट पर्याप्त हो। यद्यपि UUID RFC को एक सुरक्षित यादृच्छिक संख्या जनरेटर की आवश्यकता नहीं होती है, एक दिया गया कार्यान्वयन एक का उपयोग करने के लिए स्वतंत्र है। RandomUUID के मामले में , एपीआई डॉक्स विशेष रूप से बताता है कि यह "क्रिप्टोग्राफिक रूप से मजबूत छद्म यादृच्छिक संख्या जनरेटर" का उपयोग करता है। ताकि विशेष रूप से कार्यान्वयन 128-बिट एपीआई कुंजी के लिए सुरक्षित हो।

— एडवर्ड ब्रे

Answer 4

यदि आप केवल अल्फ़ान्यूमेरिक वर्णों के साथ एक एपीआई कुंजी चाहते हैं, तो आप बेस 64-यादृच्छिक दृष्टिकोण के एक संस्करण का उपयोग कर सकते हैं , केवल इसके बजाय एक बेस -62 एन्कोडिंग का उपयोग कर सकते हैं। आधार-62 एनकोडर पर आधारित है यह ।

public static string CreateApiKey()
{
    var bytes = new byte[256 / 8];
    using (var random = RandomNumberGenerator.Create())
        random.GetBytes(bytes);
    return ToBase62String(bytes);
}

static string ToBase62String(byte[] toConvert)
{
    const string alphabet = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
    BigInteger dividend = new BigInteger(toConvert);
    var builder = new StringBuilder();
    while (dividend != 0) {
        dividend = BigInteger.DivRem(dividend, alphabet.Length, out BigInteger remainder);
        builder.Insert(0, alphabet[Math.Abs(((int)remainder))]);
    }
    return builder.ToString();
}

Answer 5

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

उदाहरण के लिए, विंडोज के पहले के संस्करणों ने पूर्वानुमानित GUID का उत्पादन किया था, लेकिन यह एक पुरानी कहानी है।

Comments

विंडोज 2000 यादृच्छिक संख्याओं का उपयोग कर GUIDs में बदल गया । हालाँकि, इस बात की कोई गारंटी नहीं है कि यादृच्छिक संख्या की भविष्यवाणी नहीं की जा सकती है। उदाहरण के लिए, यदि कोई हमलावर अपने लिए कई एपीआई कुंजी बनाता है, तो भविष्य में किसी अन्य उपयोगकर्ता की एपीआई कुंजी उत्पन्न करने के लिए उपयोग किए जाने वाले यादृच्छिक संख्या को निर्धारित करना संभव हो सकता है। सामान्य तौर पर, यूयूआईडी को सुरक्षित रूप से अनुचित नहीं मानते हैं ।

— एडवर्ड ब्रे