सुरक्षा

तिजोरी कैसे बनी है, और उसमें सेंध लगने पर क्या मिलेगा।

अंतिम अद्यतन 21 सितंबर 2026 · AssuredAuth, CircleRoll LLC द्वारा

यह इस बात का सार्वजनिक विवरण है कि AssuredAuth आपके द्वारा इसमें रखे गए दो-कारक सुरक्षा रहस्यों, पासवर्ड और कार्डों की सुरक्षा कैसे करता है। इसे इस तरह से लिखा गया है कि सुरक्षा के प्रति जागरूक पाठक ऐप और प्रकाशित परीक्षण तरीकों (जो hello@assuredauth.com पर अनुरोध करने पर किसी भी समीक्षक के लिए उपलब्ध हैं) के आधार पर प्रत्येक दावे की जांच कर सकें। इसमें केवल वही बताया गया है जो सच है: यहां किसी भी चीज़ में हमले से पूरी तरह सुरक्षित होने का दावा नहीं किया गया है, और किसी भी चीज़ का प्रतिशत में वादा नहीं किया गया है।

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

समस्या की रिपोर्ट करें: hello@assuredauth.com. अंत में "कमजोरी की रिपोर्टिंग" देखें।

1. क्या एन्क्रिप्ट किया गया है, किससे?

डेटा	फोन पर	कुंजी
दो-कारक रहस्य (टीओटीपी/एचओटीपी/स्टीम सीड्स)	फोन परकीचेन (iOS) / एंड्रॉइड कीस्टोर-समर्थित स्टोर	कुंजीप्लेटफ़ॉर्म की हार्डवेयर-आधारित कुंजी; डेटाबेस पंक्ति में केवल एक संदर्भ (secretRef) होता है, बीज कभी नहीं।
पासवर्ड (पासवर्ड का मान, नोट्स)	फोन परसीलबंद पंक्ति: AES-256-GCM, प्रति मान एक यादृच्छिक 96-बिट नॉनस	कुंजीएक यादृच्छिक 256-बिट डेटा कुंजी, जो स्वयं धारा 2 में वर्णित हार्डवेयर कुंजी द्वारा संलग्न है।
कार्ड (संख्या, समाप्ति तिथि, कार्ड पर नाम, सीवीसी)	फोन परपासवर्ड के समान ही सील; सीवीसी वैकल्पिक है और इसे तभी संग्रहीत किया जाता है जब आप इसे दर्ज करते हैं।	कुंजीसमान डेटा कुंजी
मेटाडेटा (सेवा के नाम, उपयोगकर्ता नाम, आइकन, सॉर्ट क्रम)	फोन परऐप का डेटाबेस (स्विफ्टडेटा / रूम)	कुंजीऑपरेटिंग सिस्टम के फ़ाइल एन्क्रिप्शन द्वारा सुरक्षित; इसे गैर-गुप्त माना जाता है।
बैकअप फ़ाइल (.authbackup)	फोन परआप इसे कहीं भी रखें: फ़ाइलें, iCloud ड्राइव, Google ड्राइव ऐप डेटा फ़ोल्डर, या शेयर शीट।	कुंजीआपके पासफ़्रेज़ से प्राप्त एक कुंजी (§3)। Apple और Google को केवल सीलबंद फ़ाइल प्राप्त होती है, और कुछ नहीं।
Watch / Wear साथी ऐप	फोन परघड़ी की अपनी कीचेन / एन्क्रिप्टेडशेयर्डप्रेफरेंसेस	कुंजीवॉच प्लेटफॉर्म की कुंजियाँ; प्लेटफॉर्म के युग्मित-उपकरण चैनल के माध्यम से स्थानांतरित की गईं
डेस्कटॉप एक्सटेंशन ट्रैफ़िक (अनुरोध पर एक बार उपयोग किए जाने वाले कोड)	फोन परसंग्रहीत नहीं; एंड-टू-एंड एन्क्रिप्टेड लिफाफों के रूप में प्रसारित किया जाता है	कुंजीप्रत्येक पेयरिंग के लिए एक X25519 कुंजी युग्म, निजी कुंजी कीचेन/कीस्टोर में; रिले केवल सिफरटेक्स्ट देखता है

डायग्नोस्टिक्स में ऐसा कोई मेथड नहीं है जो सीक्रेट स्वीकार करता हो। किसी भी एनालिटिक्स इवेंट में वॉल्ट फ़ील्ड नहीं होता है। वॉल्ट से कोई भी मान किसी भी बिल्ड में लॉग में नहीं लिखा जाता है।

2. प्रत्येक प्लेटफ़ॉर्म पर चाबियाँ कहाँ स्थित हैं

आईओएस. डेटा कुंजी को सिक्योर एन्क्लेव (kSecAttrTokenIDSecureEnclave) के अंदर जनरेट की गई कुंजी से सुरक्षित किया जाता है, जिसमें एक्सेस कंट्रोल .privateKeyUsage + .userPresence, एक्सेसिबिलिटी …ThisDeviceOnly शामिल है। यह कुंजी ऐप के साझा कीचेन एक्सेस ग्रुप में होती है, ताकि ऑटोफिल एक्सटेंशन उसी कुंजी का उपयोग कर सके। ऐप, बैकअप या डीबगर द्वारा एन्क्लेव से निजी कुंजी को पढ़ा नहीं जा सकता; एन्क्लेव इसका उपयोग तभी स्वीकार करता है जब उपयोगकर्ता मौजूद हो (फेस आईडी, टच आईडी या डिवाइस पासकोड)। ThisDeviceOnly का अर्थ है कि फोन के iCloud या iTunes बैकअप में कुंजी नहीं होती; पुनर्स्थापित फोन एक खाली वॉल्ट से शुरू होता है और आपकी बैकअप फ़ाइल और पासफ़्रेज़ मांगता है। बिना पासकोड वाला फ़ोन .userPresence कुंजी को नियंत्रित नहीं कर सकता (एनक्लेव इसे बनाने से इनकार करता है), और सिम्युलेटर भी डिज़ाइन के अनुसार यही तरीका अपनाता है (इसका उपस्थिति संकेत एक चेतावनी है जिसका कोई परीक्षण उत्तर नहीं दे सकता): वहाँ डेटा कुंजी एक साधारण डिवाइस-ओनली कीचेन आइटम है — जो अभी भी हर बैकअप से बाहर है, फ़ोन लॉक होने पर अभी भी अपठनीय है, लेकिन बिना किसी दूसरे संकेत के — और सुरक्षा स्क्रीन ठीक यही कहती है और पासकोड सेट करने का सुझाव देती है।

एंड्रॉइड। डेटा कुंजी को AndroidKeyStore AES-256 कुंजी द्वारा सुरक्षित किया जाता है, जो डिवाइस में मौजूद होने पर StrongBox में जनरेट होती है (अन्यथा TEE द्वारा), जिसमें setUserAuthenticationRequired(true) और बायोमेट्रिक या डिवाइस क्रेडेंशियल के बाद 30 सेकंड की प्रमाणीकरण वैधता, setUnlockedDeviceRequired(true) और setInvalidatedByBiometricEnrollment(true) चालू रहते हैं। यह अंतिम फ़्लैग लोड-बेयरिंग के बजाय ईमानदार है: Android इसे केवल उन कुंजियों पर लागू करता है जिनके लिए हर बार उपयोग पर बायोमेट्रिक की आवश्यकता होती है, इसलिए डिवाइस क्रेडेंशियल की अनुमति वाली इस 30-सेकंड की कुंजी पर यह कुछ भी नहीं बदलता है - किसी अजनबी को उंगली से दूर रखने का कारण यह है कि नामांकन के लिए PIN की आवश्यकता होती है, और स्क्रीन लॉक हटाने से कुंजी हमेशा के लिए अमान्य हो जाती है। Keystore कुंजियाँ निर्यात योग्य नहीं हैं और Android के क्लाउड बैकअप से बाहर रखी गई हैं। किसी ऐप द्वारा अपने स्वयं के दृश्यों (webDomain) पर नामित डोमेन को केवल एक ज्ञात ब्राउज़र से ही मान्य माना जाता है; किसी भी अन्य पैकेज से अलग होने पर, यह भी एक ऐसा पैकेज होना चाहिए जिसे सिस्टम ने उस पैकेज (डिजिटल एसेट लिंक्स) के लिए सत्यापित किया हो, क्योंकि कोई भी ऐप किसी भी डोमेन पर दावा कर सकता है।

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

3. बैकअप फ़ाइल

बैकअप ही एकमात्र ऐसी चीज़ है जो फ़ोन से बाहर जाती है, इसलिए सैद्धांतिक रूप से ऑफ़लाइन हमले की संभावना यहीं होती है। डिज़ाइन इस प्रकार बनाया गया है कि यह हमला महंगा हो और हमलावर को काम करने के लिए यथासंभव कम गुंजाइश मिले:

• पासफ़्रेज़ कम से कम 12 अक्षरों का होना चाहिए (शीट इससे कम अक्षरों को स्वीकार नहीं करती और एक स्ट्रेंथ बार दिखाती है)।
• पासफ़्रेज़ का कोई संकेत न तो फ़ाइल में और न ही ऐप में कहीं भी संग्रहीत किया जाता है।
• लिखी गई प्रत्येक फ़ाइल के लिए एक नया यादृच्छिक 16-बाइट सॉल्ट और 12-बाइट नॉनस।
• पूरा डेटा AES-256-GCM प्रारूप में है, इसलिए गलत पासफ़्रेज़ या क्षतिग्रस्त फ़ाइल को अस्वीकार कर दिया जाता है, इसे कभी भी कचरे में डिक्रिप्ट नहीं किया जाता है।
• हेडर (फॉर्मेट, वर्जन, केडीएफ पैरामीटर, सॉल्ट) को अतिरिक्त प्रमाणीकरण डेटा के रूप में जीसीएम टैग में शामिल किया जाता है, इसलिए जिस फाइल के वर्क फैक्टर को कम कर दिया गया है, वह नहीं खुलती है।

यह फ़ाइल JSON प्रारूप में है और किसी भी टेक्स्ट एडिटर में पढ़ी जा सकती है; केवल सिफरटेक्स्ट ही अपारदर्शी है। पांच साल बाद, जब ऐप गायब हो चुका होगा, तब अगर किसी को यह फ़ाइल मिलती है, तो वह देख सकता है कि इसे कैसे सील किया गया था और इसे OpenSSL या किसी भी Argon2 लाइब्रेरी से खोल सकता है।

फॉर्मेट v1 (1.0 में शामिल, पठनीय बना रहता है)

{
  "format": "authbackup",
  "version": 1,
  "kdf": "PBKDF2-HMAC-SHA256",
  "rounds": 600000,
  "salt": "<base64, 16 bytes>",
  "cipher": "AES-256-GCM",
  "nonce": "<base64, 12 bytes>",
  "ciphertext": "<base64>",
  "tag": "<base64, 16 bytes>"
}

कदम	बाइट्स
key	PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes)
aad	UTF-8("authbackup:1:600000:") ‖ salt (कच्चे नमक बाइट्स, बेस64 नहीं)
ciphertext, tag	AES-256-GCM(key, nonce, plaintext, aad); टैग 16 बाइट्स का है, जिसे अलग से संग्रहीत किया जाता है।
plaintext	UTF-8 JSON, कुंजी क्रमबद्ध: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1}

संगतता नोट: एंड्रॉइड 1.0 ने v1 का एक संस्करण लिखा था — kdf लोअर केस में, बिना टैग कुंजी (साइफरटेक्स्ट में जोड़ा गया 16-बाइट टैग), बिना अतिरिक्त डेटा के। दोनों प्लेटफ़ॉर्म इन फ़ाइलों को पढ़ते रहते हैं (जब टैग अनुपस्थित हो: अंतिम 16 बाइट्स को विभाजित करें, खाली AAD के साथ खोलें; kdf की केस-संवेदनशीलता रहित तुलना करें) और अब दोनों केवल ऊपर दिए गए लेआउट को ही लिखते हैं।

फॉर्मेट v2 (वर्तमान; नए बैकअप के लिए डिफ़ॉल्ट)

{
  "format": "authbackup",
  "version": 2,
  "kdf": "Argon2id",
  "memoryKiB": 65536,
  "passes": 3,
  "lanes": 1,
  "salt": "<base64, 16 bytes>",
  "cipher": "AES-256-GCM",
  "nonce": "<base64, 12 bytes>",
  "ciphertext": "<base64>",
  "tag": "<base64, 16 bytes>"
}

कदम	बाइट्स
key	Argon2id(version 0x13, passphrase as UTF-8, salt, m = 65536 KiB, t = 3, p = 1, tagLength 32, no secret, no associated data)
aad	UTF-8("authbackup:2:argon2id:65536:3:1:") ‖ salt
ciphertext, tag	AES-256-GCM(key, nonce, plaintext, aad); टैग 16 बाइट्स का है, जिसे अलग से संग्रहीत किया जाता है।
plaintext	UTF-8 JSON, कुंजी क्रमबद्ध: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2}

Argon2id संदर्भ C कार्यान्वयन (phc-winner-argon2, CC0) है, जो दोनों प्लेटफॉर्म पर उपलब्ध है। 64 MiB डेटा और 3 पास एक मौजूदा फोन पर लगभग एक सेकंड में प्रोसेस हो जाते हैं, और प्रत्येक अनुमान के लिए किसी भी हार्डवेयर पर उतनी ही मेमोरी और समय की आवश्यकता होती है — यह वह विशेषता है जो PBKDF2 में GPU सिस्टम के मुकाबले नहीं है, और यही कारण है कि v2 मौजूद है। एक रीडर उन कुंजियों को अनदेखा कर देता है जिन्हें वह नहीं जानता, इसलिए v1 रीडर को v2 बॉडी दिए जाने पर कार्ड कभी दिखाई नहीं देते।

सबूत

तीन टेस्ट-वेक्टर फ़ाइलें (बैकअप v1, बैकअप v2 और Argon2id) एक तीसरे कार्यान्वयन द्वारा उत्पन्न की जाती हैं, जो दोनों ऐप्स से स्वतंत्र है (Node का OpenSSL for PBKDF2 and AES-GCM, एक WebAssembly Argon2id जिसकी जाँच निर्माण के समय संदर्भ कार्यान्वयन के प्रकाशित उत्तरों के विरुद्ध की जाती है)। प्रत्येक फ़ाइल में पासफ़्रेज़, सॉल्ट, नॉनस, प्लेनटेक्स्ट, व्युत्पन्न कुंजी, AAD, अपेक्षित सिफरटेक्स्ट और टैग, और पूरी फ़ाइल होती है। iOS और Android पर किए गए यूनिट परीक्षण समान फ़ाइलों को पढ़ते हैं और समान बाइट्स की पुष्टि करते हैं - इसलिए एक प्लेटफ़ॉर्म पर सील किया गया बैकअप दूसरे प्लेटफ़ॉर्म पर खुलने के लिए सिद्ध होता है, न कि अनुमानित, और तीनों का मिलान एक ही गलती की दो प्रतियाँ नहीं है। एक सहायक टूल उसी तीसरे कार्यान्वयन के साथ फ़ोन द्वारा वास्तव में लिखी गई फ़ाइल को खोलता है और ऊपर दिए गए नियमों के अनुसार हेडर की जाँच करता है (स्वरूप की कुंजियाँ बिल्कुल वैसी ही होनी चाहिए, इसलिए कोई संकेत या नाम मौजूद नहीं हो सकता; 16-बाइट सॉल्ट, 12-बाइट नॉनस, 16-बाइट टैग अलग से संग्रहीत; संस्करण 2 बिल्कुल 64 MiB / 3 / 1 पर; गलत पासफ़्रेज़ अस्वीकार कर दिया गया); स्वचालित iOS रन सिम्युलेटर पर एक फ़ाइल लिखता है और उसे उस तरह से खोलता है, और सिम्युलेटर के ऐप कंटेनर, ऐप ग्रुप कंटेनर और कीचेन डेटाबेस में प्रत्येक सीडेड पासवर्ड और कार्ड नंबर को UTF-8 और UTF-16 के रूप में खोजता है (0 परिणाम)।

4. खतरे का मॉडल

परिस्थिति	उनके पास क्या है	उन्हें क्या मिलता है
खोया या चोरी हुआ फोन, लॉक किया हुआ	उनके पास क्या हैडिवाइस, डेटाबेस फ़ाइल, सीलबंद पंक्तियाँ	उन्हें क्या मिलता हैसिफरटेक्स्ट। रैपिंग कुंजी सुरक्षित एन्क्लेव/स्ट्रॉन्गबॉक्स में है और डिवाइस लॉक होने के साथ-साथ नया बायोमेट्रिक या पासकोड डालने पर ही रिलीज़ होती है। फ़ोन को दूर से वाइप करने (फाइंड माई/फाइंड माई डिवाइस) से कुंजी सामग्री भी नष्ट हो जाती है।
चोरी की गई बैकअप फ़ाइल	उनके पास क्या हैक्लाउड अकाउंट, ईमेल या लैपटॉप से ​​.authbackup फ़ाइल	उन्हें क्या मिलता हैकम से कम 12 अक्षरों के पासफ़्रेज़ से प्राप्त कुंजी के अंतर्गत AES-256-GCM बॉडी, जिसमें प्रति फ़ाइल सॉल्ट और 64 MiB × 3 पास (v2) या 600,000 राउंड (v1) पर Argon2id शामिल है। कोई संकेत नहीं, कोई उपयोगकर्ता नाम नहीं, कोई खाता सूची स्पष्ट रूप से नहीं। प्रत्येक अनुमान के लिए पूर्ण व्युत्पत्ति की आवश्यकता होती है; कोई शॉर्टकट नहीं है। एक मज़बूत पासफ़्रेज़ ही यहाँ संपूर्ण सुरक्षा है, और ऐप शीट पर यही बात स्पष्ट रूप से बताता है।
स्क्रीन अनलॉक किए हुए चोरी हुए डिवाइस	उनके पास क्या हैआपके हाथ में एक अनलॉक किया हुआ फोन।	उन्हें क्या मिलता हैकोड की सूची। वॉल्ट (पासवर्ड, कार्ड) ऐप लॉक के पीछे है और ऑटो-लॉक टाइमर (तुरंत / 1 मिनट / 5 मिनट) पर फिर से लॉक हो जाता है; डिक्रिप्टेड मान मेमोरी में केवल तभी मौजूद रहता है जब तक वह स्क्रीन पर दिखाई देता है। ऑटोफिल और प्लेन-टेक्स्ट एक्सपोर्ट ऐप खुला होने पर भी नए बायोमेट्रिक की मांग करते हैं। यदि आप इस बारे में चिंतित हैं, तो "तुरंत" विकल्प के साथ ऐप लॉक चालू करें।
उसी फ़ोन पर दुर्भावनापूर्ण ऐप	उनके पास क्या हैकिसी अन्य ऐप का सैंडबॉक्स, क्लिपबोर्ड, एक्सेसिबिलिटी या ओवरले ट्रिक्स	उन्हें क्या मिलता हैयह हमारी फ़ाइलों को नहीं पढ़ सकता (प्लेटफ़ॉर्म सैंडबॉक्सिंग) और न ही हमारी कुंजी का उपयोग कर सकता है (कुंजी हमारी हस्ताक्षर पहचान और उपयोगकर्ता उपस्थिति से जुड़ी होती है)। कॉपी 30 सेकंड के बाद क्लिपबोर्ड से हट जाती है; एंड्रॉइड पर कॉपी को संवेदनशील के रूप में चिह्नित किया जाता है और क्लिपबोर्ड इतिहास से हटा दिया जाता है। एंड्रॉइड पर वॉल्ट स्क्रीन FLAG_SECURE पर सेट होती हैं (कोई स्क्रीनशॉट नहीं, कोई स्क्रीन रिकॉर्डिंग नहीं, स्विचर में खाली); iOS स्विचर थंबनेल को खाली कर देता है। एंड्रॉइड पर ऑटोफिल केवल उन ऐप्स को दिया जाता है जिन्हें सिस्टम ने सहेजे गए डोमेन (डिजिटल एसेट लिंक्स) के विरुद्ध सत्यापित किया है, इसलिए किसी मिलते-जुलते ऐप को आपका पासवर्ड नहीं दिया जाता है।
फ़िशिंग पेज	उनके पास क्या हैएक ऐसी साइट जो आपके द्वारा सहेजी गई साइट जैसी दिखती हो	उन्हें क्या मिलता हैकुछ भी अपने आप नहीं भरता। मिलान रजिस्ट्रेबल डोमेन (सार्वजनिक प्रत्यय सूची, जो ऐप के साथ बंडल और अपडेट की जाती है) के आधार पर होता है: login.example.com और example.com मेल खाते हैं, example.com.evil.net और examp1e.com मेल नहीं खाते। ऐप का ब्राउज़र भी इसी तरह मिलान करता है और केवल उसी फ्रेम में भरता है जिसमें अनुरोध किया गया है, भरने के समय उस फ्रेम के मूल स्रोत से पुनः जाँच की जाती है; बिना किसी रजिस्ट्रेबल डोमेन वाला होस्ट — एक आईपी पता, स्थानीय नेटवर्क पर केवल नाम — बिल्कुल सटीक रूप से मेल खाता है और कोई भी अंतर नहीं होता। iOS ऑटोफिल में Apple का संबंधित डोमेन चेक भी शामिल है। किसी मिलते-जुलते पासवर्ड में हाथ से पेस्ट करना अभी भी जोखिम भरा है; ऐप इसे दूर नहीं कर सकता, केवल मदद करने से बच सकता है।
हमारे अपने सर्वर	उनके पास क्या है—	उन्हें क्या मिलता हैकोई वॉल्ट सर्वर नहीं है। AssuredAuth के पास कोई खाते नहीं हैं, कोई साइन-इन नहीं है और आपके वॉल्ट की कोई कॉपी भी नहीं है, इसलिए हमारे पास आपकी कोई भी ऐसी जानकारी नहीं है जिसे चुराया या क्रैक किया जा सके। सर्वर-साइड पर दो चीजें चलती हैं, जिनमें से कोई भी वॉल्ट को प्रभावित नहीं करती: डेस्कटॉप एक्सटेंशन के लिए एक रिले मेलबॉक्स, जो एंड-टू-एंड एन्क्रिप्टेड लिफाफे (वन-टाइम कोड, पढ़ने के बाद डिलीट हो जाते हैं; रिले के पास कभी कोई कुंजी नहीं होती) को स्टोर करता है, और वैकल्पिक निजी कनेक्शन के एग्जिट सर्वर, जो ट्रैफिक को संभालते हैं और कोई एक्सेस लॉग नहीं रखते।
सम्मन या सरकारी अनुरोध	उनके पास क्या हैहमारे विरुद्ध दायर कानूनी प्रक्रिया	उन्हें क्या मिलता हैसौंपने के लिए कुछ नहीं: हमारे पास न कोई तिजोरी है, न कोई चाबी, न कोई पासफ़्रेज़ और न ही कोई बैकअप। हमें यह कहने के लिए मजबूर किया जा सकता है; लेकिन जो अस्तित्व में ही नहीं है, उसे पेश करने के लिए हमें मजबूर नहीं किया जा सकता।

5. क्लिपबोर्ड, स्क्रीनशॉट और मेमोरी

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

6. ऑटोफिल: क्या भरता है और क्या नहीं

कहाँ	पासवर्ड	कार्ड
iOS: Safari और ऐप्स (ऑटोफिल एक्सटेंशन)	पासवर्डहां, एक्सटेंशन (LAContext) में नए फेस आईडी/टच आईडी/पासकोड के बाद, और केवल उस रजिस्ट्रेबल डोमेन के लिए जिसके लिए एंट्री सेव की गई थी, और ऐप्स के लिए Apple के एसोसिएटेड-डोमेन चेक के साथ।	कार्डनहीं। Safari में कार्ड ऑटोफिल की सुविधा केवल Apple की है; कार्ड स्क्रीन पर लिखा होता है "AssuredAuth ब्राउज़र में कॉपी भरता है" और इसके अलावा कोई और वादा नहीं करता।
एंड्रॉइड: ऐप्स और क्रोम (ऑटोफिल सर्विस)	पासवर्डहां, प्रति-डेटासेट प्रमाणीकरण: सिस्टम भरने से पहले बायोमेट्रिक प्रॉम्प्ट दिखाता है; ऐप पैकेज का मिलान तभी होता है जब डिजिटल एसेट लिंक्स इसे सहेजे गए डोमेन से जोड़ता है।	कार्डहां, क्रेडिट कार्ड नंबर, क्रेडिट कार्ड की समाप्ति तिथि* और क्रेडिट कार्ड सुरक्षा कोड संकेत देते हैं, ये सभी एक ही बायोमेट्रिक जांच प्रक्रिया का हिस्सा हैं।
AssuredAuth ब्राउज़र (दोनों प्लेटफ़ॉर्म)	पासवर्डहां, रजिस्ट्रेबल डोमेन द्वारा — एक होस्ट जिसका अपना कोई भी डोमेन बिल्कुल मेल नहीं खाता — उस फ्रेम में डाला गया जिसमें बायोमेट्रिक जानकारी भरने से पहले मांगी गई थी।	कार्डहां, भरने से पहले फील्ड डिटेक्शन और बायोमेट्रिक विधि द्वारा।
कॉपी बटन	पासवर्डऐप लॉक के पीछे, 30 सेकंड का क्लिपबोर्ड	कार्डसंख्या, समाप्ति तिथि, सीवीसी (नियम समान हैं)

किसी हमशक्ल होस्ट पर कुछ भी नहीं भरता। बायोमेट्रिक के बिना कुछ भी नहीं भरता।

7. जो कभी नहीं होता

कोई वॉल्ट सर्वर नहीं। वॉल्ट फ़ील्ड वाले कोई एनालिटिक्स नहीं। पुष्टि पत्र और नए बायोमेट्रिक के बिना कोई प्लेन-टेक्स्ट निर्यात नहीं। वॉल्ट स्क्रीन पर कोई तृतीय-पक्ष SDK लोड नहीं। वॉल्ट स्क्रीन का कोई स्क्रीनशॉट नहीं। कोई पासफ़्रेज़ संकेत नहीं। किसी भी बिल्ड में मानों की कोई लॉगिंग नहीं।

8. हम किन चीजों से बचाव नहीं कर सकते

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

9. समीक्षा स्थिति

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

10. जहाँ चीजें चलती हैं

वॉल्ट से कुछ भी फ़ोन से बाहर नहीं जाता, लेकिन इससे जुड़ी कुछ चीज़ें दूसरे लोगों के कंप्यूटरों पर चलती हैं। यह सूची है, और प्रत्येक में क्या है; डेटा प्रवाह का विवरण https://assuredauth.com/privacy पर गोपनीयता नीति में दिया गया है।

• Google Cloud / Firebase — डेस्कटॉप एक्सटेंशन के लिए रिले मेलबॉक्स (एंड-टू-एंड एन्क्रिप्टेड लिफाफे, पढ़े जाने पर हटा दिए जाते हैं), पुश टोकन, खरीद की स्थिति और संपर्क फ़ॉर्म के माध्यम से भेजे गए संदेश।
• वर्सेल — assuredauth.com, इसके पेज और इनके पीछे मौजूद छोटे-छोटे फ़ंक्शन।
• Vultr — निजी कनेक्शन के निकास सर्वर। ट्रैफ़िक इनके माध्यम से गुजरता है; कुछ भी संग्रहीत नहीं होता है।
• एप्पल और गूगल प्ले — उनके अपने स्टोर में खरीदारी और सदस्यता।
• PostHog — उत्पाद विश्लेषण: उपयोग की गई वस्तुओं की गणना, जिसका किसी पहचान से कोई संबंध नहीं है।
• RevenueCat — सदस्यता की स्थिति: सक्रिय या समाप्त, और किस प्लान पर है।

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

किसी कमजोरी की रिपोर्ट करना

यदि आपको लगता है कि यहाँ वर्णित किसी भी बात में आपको कोई खामी मिली है, तो कृपया hello@assuredauth.com पर "Security" विषय के साथ लिखें। कृपया प्लेटफ़ॉर्म, ऐप संस्करण और चरण शामिल करें; आपके अपने डेटा का उपयोग करके दिया गया प्रमाण पर्याप्त है, और हम आपसे अनुरोध करते हैं कि आप दूसरों के डेटा पर परीक्षण न करें। हम PGP कुंजी प्रदान नहीं करते हैं; यदि कोई रिपोर्ट सामान्य ईमेल के माध्यम से नहीं भेजी जानी चाहिए, तो कृपया पहले संदेश में ही बता दें और हम कोई दूसरा तरीका निकाल लेंगे।

बदले में हम आपसे ये वादा करते हैं: हम तीन कार्य दिवसों के भीतर इसकी पुष्टि करेंगे, काम करते समय आपको सूचित करते रहेंगे, प्रकाशन से पहले वास्तविक त्रुटियों को ठीक करेंगे, और यदि आप चाहें तो आपको यहां श्रेय देंगे। नीचे दिए गए दायरे में सद्भावनापूर्वक किए गए शोध पर हम कोई कानूनी कार्रवाई नहीं करेंगे।

इसके दायरे में शामिल हैं: iOS और Android ऐप्स, वॉच ऐप्स, डेस्कटॉप एक्सटेंशन, assuredauth.com और इसका API। इसके दायरे से बाहर हैं: ऐप स्टोर और गूगल प्ले, ऊपर सूचीबद्ध प्रदाता, किसी का भी सोशल इंजीनियरिंग करना और सेवा से वंचित करना।

फिलहाल कोई इनाम नहीं है। शिकायत का जवाब समाधान और धन्यवाद के साथ दिया जाता है, पैसे से नहीं।