मैं MQTT नेटवर्क में 2FA का उपयोग कैसे कर सकता हूं?

12

जब मैं संभव हो तो किसी नए उपकरण को ब्रोकर से कनेक्ट करने पर मैं 2FA (दो कारक प्रमाणीकरण) का उपयोग कैसे कर सकता हूं?

क्योंकि यह आसान लगता है, दूसरा कारक पहले एक सॉफ्टवेयर समाधान हो सकता है लेकिन मैं इस बात का स्वागत करता हूं कि हार्ड टोकन (RFID हो सकता है) को कैसे पेश किया जाए।

यह समझ में आता है अगर उपकरणों को केवल पहले कनेक्शन पर प्रमाणित करना चाहिए और सर्वर "पुराने" ग्राहकों को याद रखेगा।

विचार शायद असामान्य या अनुपयुक्त है - यदि यह एक बुरा विचार है, तो कृपया मुझे इसके कारण बताएं।

security mqtt authentication

— बेंस कौलिक्स
स्रोत

क्या आप बता सकते है आप कैसे लगता है कि एक युक्ति कर सकता है 2FA के बाद से यह है एक डिवाइस?

— गॉफालिट

@Goufalite उदाहरण के लिए जब मैं एक नया उपकरण स्थापित करता हूं, तो मुझे मैन्युअल रूप से एक कुंजी प्रदान करनी होगी (उदाहरण के लिए एक RFID टैग) जो प्रमाणीकरण के दौरान उपयोग किया जाएगा। जैसा कि सॉफ्टवेयर 2FA के लिए, मुझे नहीं पता कि क्या मेरे घर में सेवा की कुछ मानवता स्थापित की जा सकती है, जहां से नए उपकरण नरम टोकन का अनुरोध कर सकते हैं, कुछ निजी कुंजी सर्वर की तरह।

— बेंस कौलिक्स

8

आप एक दलाल प्रॉक्सी, या एक वेबसर्वर की जरूरत है ...

सबसे पहले, आप पूरी तरह से विशिष्ट विषयों 2FA का उपयोग कर प्रदर्शन करने के लिए (अपने ब्रोकर से जुड़ा एक प्रमाणीकरण सेवा कहीं जरूरत है /auth/RFID, ...)। यह तब क्लाइंट को जानकारी प्रकाशित करने की अनुमति देगा (नीचे देखें)।

पहली समस्या जो मैं यहाँ देख सकता हूँ, वह यह है कि इस विषय की सदस्यता लेने वाला कोई भी व्यक्ति उस विषय की जानकारी पढ़ सकता है, लेकिन आप विषयों को लॉक कर सकते हैं !

फिर आप अपने सभी उपकरणों को जानकारी प्रकाशित करने के लिए (बल) बता सकते हैं /proxy/mytopic। Mqtt के क्लाइंटआईड फीचर के साथ, ऑर्टिकल सर्विस यह जांच सकती है कि इस विषय से भेजे गए संदेश किसी प्रमाणित डिवाइस से हैं, जो पहले 2FA का उपयोग करते थे, और फिर /proxyout/mytopicपेलोड में डिवाइस की आईडी के साथ डिवाइस की ओर से अपना संदेश प्रकाशित करते हैं।

समस्या अब उन उपकरणों की जाँच कर रही है जो प्रमाणित होने पर संदेशों को प्राप्त कर सकते हैं, क्योंकि, अच्छी तरह से, MQTT सामूहिक प्रकाशन के बारे में है। प्रमाणिक सेवा के लिए प्रामाणिक उपकरणों की एक सूची होनी चाहिए और जांच करनी चाहिए कि क्या वे स्वागत योग्य हैं। फिर से, पेलोड एन्क्रिप्शन और डिक्रिप्शन डिवाइस-साइड ...

मुझे लगता है कि मेरा समाधान MQTT क्षमताओं पर बहुत अधिक है। इसलिए आपको सॉकेट या वेब सर्वर का उपयोग करना चाहिए ...

— Goufalite
स्रोत

@ tim3in देर से प्रतिक्रिया के लिए खेद है। आखिरकार यह 2,5 साल पहले दिया गया एक जवाब था ... शायद चीजें बदल गई हैं और यह सिर्फ एक सामान्य वास्तुकला का प्रस्ताव था। क्या आपने अपने समाधान के साथ एक पीओसी किया था?

— Goufalite

मैंने इसकी योजना बनाई है। क्या आप इसकी समीक्षा कर पाएंगे?

— टिम

7

आगामी MQTT v5 विनिर्देश AUTHनियंत्रण पैकेट के लिए समर्थन जोड़ता है , जो चुनौती / प्रतिक्रिया प्रमाणीकरण की अनुमति देता है। जैसा कि MQTT v5 अभी भी अंतिम रूप से समर्थन नहीं बदल सकता है, लेकिन यह मान लेना उचित है कि AUTH किसी न किसी रूप में बना रहेगा और इसका उपयोग करते हुए 2FA जोड़ा जा सकता है।

आप OASIS MQTT समिति के दस्तावेज़ पृष्ठ पर कल्पना के वर्तमान कार्य ड्राफ्ट देख सकते हैं ।

— ralight
स्रोत

5

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

यदि प्रमाणीकरण के दूसरे कारक को लागू करने के लिए, सबसे अच्छा तरीका दूसरे कारक के साथ एक कस्टम कनेक्ट संदेश भेजना चाहिए। इस मामले में CONNACK संदेश को प्रमाणीकरण के दूसरे कारक की सफलता या विफलता का उल्लेख करना चाहिए। इसलिए, ब्रोकर और क्लाइंट को विनिर्देश के ऊपर और ऊपर कस्टम संदेश लागू करना चाहिए।

— cogitoergosum
स्रोत

4

एमक्यूटीटी नेटवर्क में 2FA प्राप्त करने के लिए मैंने प्रमाणीकरण के लिए निम्नलिखित सेवाएं बनाई हैं जो ब्रोकर से जुड़ी हैं।

आईडी सत्यापनकर्ता
टोकन जेनरेटर
टोकन सत्यापनकर्ता

जब MQTT क्लाइंट SSL / TLS पर ब्रोकर से जुड़ता है, तो वह सबसे पहले अपनी खुद की ID को device_id टॉपिक पर प्रकाशित करता है, ID Verifier यह प्रमाणित करता है कि यह प्रामाणिक क्लाइंट है और फिर टोकन जेनरेटर मंगवाया गया है, जो एक टोकन बनाता है और लॉक किए गए टॉपिक device_token पर टोकन प्रकाशित करता है ।

क्लाइंट डिवाइस को यह टोकन मिलता है और इसे आगे एक विषय verify_token पर प्रकाशित करता है । जैसे ही टॉपिक को verify_token पर पब्लिश किया जाता है टोकन वेरिफायर टॉपिक device_token और verify_token पर वैल्यू की तुलना करता है यदि यह मैच करता है तो डिवाइस के id को वैरिफाइड डिवाइस पूल में ऐड करता है और डिवाइस को डेटा पब्लिश करने की अनुमति देता है। इससे सुरक्षा में सुधार होता है क्योंकि डेटा को प्रकाशित करने के लिए केवल सत्यापित उपकरण ही विषयों से जुड़े होते हैं।

जब मैंने कोई डेटा भेजा नहीं जा रहा है या डिवाइस पूल में क्लाइंट डिवाइस को ज़िंदा रखने के लिए क्लाइंट को सक्रिय रखने के लिए MQTT_KEEPALIVE कॉन्फ़िगरेशन विकल्प का उपयोग किया है, तो इसे डिवाइस पूल में जोड़ने के बाद इसे फिर से सत्यापित होने से रोका जाए। हालांकि सुरक्षा उद्देश्य के लिए मैं हर 24 घंटे में डिवाइस को 2FA करने में देरी करता हूं।

— tim3in
स्रोत

3

यह कैसे सुरक्षित है कि केवल सही ग्राहक को टोकन मिलता है?

— Helmar

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

— टिम 3

@ क्या आप इस पर अपनी टिप्पणी जोड़ना चाहेंगे? मैं अपने समाधान पर सभी के विचारों की सराहना करूंगा।

— टाइम 3

2

हां, लेकिन मुझे सभी टोकन प्रतिक्रियाओं को देखने के लिए '#' की सदस्यता लेने से रोकने के लिए क्या है

— हार्डबिल

@ हार्दिल विषय जिनके पास टोकन प्रतिक्रियाएं हैं, वे गौफलाइट के रूप में वर्णित हैं। इसलिए केवल प्रचलित उपकरण ही देख सकते हैं। पंजीकरण चरण में उपकरण विशिष्ट विषयों के लिए बाध्य होते हैं और प्रत्येक डिवाइस ने टोकन प्रतिक्रियाओं के लिए अलग-अलग विषयों को सौंपा है।

— टिम ३