Chrome में जोड़ें

यह कैसे काम करता है

सुरक्षा की समीक्षा करने वालों के लिए तकनीकी विवरण। यहाँ लिखी हर बात स्रोत कोड से मिलाकर जाँची जा सकती है — उन हिस्सों समेत जो हमारे पक्ष में नहीं हैं और जिन्हें हम छिपाने के बजाय साफ़ लिखते हैं।

आर्किटेक्चर

कोई बैकएंड नहीं है। यह एक Manifest V3 क्रोम एक्सटेंशन है जो TOTP/HOTP कोड OTPAuth की मदद से डिवाइस पर ही बनाता है। हम कोई सर्वर नहीं चलाते, कोई खाता नहीं रखते, और ऐसा कोई रास्ता ही नहीं है जिससे उपयोगकर्ता का डेटा हम तक पहुँच सके।

जब सर्वर ही नहीं है, तो सर्वर पर कुंजी सामग्री, कुंजी एस्क्रो या हमारे नियंत्रण वाला कोई रिकवरी रास्ता भी नहीं है। यदि उपयोगकर्ता पासवर्ड भूल जाए और रिकवरी कोड भी खो दे, तो हम कुछ नहीं कर सकते — यह डिज़ाइन का हिस्सा है।

क्रिप्टोग्राफ़ी

पासवर्ड सुरक्षा वैकल्पिक है और डिफ़ॉल्ट रूप से बंद रहती है। चालू होने पर:

सिफर
AES-256-GCM, हर रिकॉर्ड और हर बार दोबारा लिखने पर यादृच्छिक 96-बिट IV
कुंजी व्युत्पत्ति
PBKDF2-HMAC-SHA256, 6,00,000 पुनरावृत्तियाँ, यादृच्छिक 128-बिट सॉल्ट (OWASP की सलाह के अनुसार)
मास्टर कुंजी
256-बिट, crypto.getRandomValues से, एक ही बार बनती है; पासवर्ड सिर्फ़ उसे लपेटता है
फ़िंगरप्रिंट
HKDF से बनी उप-कुंजी पर HMAC-SHA256, जिससे रिकॉर्ड अलग-अलग डिवाइसों के बीच मिलाए जाते हैं
अनलॉक कुंजी का भंडारण
chrome.storage.session — केवल मेमोरी में, डिस्क पर कभी नहीं लिखी जाती, ब्राउज़र बंद होते ही मिट जाती है, और कंटेंट स्क्रिप्ट की पहुँच से बाहर रहती है
स्वतः लॉक
हर बार खोलने पर / 5, 15 या 60 मिनट निष्क्रियता के बाद / ब्राउज़र बंद होने तक
क्रियान्वयन
केवल WebCrypto। कोई भी प्रिमिटिव हाथ से नहीं लिखा गया और कोई क्रिप्टो लाइब्रेरी पैकेज में शामिल नहीं है।

कुंजी के दो स्तर क्यों

डेटा को पासवर्ड से बनी कुंजी से सीधे कभी एन्क्रिप्ट नहीं किया जाता। रिकॉर्ड एक यादृच्छिक मास्टर कुंजी से एन्क्रिप्ट होते हैं; PBKDF2 का आउटपुट सिर्फ़ उस मास्टर कुंजी को लपेटता है। इससे दो नतीजे निकलते हैं, और दोनों मायने रखते हैं:

  • पासवर्ड बदलने पर हर रिकॉर्ड, हर बैकअप और हर एक्सपोर्ट को दोबारा एन्क्रिप्ट करने के बजाय सिर्फ़ 32 बाइट दोबारा लिखे जाते हैं। भंडारण व्यवस्थाएँ डेटा ठीक ऐसे ही थोक लेखन के दौरान गँवाती हैं।
  • 160-बिट का रिकवरी कोड उसी मास्टर कुंजी को स्वतंत्र रूप से लपेट सकता है, इसलिए भूला हुआ पासवर्ड वापस पाया जा सकता है। कोड एक ही बार दिखता है, पुष्टि के लिए उसे दोबारा टाइप करना पड़ता है, और हर इस्तेमाल के बाद वह बदल जाता है। जब तक उपयोगकर्ता उसकी पुष्टि न कर दे, डिस्क पर कुछ नहीं लिखा जाता।

क्या एन्क्रिप्ट होता है और क्या नहीं

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

साफ़-साफ़ कह रहे हैं, क्योंकि आपके आकलन के लिए यह अहम है:

  • पासवर्ड सुरक्षा बंद होने पर खाते बिना एन्क्रिप्शन के सहेजे जाते हैं और, यदि Chrome Sync चालू है, तो उपयोगकर्ता के अपने Google खाते के ज़रिए दोहराए जाते हैं। वे हम तक कभी नहीं पहुँचते, पर Google के पास रहते हैं। सिंक बंद किया जा सकता है, जिससे वहाँ पहले से मौजूद डेटा भी हट जाता है।
  • प्रति-साइट उपयोग इतिहास — कौन-सा खाता किस डोमेन पर इस्तेमाल होता है — स्थानीय रूप से सहेजा जाता है और जब तक इकट्ठा हो रहा है, तिजोरी के दायरे में नहीं आता। पासवर्ड सुरक्षा चालू करने पर यह मिट जाता है; इसे अलग से भी बंद किया जा सकता है।

ख़तरा मॉडल

इनसे बचाता है

  • ब्राउज़र की प्रोफ़ाइल डायरेक्टरी चोरी होना या कॉपी हो जाना
  • इन्फ़ोस्टीलर मैलवेयर जो ब्राउज़र का डेटा थोक में बाहर भेजता है
  • बिना निगरानी छोड़ी गई मशीन तक किसी की भौतिक पहुँच
  • Chrome Sync के ज़रिए खातों के रिकॉर्ड का Google तक पहुँचना
  • बैकअप फ़ाइल का खो जाना या चोरी होना (पासवर्ड-सुरक्षित एक्सपोर्ट)

इनसे नहीं बचाता

  • तिजोरी अनलॉक रहते हुए उपयोगकर्ता के रूप में चल रहा मैलवेयर
  • टाइप करते समय पासवर्ड पकड़ने वाला कीलॉगर
  • पहले से समझौता किया जा चुका ब्राउज़र या ऑपरेटिंग सिस्टम
  • उन तृतीय-पक्ष सेवाओं में सेंध, जिनके लिए ये कोड हैं

संक्षेप में: यह निष्क्रिय अवस्था में रखे डेटा की रक्षा करता है। जो डिवाइस इस्तेमाल के समय पहले से ही हमलावर के नियंत्रण में है, उसकी रक्षा यह नहीं करता, और कर भी नहीं सकता।

अनुमतियाँ

मैनिफ़ेस्ट में ठीक दो अनुमतियाँ घोषित हैं और कोई होस्ट अनुमति नहीं:

storage
खाते और सेटिंग्स लोकल स्टोरेज में, अनलॉक कुंजी सेशन स्टोरेज में, और वैकल्पिक सिंक प्रति
activeTab
मेल खाते खाते को उभारने के लिए सक्रिय टैब का होस्टनाम पढ़ता है, और जब उपयोगकर्ता स्क्रीन से QR कोड स्कैन करता है तो उस टैब को कैप्चर करता है

कोई कंटेंट स्क्रिप्ट नहीं है, tabs, cookies या webRequest जैसी कोई अनुमति नहीं है, और वेब से पहुँच योग्य कोई संसाधन नहीं है। एक्सटेंशन किसी भी पेज की सामग्री न पढ़ सकता है, न बदल सकता है।

कैमरा

कैमरे से QR स्कैन करना पॉपअप में नहीं, बल्कि टैब में खुले एक्सटेंशन पेज पर चलता है — पॉपअप फ़ोकस हटते ही नष्ट हो जाता है, और अनुमति का संवाद ठीक यही करता है। इसके लिए मैनिफ़ेस्ट में किसी अनुमति की ज़रूरत नहीं: यह ब्राउज़र का सामान्य कैमरा अनुरोध इस्तेमाल करता है, जो एक्सटेंशन के ऑरिजिन पर दिया जाता है और साइट सेटिंग्स से वापस लिया जा सकता है, और जब तक उपयोगकर्ता स्कैनर न खोले तब तक कभी नहीं माँगा जाता। वीडियो डिवाइस पर ही डिकोड होता है और कभी भेजा या सहेजा नहीं जाता।

बाहर जाने वाला नेटवर्क ट्रैफ़िक

सामान्य उपयोग में एक्सटेंशन कोई स्वचालित अनुरोध नहीं भेजता, और Manifest V3 रिमोट कोड पर रोक लगाता है। जितने भी कनेक्शन संभव हैं, वे ये रहे:

होस्टकबक्या उपयोगकर्ता डेटा जाता है?
worldtimeapi.org
timeapi.io
घड़ी के अंतर की जाँच, कैश के साथ, विफल होने पर चुपचाप छूट जाती है। घड़ी खिसकी हो तो TOTP टूट जाता है।नहीं
authenticator.shइंस्टॉल पर स्वागत पेज; अनइंस्टॉल या रेटिंग पर प्रतिक्रिया पेज।नहीं (सामान्य वेब सर्वर लॉग)

कोई फ़ॉन्ट, स्क्रिप्ट, स्टाइल या छवि तृतीय-पक्ष होस्ट से लोड नहीं होती। इंटरफ़ेस दिखाने के लिए जो भी चाहिए, वह पैकेज के भीतर ही आता है।

हम जो प्रकाशित करते हैं उसे जाँचना

ऊपर लिखी किसी भी बात को भरोसे पर मानने की ज़रूरत नहीं। एक्सटेंशन ओपन सोर्स है और हर रिलीज़ दोबारा बनाई जा सकती है:

  1. Chrome Web Store से प्रकाशित .crx डाउनलोड करके उसे अनज़िप करें
  2. उससे मेल खाते git टैग पर जाएँ
  3. Node 20 LTS पर npm ci && npm run build चलाएँ
  4. बनी हुई dist/ की तुलना अनज़िप किए पैकेज से करें

बनी हुई dist/ की हर फ़ाइल का SHA-256 हर GitHub रिलीज़ के साथ SHA256SUMS-v<version>.txt नाम से, sha256sum प्रारूप में प्रकाशित होता है — इसलिए चरण 4 सिर्फ़ एक बार sha256sum -c चलाने जितना रह जाता है। अंतर केवल आर्काइव के भीतर फ़ाइलों के क्रम और Node की अलग पैच रिलीज़ में मिनिफ़ाइड आउटपुट के ख़ाली स्थान तक सीमित होने चाहिए।

रनटाइम निर्भरताएँ जानबूझकर बहुत कम हैं — OTPAuth, React, jsQR, Zustand, Framer Motion और Lucide — और कमिट की गई लॉकफ़ाइल से तय हैं। CycloneDX प्रारूप में SBOM माँगने पर उपलब्ध है।

स्रोत कोड देखें

जो हमारे पास नहीं है

हम एक छोटे स्वतंत्र विक्रेता हैं। यदि नीचे में से कुछ भी आपकी प्रक्रिया के लिए अनिवार्य है, तो मूल्यांकन के तीन हफ़्ते बाद पता चलने से बेहतर है कि अभी पता चल जाए:

  • SOC 2, ISO 27001 या इनके समकक्ष कोई प्रमाणन नहीं
  • आज तक किसी तृतीय-पक्ष पेनिट्रेशन टेस्ट का आदेश नहीं दिया गया
  • कोई सशुल्क बग बाउंटी कार्यक्रम नहीं

इनके बदले हम जो देते हैं वह है स्रोत कोड की पूरी पारदर्शिता, जाँची जा सकने वाली बिल्ड, न्यूनतम अनुमतियाँ, और ऐसा कोई सर्वर ढाँचा ही नहीं जो आपका डेटा रख सके।

हमसे बात करना

सुरक्षा खामियों की सूचना और सुरक्षा से जुड़े सवाल: security@authenticator.sh। हमारी प्रकटीकरण नीति, दायरा, प्रतिक्रिया समय और सेफ़ हार्बर शर्तें सुरक्षा नीति पेज पर हैं; क्या सहेजा जाता है और डिवाइस से क्या बाहर जाता है, यह गोपनीयता नीति में लिखा है।

हम विक्रेता आकलन की लिखित प्रश्नावली भरने या किसी सुरक्षा टीम के साथ कोड पर चलकर बात करने को तैयार हैं।

जो कुछ भी सुरक्षा का मामला नहीं है — इंस्टॉलेशन, खाता वापस पाना, तैनाती से जुड़े बिलिंग सवाल — उसके लिए सहायता देखें। कृपया सुरक्षा खामियों की सूचना वहाँ न भेजें; वह इनबॉक्स गोपनीय नहीं माना जाता।