क्या उसी लैपटॉप पर TOTP वाकई दूसरा कारक है?
VPN लैपटॉप पर कोड जनरेटर एक स्वामित्व कारक है जो उसी समझौता-सीमा के भीतर बैठता है। पहले बीज और सत्र का पता लगाएँ।
ऐसे VPN क्लाइंट में साइन इन करें जो पहले पासवर्ड और फिर छह अंकों का कोड माँगता है, और दो संकेत दो स्वतंत्र बाधाओं जैसे लगते हैं। कारक के प्रकार से गिनें तो वे वही हैं: पासवर्ड वह है जो आप जानते हैं, कोड वह है जो आपके पास है। एक समझौता-ग्रस्त लैपटॉप क्या उजागर करता है, उससे गिनें तो वे एक ही सीमा में सिमट सकते हैं, क्योंकि जो आपके पास है वह उसी मशीन की फ़ाइल है जिसमें आप टाइप कर रहे हैं। इन दो गणनाओं के बीच का अंतर इसी विवेचन का विषय है।
पासवर्ड फ़ील्ड से कोड बॉक्स तक एक लॉगिन का पता लगाएँ
क्रम देखें, लेबल नहीं। क्लाइंट पासवर्ड भेजता है, सर्वर उत्तर देता है कि दूसरा प्रमाण आवश्यक है, और क्लाइंट छह या आठ अंकों के लिए फ़ील्ड खोलता है। उस फ़ील्ड के पीछे एक जनरेटर ऐप्लिकेशन है जिसके पास साझा रहस्य और एक घड़ी है। वह रहस्य और वर्तमान समय-चरण से एक मान गणता है, और सर्वर रहस्य की अपनी प्रतिलिपि से वही मान फिर से गणता है।
दोनों पक्षों के पास वही कुंजी-सामग्री है। यही सममिति वह हिस्सा है जो लोग कोड को रहस्य कहते समय छोड़ देते हैं: प्रदाता आपके कोड भी बना सकता है, इसीलिए बीज किसी भी एकल आउटपुट से अधिक मूल्यवान है। लीक हुआ कोड एकबारगी मान है; उसे बनाने वाला बीज स्थायी क्रेडेंशियल है जो बदले जाने तक वैध मान बनाता रहता है।
सक्रियण प्रवाह का दूसरा आधा है। जो जनरेटर डिवाइस पासकोड, बायोमेट्रिक अनुरोध या एन्क्रिप्टेड कंटेनर से खुलता है, वह स्वामित्व का प्रमाण और कुछ और देता है। जो बिना एन्क्रिप्शन चलता है और ऑपरेटिंग सिस्टम सत्र से खुलता है, वह केवल फ़ाइल देता है। वही ऐप्लिकेशन नामांकन कैसे हुआ, इस पर निर्भर करते हुए दोनों व्यवस्थाएँ दे सकता है, इसलिए तैनाती का निर्णय उसी चरण में है, ऐप के विपणन पृष्ठ में नहीं।
तय करें कि कोड वास्तव में क्या सिद्ध करता है
मानकों की भाषा यहाँ असामान्य रूप से स्पष्ट है, और सीधे पढ़ने योग्य है। NIST की प्रमाणक मार्गदर्शिका सॉफ़्टवेयर-आधारित OTP जनरेटर को प्रमाणक के रूप में सूचीबद्ध करती है, सक्रियण कारक वाले बहु-कारक OTP से एक-कारक OTP को अलग करती है, और कहती है कि OTP प्रमाणीकरण फ़िशिंग-प्रतिरोधी नहीं है। इन तीनों में से प्रत्येक वाक्य बदल देता है कि संकेत के बारे में आप क्या दावा कर सकते हैं।
फ़िशिंग-प्रतिरोधी न होना सबसे तीखा किनारा है। फ़ील्ड में टाइप किया गया कोड किसी और के फ़ील्ड में, वास्तविक समय में, ऐसे व्यक्ति द्वारा टाइप किया जा सकता है जिसे ऐसा करने के लिए राज़ी किया गया हो। खिड़की छोटी है, जो उपयोगी प्रयासों की संख्या घटाती है पर तकनीक को बंद नहीं करती। यदि आपकी आवश्यकता में उसका प्रतिरोध शामिल है, तो जनरेटर कहीं भी चले, OTP गलत आदिम है।
एक-कारक बनाम बहु-कारक दूसरा भेद है। सक्रियण चरण के बिना दिखने वाला कोड फ़ाइल पर स्वामित्व सिद्ध करता है और कुछ नहीं, और फ़ाइल उतनी ही मज़बूत है जितना वह खाता जो उसे पढ़ सकता है। सक्रियण कारक जोड़ें तो दावा बेहतर होता है, फिर भी वह लॉगिन पर प्रस्तुत प्रमाण का वर्णन करता है, उसे बनाने वाली मशीन के पृथक्करण का नहीं।
देखें कि समझौता-ग्रस्त लैपटॉप कहाँ तक पहुँच सकता है
वर्कस्टेशन पर कोड निष्पादन रखने वाला हमलावर केवल उस फ़ील्ड को पढ़ने तक सीमित नहीं है जिसमें आप टाइप कर रहे हैं। सफल लॉगिन के बाद स्थापित सत्र सामान्यतः टोकन या कुकी होता है, और टोकन बिना किसी कोड के दूसरी मशीन से इस्तेमाल किया जा सकता है। यदि यही वह क्षमता है जिसके विरुद्ध आप रक्षा कर रहे हैं, तो लॉगिन पर दूसरा संकेत जोड़ना हमले के चरणों की संख्या बदलता है, परिणाम नहीं।
| Arrangement | What it adds at login | What it leaves inside the laptop boundary |
|---|---|---|
| Password plus TOTP app on the same machine | A possession proof the password alone does not supply | The seed, the unlock step and the authenticated session |
| TOTP app on a separate phone | Seed storage outside the workstation | Session cookies, the typed password and any prompt that can be proxied |
| Hardware key with a signed challenge | A per-login signature bound to the origin | Whatever the browser and the workstation are already trusted to do |
तीसरे स्तंभ को ईमानदार स्तंभ पढ़ें। ऊपर की हर व्यवस्था वर्कस्टेशन की विश्वास-सीमा के भीतर कुछ छोड़ती है, क्योंकि सत्र वहीं इस्तेमाल होता है। जो बदलता है वह यह है कि दीर्घकालिक रहस्य उस सीमा के साथ यात्रा करता है या बाहर रहता है, और क्या प्रमाण किसी विशेष मूल से बंधा है ताकि नक़ली पृष्ठ उसे आगे न भेज सके।
दो छोटे विवरण उसी चित्र के हैं। कोड अपनी स्वीकृति-खिड़की के दौरान वैध रहता है, अक्सर तीस सेकंड और घड़ी के विचलन के लिए सहनशीलता, इसलिए पकड़ा गया मान उस खिड़की के भीतर दोबारा चलाया जा सकता है, जब तक सत्यापनकर्ता पुनःउपयोग अस्वीकार न करे। और नया जनरेटर स्थापित करना पहले से प्रमाणित सत्रों को समाप्त नहीं करता, इसलिए पुराना सत्र उस क्रेडेंशियल परिवर्तन से अधिक जीता है जिसे घटना को सीमित करना था।
जनरेटर को केवल वहीं ले जाएँ जहाँ अलगाव मदद करता है
कोड जनरेटर को फ़ोन पर रखना एक विशेष विफलता के लिए वास्तविक सुधार है: चोरी हुआ लैपटॉप अब दोनों प्रमाण नहीं ढोता। यह लैपटॉप पर सत्र-अपहरण के लिए कुछ नहीं करता, फ़िशिंग पृष्ठ में कोड टाइप करने वाले उपयोगकर्ता के लिए कुछ नहीं करता, और एक बार छपकर नोट्स ऐप में फ़ोटो खींचे गए रिकवरी कोडों के लिए भी कुछ नहीं करता।
इसलिए उपकरण चुनने से पहले आवश्यकता लिखें। यदि लक्ष्य लीक हुए पासवर्ड के विरुद्ध अतिरिक्त प्रमाण है, तो यह स्पष्ट कहें, और उसी डिवाइस का ऐप वह पहले ही देता है। यदि लक्ष्य VPN वर्कस्टेशन के समझौते के प्रति लचीलापन है, तो उस हमलावर-क्षमता का नाम लें और उसके लिए मूल्यांकित व्यवस्था चुनें, और फ़िशिंग आवश्यकता को मान लेने के बजाय अलग से बताएँ।
फिर परिचालन वाले आधे हिस्से को संभालें, जो तय करता है कि इसमें से कुछ किसी घटना के संपर्क में टिकता है या नहीं। डिवाइस खोने के लिए प्रलेखित प्रतिस्थापन मार्ग चाहिए, क्रेडेंशियल रोटेशन के लिए सक्रिय सत्र रद्द करने चाहिए, और नामांकन सामग्री को बीज जैसी ही सुरक्षा चाहिए, क्योंकि असुरक्षित नामांकन प्रतिलिपि हमलावर को वही भावी कोड छोटे मार्ग से दे देती है। इन चार मदों को गिनाना उस बहस से अधिक उपयोगी है कि एक ही डिवाइस के टोकन अच्छे हैं या बेकार।