2016-03-25 9 views
6

मैं एक वेब ऐप पर काम कर रहा हूं जहां उपयोगकर्ता की पहचान पूरी तरह से अज्ञात रखने के तरीके पर विचार कर रहा था। हैक होने से डेटाबेस हासिल करने पर ध्यान केंद्रित छोड़कर -उपयोगकर्ताओं को बेनामी रखना - सुरक्षित डीबी केवल विकल्प - सामान्य विचार?

हालांकि मैं निष्कर्ष पर आए हैं, वहाँ बहुत ज्यादा मैं क्या कर सकते हैं नहीं है।

क्या यह स्टैक ओवरफ्लो पर सामान्य आम सहमति है या क्या कोई तरीका है जो मुझे याद आ सकता है?

तो मैं के बारे में सोचा:

  • एक सीधे bcrypt हैश और नमक लेकिन इस तो विभिन्न कारणों के लिए उपयोगकर्ता से संपर्क करने की ओर जाता है।
  • पासवर्ड रीसेट करता है। मैं वसूली प्रश्न/उत्तर बचा सकता हूं लेकिन फिर निश्चित रूप से उत्तर पढ़ने योग्य होने की आवश्यकता होगी ताकि चीजों को हराया जा सके।
  • एक और बिंदु यह था कि वे उन सुरक्षा प्रश्नों या उपयोगकर्ता नाम को भूल गए थे जिन्हें मैंने पंजीकरण पर उत्पन्न किया था। उन्हें किसी खाते से जोड़ने का कोई तरीका नहीं है।
  • यह भी ध्यान में आया (मान लीजिए कि मैंने उपरोक्त विजय प्राप्त की है) डुप्लिकेट उपयोगकर्ताओं को प्रतिबंधित कर रहा है। यदि मैंने खोज/नमकीन खोज के माध्यम से प्रसंस्करण पर काफी 'भारी' होगा? मैं बस इस्तेमाल की गई ईमेल की एक लंबी सूची रख सकता था लेकिन फिर फिर से इस मुद्दे को किसी मौजूदा खाते से जोड़ रहा था?

आपके विचारों को सुनना दिलचस्प है।

धन्यवाद।

+0

क्या मैं यह सोचने में सही हूं कि आप चाहते हैं कि उपयोगकर्ता ईमेल/पासवर्ड से लॉग इन करें और फिर आप चाहते हैं कि आपका सिस्टम अपनी सभी व्यक्तिगत जानकारी एन्क्रिप्ट करे ताकि वे अज्ञात हों? –

+0

आप उपयोगकर्ता सत्यापन के लिए Sqrl का उपयोग करने पर विचार कर सकते हैं। https://www.grc.com/sqrl/sqrl.htm। पासवर्ड के बजाय उपयोगकर्ता सत्र पर हस्ताक्षर करने के लिए सिस्टम सार्वजनिक कुंजी क्रिप्टो का उपयोग करता है। आप क्लाइंट गुप्त से ली गई कुंजी के आधार पर उपयोगकर्ता की पहचान करते हैं। इस तरह आपको पासवर्ड खोने के बारे में चिंता करने की ज़रूरत नहीं है। चूंकि खोने के लिए कोई पासवर्ड नहीं है। मैंने कोशिश नहीं की है, लेकिन स्टीव गिब्सन को अपने पॉडकास्ट पर सुनने से यह अच्छा लगता है। –

+0

@AaronFranco हाँ यह सही है। – userMod2

उत्तर

3

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

टोकन का उपयोग करके, ऐप सर्वर से आने वाले एन्क्रिप्टेड डेटा को डिक्रिप्ट कर सकता है। इसलिए, टोकन का उपयोग करके सभी डेटा एन्क्रिप्ट किया जा सकता है। फिर, यदि पासवर्ड परिवर्तन की आवश्यकता होती है, तो आप एक नया पासवर्ड उत्पन्न करते समय एक नया टोकन उत्पन्न कर सकते हैं, और आपके सर्वर को डिक्रिप्ट करना होगा और फिर नए टोकन का उपयोग करके अपने सभी डेटा को फिर से एन्क्रिप्ट करना होगा। इस तरह, आपके पास एसएसएल का उपयोग करते समय एन्क्रिप्टेड सभी सर्वर फाइलें, कोड और डेटाबेस हो सकते हैं, इसलिए जब तक यह प्रदर्शन के लिए उपयोगकर्ता तक नहीं पहुंच जाता तब तक सभी डेटा अज्ञात होंगे। सर्वर से आने वाले किसी भी डेटा को डिक्रिप्ट करने के लिए टोकन प्राप्त करने का एकमात्र तरीका उपयोगकर्ता लॉग इन करना होगा। इससे सर्वर प्रदर्शन में काफी कमी आएगी।

इस तकनीक का उपयोग अपने माइक्रोचिप्स में एटमेल द्वारा डिवाइस से क्लाउड तक 100% एन्क्रिप्शन करने के लिए किया जाता है। जो एक चिप के लिए समझ में आता है क्योंकि उपयोगकर्ता को इसके साथ बातचीत करने की ज़रूरत नहीं है। वेबपैस के मामले में, प्रदर्शन के लिए डेटा को डिक्रिप्ट करने के लिए कुछ तरीका होना चाहिए। जो संभावनाओं को सीमित करता है। https://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services https://www.fourmilab.ch/javascrypt/javascrypt.html

यहाँ Atmel चिप जैसा कि ऊपर उल्लेख सुरक्षा विधि का उपयोग करता है के लिए एक लिंक है:

यहाँ कि ऐसा करने में उपयोगी हो सकता है लिंक के एक जोड़े हैं। http://www.atmel.com/products/security-ics/cryptoauthentication/

+0

दिलचस्प - यह देख सकता है कि यह कैसे काम करेगा हालांकि उपयोगकर्ता को अब उनके ईमेल/मोबाइल की बजाय टोकन याद रखना होगा। मुझे लगता है कि टोकन एक साधारण में बनाया जा सकता है? – userMod2

+0

उपयोगकर्ता कभी टोकन नहीं देखता है। वे आपके सर्वर से टोकन लाने के लिए केवल ईमेल और पासवर्ड का उपयोग करते हैं। टोकन एकमात्र चीज सर्वर से भेजी जाएगी जो एन्क्रिप्ट नहीं की जाएगी। –

+0

आह ठीक है - लेकिन सर्वर साइड/डीबी पर अभी भी टोकन से उपयोगकर्ता के लिए एक लिंक है? – userMod2

2

ठीक है, पूरी तरह से अज्ञात होने का एकमात्र तरीका ऑनलाइन कभी नहीं जाना है। कुछ भी नहीं, और मेरा मतलब कुछ भी नहीं है, पूरी तरह से सुरक्षित है। किसी भी हैश, एन्क्रिप्शन, डीबी, आदि क्रैक किया जा सकता है। यदि कोई दुर्भावनापूर्ण "हैकर" वास्तव में जानकारी चाहता है तो उसे इससे कोई फर्क नहीं पड़ता कि आप कितनी मेहनत करते हैं।

अब कहा गया है कि, जो आप वर्णन करते हैं वह संभव है, उदाहरण के लिए टोर, प्रॉक्सी, वीपीएन, आदि देखें यदि आप उपयोगकर्ता से ली गई हर जानकारी को पूरी तरह से एन्क्रिप्ट करते हैं, तो आप कुछ में हैं। हालांकि कुछ गलत होने पर यह एक मुद्दा बन सकता है, उदाहरण के लिए आप ट्रिपल हैश, और बहु-नमक सभी हैंश कहते हैं और ऐसी समस्या में आते हैं जहां आपको उपयोगकर्ताओं की जानकारी को डिक्रिप्ट करने की आवश्यकता होती है (तर्क के लिए, एफबीआई अनुरोध करता है) एक एमडी 5 एन्क्रिप्शन वाला एकल नमकीन हैश 2-5 घंटे से डिक्रिप्ट/क्रैक तक कहीं भी ले सकता है। आपने आईपी, उपयोगकर्ता नाम, पासवर्ड, ईमेल, नाम इत्यादि सहित सभी जानकारी एन्क्रिप्ट की है, अब आप एक उपयोगकर्ता को डिक्रिप्ट करने के लिए एक दिन और अधिक संभावित रूप से देख रहे हैं।

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

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

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

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