मोंगोडीबी का उपयोग करके _ids को "गुप्त डेटा" (उदाहरण के लिए, ओथ टोकन) के रूप में उत्पन्न किया गया है

Question

क्या मोंगोडीबी _id क्षेत्र गुप्त डेटा के रूप में कार्य करने के लिए पर्याप्त यादृच्छिक/अनुपयोगी हैं?

उदाहरण के लिए: यदि मैं सर्वर-साइड ओएथ का निर्माण कर रहा हूं, तो क्या मैं उपयोगकर्ता के लिए ओथ टोकन के रूप में _id का उपयोग कर सकता हूं? मैं सफाई के कारण ऐसा करना चाहता हूं & सूचकांक यह डेटाबेस देता है (उदाहरण के लिए, "tokens._id" => oauth_token)।

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

Answer 1

संक्षेप में, नहीं। मोंगो ObjectIds अनुमान लगाना आसान है। विशेष रूप से, उच्च भार के तहत, ये लगातार संख्याएं होती हैं, क्योंकि टाइमस्टैम्प, मशीन और प्रक्रिया आईडी नहीं बदलती है। आप the structure of Objectid को देखें, तो वे

a 4-byte timestamp, 
a 3-byte machine identifier, 
a 2-byte process id, and 
a 3-byte counter, starting with a random value. 

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

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

इसके बजाय एक क्रिप्टोग्राफ़िक रूप से मजबूत छद्म यादृच्छिक संख्या जनरेटर का उपयोग करें और उस से टोकन बनाएं। उदाहरण के लिए, .NET में, RNGCryptoServiceProvider मनमाने ढंग से यादृच्छिक डेटा बनाने की अनुमति देता है।

एक sidenote के रूप में, मैं दो कारणों के लिए, अपने OAuthTokens चारों ओर एक अतिरिक्त क्रिप्टोग्राफिक आवरण के लिए सुझाव देते हैं:

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

बी) ग्राहक टोकन का अनुरोध कर सकते हैं। हालांकि यह एक आवश्यकता नहीं है, मुझे पता है कि लगभग सभी प्रणालियों हर बार विभिन्न टोकन लौटते हैं (इससे कोई फर्क नहीं पड़ता कि वे स्वयं प्रमाणित हैं या नहीं)। आमतौर पर, ऐसा इसलिए होता है क्योंकि टोकन की सीमित वैधता अवधि होती है। यह वही वैधता अवधि नहीं है जिसे ओथ अनुदान है।

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

Answer 2

यह सोचना संभव है कि यह बेहद मुश्किल है। आप वास्तव में अधिक अन्य OAuth टोकन अनुमान लगाने के लिए बेहतर भाग्य हो सकता है।

यह एक उदाहरण है कि यह कितना कठिन हो सकता है कि इसमें पीआईडी ​​है। यदि आप PHP या किसी चीज़ जैसी भाषा का उपयोग कर रहे हैं तो पीआईडी ​​प्रत्येक PHP प्रक्रिया में बदल जाती है, जिसका अर्थ है कि प्रत्येक _id संभावित रूप से अपना स्वयं का चल रहा पीआईडी ​​हो सकता है और पूरी तरह से और पूरी तरह यादृच्छिक हो सकता है, बेशक यह निर्भर करता है कि आप किस मोड में PHP चलाते हैं; अगर fcgi मोड में तो पीआईडी ​​स्थिर हो सकता है।

महासाइन आईडी भी एक और है। अधिकांश वेबसाइटों में अपने डेटाबेस के लिए सर्वर के ऑटो स्केलिंग क्लस्टर होते हैं, यहां तक ​​कि भारी लोड आदि के तहत भी एकमात्र असली अनुमानित परिवर्तनीय बहुत सारे मामलों में टाइमस्टैम्प होता है और फिर भी, चूंकि यह मिलीसेकंड स्तर पर है, फिर भी यह अनुमान लगाने में बहुत आसान नहीं है ; आपको उचित तरीके से समय निकालने के लिए साइट को एल्गोरिदम बनाने के लिए कितना ट्रैफ़िक बनाना था, यह जानने की आवश्यकता है। निस्संदेह उस जानकारी को पहली जगह में सजाए जाने का एकमात्र तरीका वास्तव में इसके _id को प्राप्त करना है, 22 पकड़ें।

हालांकि, माना जाता है कि एकमात्र तरीका है कि मैं _id को मजबूर करने के लिए ब्रूट के बारे में सोच सकता हूं, पर्याप्त कंप्यूटिंग पावर प्राप्त करना है ऑब्जेक्ट आईडी के सभी ऑब्जेक्ट्स को फिर से चालू करें (ऑब्जेक्टआईडी के चर के यादृच्छिकता पर विचार करने के लिए यहां ट्रिलियन/अनंत हो सकते हैं) और फिर प्रत्येक ऐप आईडी में आपको पिंग कर सकते हैं (आपको ओएथ टोकन और एक ऐप आईडी हमेशा पूछना चाहिए) डेटाबेस जो फिर से रहस्य का एक और स्तर प्रदान करता है।

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