U2F के लिए विश्वसनीय, सुरक्षित और बहुमुखी बैकअप

मुझे वास्तव में U2F द्वारा प्रदान की गई सुरक्षा का स्तर पसंद है, लेकिन सुरक्षा के साथ-साथ आपको एक रिकवरी प्लान पर विचार करने की आवश्यकता है। अपने सबसे महत्वपूर्ण खातों तक पहुंच खोना, यदि मुख्य U2F टोकन के साथ कुछ होता है, तो एक गंभीर समस्या है। उसी समय, मैं एक बैकअप का उपयोग करने से बचना चाहूंगा जो यू 2 एफ द्वारा प्रदान की गई सुरक्षा से समझौता करता है।

लोकप्रिय बैकअप विधियाँ

आज तक, बैकअप के लिए दूसरा स्वतंत्र U2F टोकन रखना एक अच्छा अभ्यास रहा है; इस टोकन को प्रत्येक सेवा में मैन्युअल रूप से जोड़ा जाना चाहिए और "सुरक्षित" स्थान पर संग्रहीत किया जाना चाहिए। एक अन्य सामान्य अभ्यास गैर-यू 2 एफ पद्धति का बैकअप (ओटीपी, रिकवरी कोड) के रूप में उपयोग करना है। ईमानदारी से, इन दोनों तरीकों से वांछित होने के लिए बहुत कुछ छोड़ दिया जाता है।

स्वतंत्र U2F टोकन

इसका मतलब है कि हर बार जब मैं किसी नई सेवा में पंजीकरण करता हूं, तो मुझे अपने दोनों टोकन जोड़ने होंगे। यह तथ्य कई समस्याओं को जन्म देता है:

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

मेरी राय में, यह "अनुकरणीय अभ्यास" बहुत विश्वसनीय नहीं है, और बल्कि बोझिल है। आइए एक और सामान्य अभ्यास देखें।

बैकअप के रूप में गैर- U2F विधि

OTP:

• ओटीपी का बैकअप के रूप में उपयोग करना मुख्य 2FA विधि के रूप में उपयोग करने से बेहतर है, लेकिन ओटीपी के किसी भी तरह होने का तथ्य अतिरिक्त आक्रमण वेक्टर को खोलता है;
• फोन टूट जाते हैं, खो जाते हैं और चोरी हो जाते हैं, और अगर इसके नुकसान के बाद एक मौका है कि यह अजनबियों के हाथों में होगा, तो आपको सभी खातों पर इस बैकअप को मैन्युअल रूप से याद करने की आवश्यकता है;
• मैं हमेशा अपने साथ एक फोन और एक यू 2 एफ टोकन ले जाता हूं, इसलिए फिर से, ऐसी बैकअप विधि आदर्श से बहुत दूर है: एक बार में दोनों को खोने की संभावना बहुत अधिक है यदि बैकअप अलग से संग्रहीत किया गया था। लेकिन इस आइटम का उपयोग करके थोड़ा मुआवजा दिया जा सकता है, उदाहरण के लिए, ऑटि, जो अपने सर्वर पर एन्क्रिप्टेड बैकअप को संग्रहीत करता है;
• गैर-सार्वभौमिक विधि: दुर्भाग्य से, पर्याप्त संख्या में सेवाएं हैं जो केवल कस्टम एप्लिकेशन प्रदान करती हैं और मानक टीओटीपी का समर्थन नहीं करती हैं।

रिकवरी कोड:

• रिकवरी कोड एक सुरक्षित स्थान पर संग्रहित किया जाना चाहिए। फिर से, यह "सुरक्षित स्थान" सबसे अधिक संभावना मेरा घर होगा, जिसमें लगभग अलग-अलग यू 2 एफ टोकन के समान समस्याएं हैं;
• फिर से, एक गैर-सार्वभौमिक विधि: प्रत्येक सेवा का बैकअप के लिए अपना दृष्टिकोण है

इसलिए, संक्षेप में, ये सभी विधियां गैर-सार्वभौमिक, बोझिल और सुरक्षित नहीं हैं।

सबसे अच्छा बैकअप तरीका

अब, जब मैंने मामलों की वर्तमान स्थिति की पर्याप्त आलोचना की है, मैं अंत में कहूंगा कि मैं वास्तव में क्या चाहता हूं। मैं वास्तव में दो U2F टोकन रखना चाहता हूं: प्राथमिक और बैकअप, लेकिन उन्हें एक निश्चित तरीके से कॉन्फ़िगर किया जाना चाहिए:

• जब मैं किसी भी डिवाइस पर मुख्य टोकन को पंजीकृत करता हूं, तो बैकअप टोकन स्वचालित रूप से इस सेवा के लिए चालू हो जाता है;
• जैसे ही मैं किसी भी सेवा पर बैकअप टोकन का उपयोग करता हूं, इस सेवा के लिए मुख्य टोकन अमान्य है।

इससे पहले कि हम U2F के भीतर इसकी तकनीकी व्यवहार्यता पर चर्चा करें, मैं बताऊंगा कि यह महान क्यों है और मैं इसका उपयोग कैसे करता हूं।

यह महान क्यों है?

यदि हम ऊपर वर्णित स्वतंत्र बैकअप टोकन की आलोचना को देखते हैं, तो हम देख सकते हैं कि इस पद्धति की सभी कमियों को समाप्त कर दिया गया है:

• बैकअप टोकन अब आसानी से सुलभ नहीं होना चाहिए। चरम उदाहरण हो सकते हैं: एक ईंट की दीवार के अंदर एक टोकन को ऊपर उठाएं, या बगीचे में या अन्य जगहों पर मीटर और आधे हिस्से को दफनाना। कोई मजाक नहीं, मैं इसके लिए जाने के लिए काफी तैयार हूं;
• चाहे मैं जहां भी स्थित हूं, अगर मैं किसी भी सेवा के लिए साइन अप करता हूं, तो मुझे इस सेवा में बैकअप टोकन जोड़ने के लिए कुछ भी करने की आवश्यकता नहीं है। मैं अपने मुख्य टोकन का उपयोग करता हूं, और मैं मन की शांति में हूं, यह जानकर कि मेरे पास बैकअप है;
• बाहरी लोगों के लिए, यह पूरी तरह से अस्पष्ट है जहां मेरा बैकअप टोकन स्थित है। यह जानते हुए भी कि यह मौजूद है, इसे स्वयं खोजने की कोशिश शायद ही समझ में आती है;
• यह काफी सुरक्षित है। यहां तक ​​कि अगर मेरे मुख्य टोकन में कुछ बुरा होता है, तो यह अत्यधिक संभावना नहीं है कि उसी घटना से बैकअप टोकन प्रभावित होगा;
• यह सार्वभौमिक है। यह बैकअप विधि किसी भी सेवा पर काम करेगी जो U2F को सपोर्ट करती है, फिर चाहे यह सेवा और भी क्यों न हो।

और अगर कुछ बुरा वास्तव में मुख्य टोकन के साथ होता है, तो मैं निम्नलिखित कार्य करता हूं:

• मैं एक बैकअप टोकन खोदता / निकालता हूं;
• U2F के साथ मेरी सभी सेवाओं पर प्रमाणीकरण करें, जिससे मुख्य टोकन रद्द हो जाए;
• मैं टोकन की एक नई जोड़ी का आदेश देता हूं, और प्राप्त होने पर, सभी सेवाओं पर एक नया मुख्य टोकन जोड़ देता हूं, और पुराने को रद्द कर देता हूं।

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

कार्यान्वयन

U2F प्रोटोकॉल अवलोकन

इससे पहले कि हम कार्यान्वयन के बारे में बात कर सकें, हमें एक निश्चित स्तर पर समझने की आवश्यकता है कि U2F कैसे काम करता है। अधिकांश निर्माता इसे निम्नानुसार लागू करते हैं (निम्न में से सभी मानक में मौजूद नहीं हैं; कुछ चीजें कार्यान्वयन विवरण हैं, लेकिन अधिकांश मौजूदा कार्यान्वयन, जहां तक ​​मुझे पता है, बस उसी तरह से काम करते हैं):

device_secret U2F टोकन में 32-बिट counter के साथ प्रोग्राम किया गया है, जिसे केवल इंक्रीमेंट किया जा सकता है। जब हम किसी सेवा पर U2F टोकन रजिस्टर करते हैं, तो निम्नलिखित होता है:

• ब्राउज़र यूआईडीएफ डिवाइस को AppID (वास्तव में, डोमेन नाम) भेजता है;
• डिवाइस एक यादृच्छिक संख्या ( nonce ) उत्पन्न करता है, इसे device_secret साथ जोड़ता है, यह सभी को HMAC-SHA256 के माध्यम से कुंजी के रूप में device_secret का उपयोग करके device_secret , और परिणामस्वरूप हैश इस विशेष सेवा के लिए निजी कुंजी बन जाता है: service_private_key ;
• service_private_key , सार्वजनिक कुंजी service_public_key उत्पन्न होता है;
• डिवाइस AppID फिर से लेता है, इसे device_secret साथ जोड़ता है, और इसे HMAC-SHA256 के माध्यम से फिर से कुंजी के रूप में device_secret का उपयोग करके device_secret करता है। परिणाम ( MAC ), nonce के साथ जो पहले उत्पन्न हुआ था, key_handle बन जाता है;
• डिवाइस key_handle और service_public_key ब्राउज़र को वापस भेजता है, और ब्राउज़र सेवा में पास हो जाता है, जो भविष्य के प्रमाणीकरण के लिए इस डेटा को बचाता है।

बाद में प्रमाणीकरण इस प्रकार है:

• सेवा एक challenge उत्पन्न करती है (यादृच्छिक रूप से उत्पन्न डेटा) और इसे key_handle (जिसमें nonce और MAC ) के साथ ब्राउज़र को भेजता है। ब्राउज़र यह सब डिवाइस के पास जाता है, AppID (यानी डोमेन नाम) के साथ;
• डिवाइस, nonce और AppID , उसी तरह से service_private_key उत्पन्न करता है, जो पंजीकरण के दौरान उत्पन्न हुई थी;
• डिवाइस पंजीकरण के दौरान उसी तरह एक MAC उत्पन्न करता है, और ब्राउज़र से प्राप्त MAC साथ तुलना करके, यह सुनिश्चित nonce है कि nonce प्रतिस्थापित नहीं किया nonce , और इसलिए, service_private_key विश्वसनीय है;
• डिवाइस वेतन वृद्धि counter ;
• डिवाइस AppID का उपयोग करके challenge , AppID और counter हस्ताक्षर counter है, counter ब्राउज़र को परिणामस्वरूप हस्ताक्षर ( signature ) और counter भेजता है, जो इस डेटा को सेवा में आगे स्थानांतरित करता है;
• सेवा उस service_public_key का उपयोग करके signature जांच करती है जो उसके पास पंजीकरण के बाद है। साथ ही, अधिकांश सेवाएं यह सत्यापित करती हैं कि counter पिछले मूल्य से बड़ा है (यदि यह पहला प्रमाणीकरण नहीं है)। इस परीक्षण का उद्देश्य यू 2 एफ उपकरणों की क्लोनिंग को दुर्गम बनाना है। परिणामस्वरूप, यदि signature मिलान और counter पिछले मूल्य से अधिक है, तो प्रमाणीकरण सफलतापूर्वक पूरा हुआ माना जाता है, और सेवा नए counter मान को सहेजती है।

अब उन विवरणों की रूपरेखा तैयार करते हैं जो सीधे चर्चा से संबंधित हैं।

ब्याज का विवरण

पहला यह है कि डिवाइस प्रत्येक सेवा के लिए service_private_key को संग्रहीत नहीं करता है: इसके बजाय, यह HMAC-SHA256 का उपयोग करते हुए हर बार service_private_key प्रदर्शित करता है। यह हमारे लिए बहुत महत्वपूर्ण है: यह स्पष्ट है कि यदि प्रत्येक डिवाइस प्रत्येक सेवा के लिए अलग से अद्वितीय कुंजी संग्रहीत करेगा, तो केवल यह उपकरण बाद में प्रमाणित कर सकता है।

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

और दूसरी बात, क्लोनिंग को रोकने के लिए डिवाइस में एक counter है।

पहली नज़र में, ऐसा लग सकता है कि यह counter हमें चर्चा की गई बैकअप रणनीति को लागू करने की अनुमति नहीं देता है (कम से कम मुझे ऐसा लगता था जब मैंने समाधान खोजने की कोशिश की थी), लेकिन वास्तव में, यह केवल हमारी मदद करता है! मैं अब समझाता हूँ।

मुख्य विचार

यह विचार इस प्रकार है: उत्पादन स्तर पर, दो टोकन को इस तरह से प्रोग्राम करें कि वे दोनों एक ही device_secret , लेकिन बैकअप टोकन को कुछ सुधार की आवश्यकता है: इसके शुद्ध रूप में counter का उपयोग करने के बजाय (जैसा कि सामान्य टोकन करते हैं), इसे जोड़ना चाहिए counter लिए कुछ बड़ा निरंतर। उदाहरण के लिए, आधा 32-बिट रेंज, अर्थात्। लगभग 2 000 000 000 , यह उचित लगता है: मैं अपने पूरे जीवन में इतने सारे प्रमाणों को समाप्त करने की संभावना नहीं है।

वास्तव में, यह सब है। सरल और प्रभावी।

इस तरह से दो टोकन होने के बाद, मैं बैकअप टोकन को कुछ वास्तव में हार्ड-टू-पहुंच स्थान पर छिपाता हूं, और कभी भी इसे स्पर्श न करें। यदि कुछ भयानक होता है और मैं मुख्य टोकन तक पहुंच खो देता हूं, तब भी मुझे बैकअप टोकन मिल जाता है, और मैं इसे तुरंत उन सभी सेवाओं पर उपयोग कर सकता हूं, जहां मैंने मुख्य टोकन पंजीकृत किया था, क्योंकि बैकअप में एक ही device_secret , और इसका counter वास्तव में बड़ी संख्या के साथ शुरू होता है, जो मुझे अपने जीवन के बाकी समय के लिए नहीं मिला।

इसके अलावा, मैं इस तथ्य पर ध्यान आकर्षित करता हूं कि मैं टोकन क्लोन करने का प्रस्ताव नहीं करता हूं । दो टोकन, हालांकि उनके पास एक ही device_secret , अलग-अलग काउंटर हैं, और प्रोग्रामिंग device_secret बाद इसे डिवाइस से वापस लाने या किसी अन्य तरीके से क्लोन बनाने का कोई तरीका नहीं होना चाहिए।

काउंटर के बारे में एक नोट

एक चौकस पाठक यह देख सकता है कि निम्नलिखित सुरक्षा समस्या है: क्या होगा यदि एक हमलावर मुख्य टोकन तक पहुंच प्राप्त करता है और किसी तरह 2,000,000,000 प्रमाण पत्र प्राप्त करता है? फिर वह इस सेवा पर बैकअप टोकन का उपयोग करने के बाद भी सेवा में पहुंच जाता है।

सौभाग्य से, इस समस्या का एक सरल समाधान है। किसी भी स्थिति में, काउंटर को हार्डवेयर में लागू किया जाना चाहिए (संभवतः कुछ क्रिप्टो प्रोसेसर पर), और सुरक्षित कार्यान्वयन के लिए, इस हार्डवेयर काउंटर की सीमा 32 बिट्स से कम होनी चाहिए। उदाहरण के लिए, ATECC508A पर, काउंटर केवल 2097151 तक की गिनती कर सकते हैं, इसलिए काउंटर के अधिकतम मूल्य से अधिक किसी भी मूल्य के लिए काउंटर में निरंतर जोड़े जाने से, हम यह सुनिश्चित कर सकते हैं कि मुख्य टोकन कभी भी बैकअप टोकन में काउंटर की गिनती नहीं कर सकता है।

स्पष्ट करने के लिए: मान लीजिए कि हमारा U2F टोकन ATECC508A का उपयोग करता है, और ATECC508A के अंदर काउंटर को hw_counter के रूप में hw_counter । तब:

• मुख्य टोकन में, हम गणना के लिए उपयोग करते हैं: hw_counter ;
• बैकअप टोकन में, हम गणना के लिए उपयोग करते हैं: hw_counter + 2000000000 ।

कृपया ध्यान दें कि हम क्रिप्टोकरंसी के अंदर वास्तविक hw_counter को संशोधित नहीं करते हैं; यह अभी भी 0 से 2097151 तक गिना जाएगा। इसके बजाय, हर बार जब हमें काउंटर मूल्य प्राप्त करने की आवश्यकता होती है, हम hw_counter से hw_counter पढ़ते हैं, फिर हम अपना कंटेंट जोड़ते हैं और इसे वापस करते हैं (U2F के लिए आगे की गणना के लिए)।

इस प्रकार, मुख्य टोकन में काउंटर वैल्यू की सीमा [0, 2097151] होगी, जबकि बैकअप टोकन में काउंटर वैल्यू की रेंज [2000000000, 2002097151] होगी। तथ्य यह है कि ये सीमाएं ओवरलैप नहीं होती हैं, बैकअप का उपयोग करते समय मुख्य टोकन को रद्द करना सुनिश्चित करता है (यदि सेवा counter का उपयोग करती है, तो मुख्य सेवाएं जिन्हें मैंने चेक किया था वे उपयोग करते हैं)।

वास्तविक कार्यान्वयन

U2F टोकन के निर्माताओं में से कोई भी मैं आज आवश्यक अनुकूलन का समर्थन करने के बारे में नहीं जानता। लेकिन सौभाग्य से, U2F टोकन का एक खुला-स्रोत कार्यान्वयन है: सोलोकेय्स ।

मैंने एक साल पहले अपना मूल लेख (अंग्रेजी में) लिखा था, और यह हिस्सा थोड़ा दिनांकित है: तब सोलोकेय्स प्रोटोटाइप चरण में था, और मैंने परियोजना के पिछले पुनरावृत्ति का उपयोग किया: u2f- शून्य । इसलिए, मैं अब इस हिस्से का अनुवाद नहीं करूंगा, क्योंकि u2f- शून्य डिवाइस प्राप्त करने का एकमात्र तरीका यह है कि आप इसे मिलाप करें, और ऐसा करने के लिए शायद ही सलाह दी जाती है (हालांकि गीथब पर निर्देश हैं)।

फिर भी, मूल लेख में u2f-शून्य के आवश्यक संशोधन के सभी विवरण दिए गए हैं।

जब मेरे हाथ सोलोकियों तक पहुंचेंगे, तो मैं इसके संशोधन के लिए निर्देश लिखूंगा।

एक तरीका या दूसरा, यह एकमात्र तरीका है जिसे मैं आज जानता हूं कि एक विश्वसनीय बैकअप के साथ एक काम करने वाला U2F टोकन प्राप्त करना है। कई सेवाओं (कम से कम google और github) की जाँच करने पर पता चला कि यह काम करता है: सेवा के मुख्य टोकन को पंजीकृत करके, हम बैकअप का उपयोग भी कर सकते हैं, और बैकअप के पहले उपयोग के बाद, मुख्य टोकन काम करना बंद कर देता है। Awwwwwww। <3

चेतावनी

इस तथ्य के बावजूद कि यह बैकअप रणनीति शांत है, मैं u2f-zero या solokey के माध्यम से इसके विशिष्ट कार्यान्वयन के बारे में सुनिश्चित नहीं हूं। यह मार्ग केवल वही है जो आप चाहते हैं, इसलिए मैं उस रास्ते पर चला गया; लेकिन यह मानते हुए कि हमलावर U2F डिवाइस तक भौतिक पहुंच प्राप्त कर रहा है, मुझे यकीन नहीं है कि डिवाइस को हैक करना (यानी इससे device_secret प्राप्त करना) उतना ही मुश्किल होगा, जितना कि यह वाईकाइक या अन्य प्रमुख निर्माताओं के मामले में होगा। सोलोकी के लेखकों का दावा है कि "सुरक्षा का स्तर एक आधुनिक कार कुंजी के समान है," लेकिन मैंने इसकी पुष्टि करने के लिए कोई परीक्षा आयोजित नहीं की।

हालांकि, ईमानदार होने के लिए, मैं वास्तव में इस बारे में चिंतित नहीं हूं। यदि कोई हमलावर इसे वापस करने के इरादे से एक टोकन चुराता है, तो इसे तोड़ने की जटिलता कोई फर्क नहीं पड़ता, क्योंकि एक हमलावर किसी खाते तक पहुंचने के लिए बस इस टोकन का उपयोग कर सकता है और उदाहरण के लिए, बस इस टोकन को रद्द करें और दूसरा जोड़ें। हालाँकि, इसके लिए मुझे सुरक्षा संबंधी अन्य गंभीर समस्याएं भी होनी चाहिए। U2F टोकन केवल दूसरा कारक है।

तो, एकमात्र परिदृश्य जिसमें सोलोकी कुछ और की तुलना में कम सुरक्षित हो सकता है जब कोई हमलावर थोड़े समय के लिए डिवाइस तक पहुंचने की कोशिश करता है, तो उससे device_secret प्राप्त करें, और डिवाइस को वापस, अदृश्य रूप से मुझे वापस करें। ऐसा करने के लिए, उसे फ्लैश माइक्रोकंट्रोलर (या सही समय पर रैम) की सामग्री को पढ़ने की जरूरत है, और यह बहुत मामूली नहीं है।

सभी कारकों को ध्यान में रखते हुए, मेरा मानना ​​है कि मेरे लिए व्यक्तिगत रूप से एक विश्वसनीय बैकअप होना एक U2F डिवाइस के अल्ट्रा-सुरक्षित हार्डवेयर कार्यान्वयन के मुकाबले बहुत महत्वपूर्ण है। इस तरह के एक सुरक्षित कार्यान्वयन और एक अच्छा बैकअप की कमी के साथ समस्याओं की संभावना u2f- शून्य (सोलोकी) और बैकअप के साथ समस्याओं की संभावना से अधिक है।

निष्कर्ष

माना जाता है कि बैकअप रणनीति सभी आयामों में विकल्पों को बेहतर बनाती है: यह किसी भी अन्य तरीकों की तुलना में सार्वभौमिक, सुरक्षित और अधिक विश्वसनीय है।

मुझे खुशी होगी अगर कम से कम एक मुख्य निर्माता अपने उत्पादों में इसे लागू करता है, लेकिन अभी तक कोई निश्चितता नहीं है। एक यूबिको समर्थन आदमी, जेम्स ए।, ने मुझे यह भी बताया कि बैकअप की मुझे जरूरत है, "यू 2 एफ को डिजाइन करने के तरीके से संभव नहीं है," और मैंने कार्यान्वयन विवरणों को निर्धारित करने के बाद, यह बस जवाब देना बंद कर दिया।

सौभाग्य से, यह उतना असंभव नहीं था जितना कि यूबिको का मानना ​​है।

---

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