सुरक्षा

तिजोरीची रचना कशी आहे, आणि त्यात घुसखोरी झाल्यास काय आढळेल.

शेवटचे अद्यतन 21 सप्टेंबर 2026 · अश्युअर्डऑथ, सर्कलरोल एलएलसी द्वारे

AssuredAuth तुम्ही त्यात ठेवलेले टू-फॅक्टर सिक्रेट्स, पासवर्ड्स आणि कार्ड्स यांचे संरक्षण कसे करते, याचे हे सार्वजनिक वर्णन आहे. हे अशा प्रकारे लिहिले आहे की, सुरक्षेची काळजी घेणारा वाचक ॲपच्या विरुद्ध आणि प्रकाशित केलेल्या टेस्ट व्हेक्टर्सच्या (जे hello@assuredauth.com वर विनंती केल्यावर कोणत्याही समीक्षकाला उपलब्ध आहेत) विरुद्ध प्रत्येक दाव्याची पडताळणी करू शकेल. यात जे सत्य आहे तेच सांगितले आहे आणि त्याहून अधिक काही नाही: येथे कोणतीही गोष्ट हल्ल्याच्या पलीकडे असल्याचा दावा केलेला नाही आणि टक्केवारीमध्ये कशाचेही वचन दिलेले नाही.

थोडक्यात सांगायचे तर: व्हॉल्ट एकाच ठिकाणी असतो, म्हणजेच तुमच्या फोनमध्ये. त्यातील प्रत्येक व्हॅल्यू एका कीने एनक्रिप्ट केलेली असते, जी फोनच्या सुरक्षा हार्डवेअरमध्ये असते आणि बाहेर पाठवता येत नाही. आम्ही कोणताही व्हॉल्ट सर्व्हर चालवत नाही, कोणतीही प्रत किंवा की ठेवत नाही. बॅकअप फाईल कधीही कुठेही साठवली न जाणाऱ्या एका पासफ्रेजखाली एनक्रिप्ट केल्यानंतरच फोनमधून बाहेर पाठवली जाते.

समस्येची तक्रार करा: hello@assuredauth.com. शेवटी "कमकुवतपणा कळवणे" पहा.

1. काय एनक्रिप्ट केले आहे, कशाने?

डेटा	फोनवर	की
द्वि-घटकीय रहस्ये (TOTP/HOTP/Steam seeds)	फोनवरकीचेन (iOS) / अँड्रॉइड कीस्टोअर-समर्थित स्टोअर	कीप्लॅटफॉर्मची हार्डवेअर-बद्ध की; डेटाबेसच्या ओळीत केवळ एक संदर्भ (secretRef) असतो, सीड कधीही नसते.
पासवर्ड (पासवर्डचे मूल्य, नोंदी)	फोनवरसीलबंद पंक्ती: AES-256-GCM, प्रत्येक मूल्यासाठी एक यादृच्छिक 96-बिट नॉन्स	कीएक यादृच्छिक 256-बिट डेटा की, जी स्वतः §2 मधील हार्डवेअर की मध्ये गुंडाळलेली असते.
कार्ड (क्रमांक, मुदत, कार्डवरील नाव, CVC)	फोनवरपासवर्डप्रमाणेच शिक्का; CVC ऐच्छिक आहे आणि तुम्ही ते प्रविष्ट केल्यावरच संग्रहित केले जाते.	कीसमान डेटा की
मेटाडेटा (सेवांची नावे, वापरकर्त्यांची नावे, चिन्हे, क्रमवारी)	फोनवरअ‍ॅपचा डेटाबेस (स्विफ्टडेटा / रूम)	कीऑपरेटिंग सिस्टमच्या फाइल एनक्रिप्शनद्वारे संरक्षित; गोपनीय मानले जात नाही.
बॅकअप फाइल (.authbackup)	फोनवरतुम्ही ते कुठेही ठेवा: फाइल्स, आयक्लॉड ड्राइव्ह, गूगल ड्राइव्ह ॲपडेटाफोल्डर, शेअर शीट	कीतुमच्या पासफ्रेजवरून मिळवलेली एक चावी (§3). ॲपल आणि गूगल यांना फक्त सीलबंद फाईल मिळते, बाकी काहीही नाही.
Watch / Wear सोबती ॲप	फोनवरघड्याळाचे स्वतःचे कीचेन / एन्क्रिप्टेडशेअर्डप्रेफरन्सेस	कीवॉच प्लॅटफॉर्मच्या कीज; प्लॅटफॉर्मच्या जोडलेल्या डिव्हाइस चॅनेलद्वारे हस्तांतरित केल्या जातात.
डेस्कटॉप एक्स्टेंशन ट्रॅफिक (मागणीनुसार एक-वेळचे कोड)	फोनवरसाठवले जात नाही; एंड-टू-एंड एनक्रिप्टेड एनव्हलप्सच्या स्वरूपात पाठवले जाते.	कीप्रत्येक पेअरिंगसाठी एक X25519 की पेअर, प्रायव्हेट की कीचेन / कीस्टोअरमध्ये असते; रिले फक्त सायफरटेक्स्ट पाहतो.

डायग्नोस्टिक्समध्ये सिक्रेट स्वीकारणारी कोणतीही मेथड नाही. कोणत्याही ॲनालिटिक्स इव्हेंटमध्ये व्हॉल्ट फील्ड नसते. कोणत्याही बिल्डमध्ये, व्हॉल्टमधील कोणतेही मूल्य कधीही लॉगमध्ये लिहिले जात नाही.

2. प्रत्येक प्लॅटफॉर्मवर कीज कुठे आहेत

आयओएस. डेटा की ही ॲपच्या शेअर्ड कीचेन ॲक्सेस ग्रुपमध्ये, .privateKeyUsage + .userPresence या ॲक्सेस कंट्रोल आणि …ThisDeviceOnly या ॲक्सेसिबिलिटीसह, सिक्युअर एन्क्लेव्ह (kSecAttrTokenIDSecureEnclave) मध्ये जनरेट केलेल्या की द्वारे रॅप केली जाते, जेणेकरून ऑटोफिल एक्सटेन्शन तीच की वापरू शकेल. ॲप, बॅकअप किंवा डीबगरद्वारे प्रायव्हेट की एन्क्लेव्हमधून बाहेर वाचता येत नाही; वापरकर्ता उपस्थित (फेस आयडी, टच आयडी किंवा डिव्हाइस पासकोड) असल्यानंतरच एन्क्लेव्ह ती वापरण्यास संमती देते. ThisDeviceOnly याचा अर्थ असा आहे की फोनच्या आयक्लॉड किंवा आयट्यून्स बॅकअपमध्ये ती की नसते; रिस्टोअर केलेला फोन रिकाम्या व्हॉल्टने सुरू होतो आणि तुमची बॅकअप फाइल व पासफ्रेज विचारतो. पासकोड नसलेला फोन .userPresence की तयार करू शकत नाही (एनक्लेव्ह ती तयार करण्यास नकार देतो), आणि सिम्युलेटरसुद्धा मुद्दाम तोच मार्ग अवलंबतो (त्याचा प्रेझेन्स प्रॉम्प्ट हा एक असा अलर्ट आहे ज्याचे उत्तर कोणतीही चाचणी देऊ शकत नाही): तिथे डेटा की ही एक साधी, केवळ डिव्हाइसपुरती मर्यादित कीचेन आयटम असते — जी अजूनही प्रत्येक बॅकअपमधून वगळलेली असते, फोन लॉक असताना वाचता येत नाही, पण त्यासाठी कोणताही दुसरा प्रॉम्प्ट नसतो — आणि सिक्युरिटी स्क्रीनवर नेमके हेच लिहिलेले असते व पासकोड सेट करण्याचा सल्ला दिला जातो.

अँड्रॉइड. डेटा की ही एका AndroidKeyStore AES-256 की मध्ये गुंडाळलेली असते, जी डिव्हाइसमध्ये StrongBox असल्यास (अन्यथा TEE मध्ये) त्यात तयार केली जाते, ज्यामध्ये setUserAuthenticationRequired(true) आणि बायोमेट्रिक किंवा डिव्हाइस क्रेडेंशियल वापरल्यानंतर 30-सेकंदांची ऑथेंटिकेशन वैधता, setUnlockedDeviceRequired(true), आणि setInvalidatedByBiometricEnrollment(true) हे पर्याय चालू ठेवलेले असतात. तो शेवटचा फ्लॅग भार टाकण्याऐवजी प्रामाणिक आहे: अँड्रॉइड तो फक्त अशा कीजवर लागू करतो ज्यांना प्रत्येक वापरासाठी बायोमेट्रिकची आवश्यकता असते, त्यामुळे डिव्हाइस क्रेडेंशियलला परवानगी असलेल्या या 30-सेकंदांच्या कीवर तो काहीही बदलत नाही — अनोळखी व्यक्तीला त्यात बोट घालण्यापासून रोखणारी गोष्ट म्हणजे, नोंदणी करण्यासाठी पिनची आवश्यकता असते आणि स्क्रीन लॉक काढल्यास ती की कायमची अवैध ठरते. कीस्टोअर कीज निर्यात करण्यायोग्य नसतात आणि अँड्रॉइडच्या क्लाउड बॅकअपमधून वगळल्या जातात. एखादे ॲप स्वतःच्या व्ह्यूजवर (webDomain) जे डोमेन नाव देते, ते फक्त ज्ञात ब्राउझरवरून आलेले मानले जाते; इतर कोणत्याही पॅकेजमधून आलेले डोमेन देखील सिस्टमने त्या पॅकेजसाठी सत्यापित केलेले (डिजिटल असेट लिंक्स) असले पाहिजे, कारण कोणतेही ॲप कोणत्याही डोमेनवर दावा करू शकते.

चोरलेल्या डेटाबेस फाईलसाठी याचा काय अर्थ होतो. SQLite फाईल आणि सीलबंद ओळी हे सांकेतिक मजकूर (ciphertext) आहेत. त्यांना उघडणारी किल्ली (key) ज्या फोनमधून फाईल आली आहे, त्या फोनमधील सुरक्षा हार्डवेअरमध्ये असते आणि ती फाईलसोबत कॉपी केली जाऊ शकत नाही. ऑफलाइन असताना अंदाज लावण्यासारखे काहीही नसते: डेटा की यादृच्छिक (random) असते, ती कोणत्याही व्यक्तीने निवडलेल्या गोष्टीवरून तयार केलेली नसते.

3. बॅकअप फाईल

बॅकअप ही एकमेव गोष्ट आहे जी फोनमधून बाहेर जाते, त्यामुळे तत्त्वतः ऑफलाइन हल्ला होण्याची शक्यता फक्त बॅकअपवरच असते. या रचनेमुळे तो हल्ला खर्चिक बनतो आणि त्याला यशस्वी होण्यासाठी शक्य तितके कमी वाव मिळतो:

• पासफ्रेज किमान 12 अक्षरांचा आहे (शीट त्यापेक्षा कमी अक्षरे स्वीकारते आणि एक सामर्थ्य पट्टी दाखवते).
• पासफ्रेजचा कोणताही संकेत फाईलमध्ये किंवा ॲपमध्ये कुठेही साठवला जात नाही.
• लिहिलेल्या प्रत्येक फाईलसाठी एक नवीन यादृच्छिक 16-बाइट सॉल्ट आणि 12-बाइट नॉन्स.
• संपूर्ण प्रणाली AES-256-GCM आहे, त्यामुळे चुकीचा पासफ्रेज किंवा खराब झालेली फाईल नाकारली जाते आणि कधीही निरुपयोगी फाईलमध्ये रूपांतरित केली जात नाही.
• हेडर (फॉर्मेट, आवृत्ती, KDF पॅरामीटर्स, सॉल्ट) हे अतिरिक्त प्रमाणीकृत डेटा म्हणून GCM टॅगमध्ये जोडलेले असते, त्यामुळे ज्या फाईलचा वर्क फॅक्टर कमी केला आहे ती उघडत नाही.

ही फाईल JSON स्वरूपात आहे आणि कोणत्याही टेक्स्ट एडिटरमध्ये वाचता येते; फक्त सांकेतिक मजकूर (ciphertext) अपारदर्शक आहे. पाच वर्षांनंतर, जेव्हा ॲप बंद झालेले असेल, तेव्हा जर कोणाला ही फाईल सापडली, तर ती नेमकी कशी सीलबंद केली होती हे तो पाहू शकेल आणि 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) आहे, जी दोन्ही प्लॅटफॉर्मवर उपलब्ध आहे. सध्याच्या फोनवर ६४ MiB आणि ३ पासेससाठी सुमारे एक सेकंद लागतो आणि त्यामुळे कोणत्याही हार्डवेअरवर प्रत्येक अंदाजासाठी तेवढीच मेमरी आणि वेळ खर्च होतो — हाच गुणधर्म PBKDF2 मध्ये GPU रिग्सच्या बाबतीत नाही, आणि याच कारणामुळे v2 अस्तित्वात आहे. एक रीडर त्याला माहीत नसलेल्या कीजकडे दुर्लक्ष करतो, त्यामुळे v2 बॉडी दिलेला v1 रीडर कार्ड्स कधीच पाहू शकत नाही.

पुरावा

दोन्ही ॲप्सपासून स्वतंत्र असलेल्या तिसऱ्या अंमलबजावणीद्वारे तीन टेस्ट-व्हेक्टर फाइल्स (बॅकअप v1, बॅकअप v2 आणि Argon2id) तयार केल्या जातात (PBKDF2 आणि AES-GCM साठी Node चे OpenSSL, आणि निर्मितीच्या वेळी संदर्भ अंमलबजावणीच्या प्रकाशित उत्तरांशी तपासलेला WebAssembly Argon2id). प्रत्येक फाइलमध्ये पासफ्रेज, सॉल्ट, नॉन्स, प्लेनटेक्स्ट, डिराइव्ह्ड की, AAD, अपेक्षित सायफरटेक्स्ट आणि टॅग, आणि संपूर्ण फाइल असते. iOS आणि Android वरील युनिट टेस्ट्स त्याच फाइल्स वाचतात आणि त्याच बाइट्सची पडताळणी करतात — त्यामुळे एका प्लॅटफॉर्मवर सील केलेला बॅकअप दुसऱ्या प्लॅटफॉर्मवर उघडेल हे सिद्ध केले जाते, गृहीत धरले जात नाही, आणि तिन्हीमधील एकमत म्हणजे एकाच चुकीच्या दोन प्रती नव्हेत. एक सहयोगी टूल, फोनने प्रत्यक्षात त्याच तिसऱ्या अंमलबजावणीसह लिहिलेली फाईल उघडते आणि वरील नियमांनुसार हेडर तपासते (अचूक फॉरमॅटच्या कीज, त्यामुळे कोणताही हिंट किंवा नाव असू शकत नाही; 16-बाइट सॉल्ट, 12-बाइट नॉन्स, 16-बाइट टॅग स्वतंत्रपणे साठवलेले; आवृत्ती 2 अचूक 64 MiB / 3 / 1 वर; चुकीचा पासफ्रेज नाकारला जातो); स्वयंचलित iOS रन सिम्युलेटरवर एक फाईल लिहितो आणि ती त्या पद्धतीने उघडतो, आणि सिम्युलेटरच्या ॲप कंटेनर, ॲप ग्रुप कंटेनर आणि कीचेन डेटाबेसमध्ये प्रत्येक सीडेड पासवर्ड आणि कार्ड नंबर UTF-8 आणि UTF-16 स्वरूपात शोधतो (0 हिट्स).

4. धोक्याचे मॉडेल

परिस्थिती	त्यांच्याकडे काय आहे	त्यांना काय मिळते
हरवलेला किंवा चोरीला गेलेला फोन, लॉक केलेला	त्यांच्याकडे काय आहेडिव्हाइस, डेटाबेस फाइल, सीलबंद ओळी	त्यांना काय मिळतेसायफरटेक्स्ट. रॅपिंग की सिक्युअर एन्क्लेव्ह / स्ट्रॉंगबॉक्समध्ये असते आणि डिव्हाइस लॉक केल्यानंतर तसेच नवीन बायोमेट्रिक किंवा पासकोड टाकल्यानंतरच ती बाहेर येते. फोन रिमोटली वायप केल्यास (फाइंड माय / फाइंड माय डिव्हाइस), त्यासोबत की मटेरियलदेखील नष्ट होते.
चोरलेली बॅकअप फाईल	त्यांच्याकडे काय आहेक्लाउड अकाउंट, ईमेल, लॅपटॉप येथील .authbackup फाईल	त्यांना काय मिळतेकिमान १२ अक्षरी पासफ्रेजवरून तयार केलेल्या की अंतर्गत एक AES-256-GCM बॉडी, ज्यामध्ये प्रत्येक फाईलसाठी सॉल्ट आणि ६४ MiB × ३ पासेस (v2) साठी Argon2id किंवा ६,००,००० राऊंड्ससाठी PBKDF2 (v1) असेल. कोणताही हिंट नाही, युझरनेम नाही, किंवा खात्यांची स्पष्ट यादी नाही. प्रत्येक अंदाजासाठी संपूर्ण डेरिवेशनची किंमत मोजावी लागते; कोणताही शॉर्टकट नाही. एक मजबूत पासफ्रेज हेच येथील संपूर्ण संरक्षण आहे, आणि ॲप शीटवर तसे नमूद करते.
स्क्रीन अनलॉक असलेले चोरीचे डिव्हाइस	त्यांच्याकडे काय आहेतुमच्या हातातला फोन, अनलॉक केलेला.	त्यांना काय मिळतेकोडची यादी. व्हॉल्ट (पासवर्ड, कार्ड) ॲप लॉकच्या मागे आहे आणि ऑटो-लॉक टायमरवर (तात्काळ / 1 मिनिट / 5 मिनिटे) पुन्हा लॉक होते; डिक्रिप्ट केलेले मूल्य मेमरीमध्ये फक्त तोपर्यंतच असते जोपर्यंत त्याची स्क्रीन ते दाखवत असते. ॲप उघडे असतानाही ऑटोफिल आणि प्लेन-टेक्स्ट एक्सपोर्टसाठी नवीन बायोमेट्रिकची आवश्यकता असते. जर तुम्हाला याची काळजी वाटत असेल, तर "तात्काळ" पर्यायासह ॲप लॉक चालू करा.
त्याच फोनमधील दुर्भावनापूर्ण ॲप	त्यांच्याकडे काय आहेदुसऱ्या ॲपचा सँडबॉक्स, क्लिपबोर्ड, ॲक्सेसिबिलिटी किंवा ओव्हरलेच्या युक्त्या	त्यांना काय मिळतेते आमच्या फाइल्स वाचू शकत नाही (प्लॅटफॉर्म सँडबॉक्सिंग) किंवा आमची की वापरू शकत नाही (ही की आमच्या साइनिंग आयडेंटिटी आणि युझर प्रेझेन्सशी जोडलेली आहे). 30 सेकंदांनंतर क्लिपबोर्डवरून कॉपी आपोआप काढून टाकली जाते; अँड्रॉइडवर, कॉपीला संवेदनशील म्हणून फ्लॅग केले जाते आणि क्लिपबोर्ड हिस्ट्रीमधून वगळले जाते. अँड्रॉइडवर व्हॉल्ट स्क्रीन्स FLAG_SECURE वर सेट केल्या जातात (स्क्रीनशॉट नाही, स्क्रीन रेकॉर्डिंग नाही, स्विचरमध्ये स्क्रीन कोरी दिसते); iOS मध्ये स्विचर थंबनेल कोरा असतो. अँड्रॉइडवरील ऑटोफिल केवळ अशा ॲप्सनाच दिले जाते ज्यांची सिस्टीमने सेव्ह केलेल्या डोमेन (डिजिटल असेट लिंक्स) विरुद्ध पडताळणी केली आहे, त्यामुळे तुमच्यासारख्या दिसणाऱ्या दुसऱ्या ॲपला तुमचा पासवर्ड दिला जात नाही.
फिशिंग पेज	त्यांच्याकडे काय आहेतुम्ही सेव्ह केलेल्या साइटसारखी दिसणारी एक साइट	त्यांना काय मिळतेकाहीही भरले जात नाही. जुळणी नोंदणीयोग्य डोमेनद्वारे (सार्वजनिक प्रत्यय सूची, जी ॲपसोबत बंडल केलेली आणि अद्ययावत केली जाते) केली जाते: login.example.com आणि example.com जुळतात, example.com.evil.net आणि examp1e.com जुळत नाहीत. ॲपमधील ब्राउझरही त्याच प्रकारे जुळणी करतो आणि फक्त त्याच फ्रेममध्ये माहिती भरतो, जी भरण्याच्या क्षणी त्या फ्रेमच्या स्वतःच्या मूळ स्रोताशी पुन्हा तपासली जाते; ज्या होस्टकडे स्वतःचे नोंदणीयोग्य डोमेन नाही — म्हणजे एक आयपी ॲड्रेस, स्थानिक नेटवर्कवरील केवळ एक नाव — तो तंतोतंत जुळतो आणि त्यापेक्षा सैल जुळणी होत नाही. iOS ऑटोफिलमध्ये ॲपलची संबंधित-डोमेन तपासणी जोडली जाते. एखाद्या सारख्या दिसणाऱ्या पासवर्डमध्ये तुम्हाला स्वतः हाताने पेस्ट करावा लागणारा पासवर्ड अजूनही एक धोका आहे; ॲप तो धोका दूर करू शकत नाही, फक्त मदत करणे टाळू शकते.
आमचे स्वतःचे सर्व्हर	त्यांच्याकडे काय आहे—	त्यांना काय मिळतेकोणताही व्हॉल्ट सर्व्हर नाही. AssuredAuth कडे कोणतीही खाती नाहीत, साइन-इन नाही आणि तुमच्या व्हॉल्टची कोणतीही प्रत नाही, त्यामुळे आमच्या बाजूने चोरीला जाण्यासारखे किंवा हॅक होण्यासारखे तुमचे काहीही नाही. सर्व्हर-साइडवर दोन गोष्टी चालतात, ज्यापैकी कोणतीही व्हॉल्टला स्पर्श करत नाही: डेस्कटॉप एक्सटेंशनसाठी एक रिले मेलबॉक्स, जो एंड-टू-एंड एनक्रिप्टेड एनव्हलप्स (वन-टाइम कोड, जे वाचल्यावर डिलीट केले जातात; रिलेकडे कधीही की नसते) साठवतो, आणि पर्यायी खाजगी कनेक्शनचे एक्झिट सर्व्हर्स, जे ट्रॅफिक वाहून नेतात आणि कोणतेही ॲक्सेस लॉग ठेवत नाहीत.
समन्स किंवा सरकारी विनंती	त्यांच्याकडे काय आहेआम्हाला उद्देशून असलेली कायदेशीर प्रक्रिया	त्यांना काय मिळतेसुपूर्द करण्यासारखे काहीही नाही: आमच्याकडे तिजोरी नाही, चावी नाही, सांकेतिक भाषा नाही आणि कोणताही बॅकअप नाही. आम्हाला हे सांगायला भाग पाडले जाऊ शकते; पण जे अस्तित्वातच नाही ते सादर करायला आम्हाला भाग पाडले जाऊ शकत नाही.

5. क्लिपबोर्ड, स्क्रीनशॉट आणि स्मृती

• कॉपी केल्यावर व्हॅल्यू 30 सेकंदांसाठी क्लिपबोर्डवर राहते, आणि जर ती अजूनही आपलीच असेल तर नंतर ती काढून टाकली जाते. अँड्रॉइडवर क्लिपला EXTRA_IS_SENSITIVE असे चिन्हांकित केले जाते, त्यामुळे सिस्टम तिला क्लिपबोर्ड प्रिव्ह्यू आणि हिस्ट्रीमधून लपवते; iOS वर पेस्टबोर्ड आयटम केवळ स्थानिक असतो (तो इतर डिव्हाइसेसना हँडऑफ केला जात नाही).
• अँड्रॉइडवर व्हॉल्ट स्क्रीन (पासवर्ड, पासवर्ड, कार्ड्स, कार्ड, पासफ्रेज शीट्स, प्लेन-टेक्स्ट एक्सपोर्ट) FLAG_SECURE सेट करतात. iOS मध्ये असा कोणताही समकक्ष फ्लॅग नाही; ॲप स्विचरमध्ये ॲपचे थंबनेल रिकामे होते आणि डीफॉल्टनुसार व्हॅल्यूज डोळ्याच्या चिन्हामागे असतात.
• डिक्रिप्ट केलेली मूल्ये केवळ स्क्रीनवर दिसत असेपर्यंतच मेमरीमध्ये राहतात आणि स्क्रीन बंद झाल्यावर किंवा ॲप लॉक झाल्यावर काढून टाकली जातात. डेटा की एका विनंतीसाठी अनरॅप केली जाते आणि लॉक झाल्यावर कॅश केली जात नाही.
• प्लेन-टेक्स्ट एक्सपोर्ट उपलब्ध आहे (त्यामुळे तुम्ही कधीही बाहेर पडू शकता) आणि त्यासाठी एक कन्फर्मेशन शीट व नवीन बायोमेट्रिक आवश्यक आहे, तसेच त्याची स्क्रीन देखील FLAG_SECURE आहे.

6. ऑटोफिल: काय भरले जाते आणि काय नाही.

कुठे	पासवर्ड	कार्ड्स
iOS: सफारी आणि ॲप्स (ऑटोफिल एक्सटेंशन)	पासवर्डहोय, एक्सटेंशनमध्ये (LAContext) नवीन फेस आयडी / टच आयडी / पासकोड टाकल्यानंतर, आणि केवळ ज्या नोंदणीयोग्य डोमेनसाठी एन्ट्री सेव्ह केली होती, त्याच डोमेनसाठी, ॲप्सकरिता ॲपलच्या असोसिएटेड-डोमेन्स तपासणीसह हे शक्य आहे.	कार्ड्सनाही. सफारीमधील कार्ड ऑटोफिल हे केवळ ॲपलचेच आहे; कार्ड स्क्रीनवर "ॲश्युअर्डऑथ ब्राउझरमध्ये आणि कॉपीसह भरले जाते" असे लिहिलेले असते आणि त्यापलीकडे दुसरे कोणतेही आश्वासन दिले जात नाही.
अँड्रॉइड: अॅप्स आणि क्रोम (ऑटोफिलसर्व्हिस)	पासवर्डहोय, प्रति-डेटासेट प्रमाणीकरण: सिस्टम माहिती भरण्यापूर्वी बायोमेट्रिक प्रॉम्प्ट दाखवते; जेव्हा डिजिटल असेट लिंक्स ॲप पॅकेजला सेव्ह केलेल्या डोमेनशी जोडते, तेव्हाच ते जुळते.	कार्ड्सहोय, क्रेडिट कार्ड नंबर, क्रेडिट कार्ड एक्सपायरी* आणि क्रेडिट कार्ड सिक्युरिटी कोड हे संकेत, त्याच बायोमेट्रिक गेटवर मिळतात.
अ‍ॅश्युअर्डऑथ ब्राउझर (दोन्ही प्लॅटफॉर्म)	पासवर्डहोय, नोंदणीयोग्य डोमेनद्वारे — एक असा होस्ट ज्याचे स्वतःचे तंतोतंत जुळणारे काहीही नाही — विचारलेल्या फ्रेममध्ये, भरण्यापूर्वी बायोमेट्रिक.	कार्ड्सहोय, फील्ड डिटेक्शनद्वारे, भरण्यापूर्वी बायोमेट्रिक.
कॉपी बटणे	पासवर्डअ‍ॅप लॉकच्या मागे, 30-सेकंदांचा क्लिपबोर्ड	कार्ड्सक्रमांक, मुदत, सीव्हीसी (नियम सारखेच)

सारख्या दिसणाऱ्या होस्टवर काहीही भरत नाही. बायोमेट्रिकशिवाय काहीही भरत नाही.

7. जे कधीच घडत नाही

कोणताही व्हॉल्ट सर्व्हर नाही. व्हॉल्ट फील्ड असलेले कोणतेही ॲनालिटिक्स नाही. कन्फर्म शीट आणि नवीन बायोमेट्रिकशिवाय साधा मजकूर निर्यात नाही. व्हॉल्ट स्क्रीनवर कोणतेही थर्ड-पार्टी SDK लोड केलेले नाही. व्हॉल्ट स्क्रीनचा कोणताही स्क्रीनशॉट नाही. कोणताही पासफ्रेज हिंट नाही. कोणत्याही बिल्डमध्ये व्हॅल्यूजची लॉगिंग नाही.

8. ज्यापासून आपण संरक्षण करू शकत नाही

अंदाज लावता येईल इतका कमकुवत पासफ्रेज. असा फोन ज्याची ऑपरेटिंग सिस्टीम मुळापासून हॅक झालेली आहे (जेलब्रेक केलेले किंवा रूट केलेले डिव्हाइस वरील सर्व गोष्टींबद्दल ॲपला खोटे सांगू शकते). टायपिंग करत असताना एखाद्या व्यक्तीवर नजर ठेवली जात आहे. तुम्ही पेस्ट करत असलेल्या डेस्कटॉपवरील मालवेअर. आम्ही हे यासाठी सांगत आहोत जेणेकरून वरील यादी जशी आहे तशीच वाचली जाईल: म्हणजेच, डिझाइनद्वारे काढून टाकल्या जाऊ शकणाऱ्या गोष्टी.

9. पुनरावलोकन स्थिती

या डिझाइनची दोन्ही प्लॅटफॉर्मवरील प्रकाशित ज्ञात उत्तरांच्या आधारे आणि स्वतःच्या क्रॉस-प्लॅटफॉर्म व्हेक्टर्सच्या आधारे युनिट-टेस्ट केली गेली आहे. स्टोअर लिस्टिंगवर व्हॉल्टची जाहिरात करण्यापूर्वी बाह्य पुनरावलोकन करणे हे मालकाच्या नियोजनात आहे; जोपर्यंत ते होत नाही, तोपर्यंत या दस्तऐवजात तसे नमूद केले जाईल.

10. जिथे गोष्टी चालतात

व्हॉल्टमधील काहीही फोनच्या बाहेर जात नाही, परंतु त्याच्याशी संबंधित काही गोष्टी इतर लोकांच्या मशीनवर चालतात. ही त्यांची यादी आहे, आणि प्रत्येकामध्ये काय आहे ते येथे दिले आहे; डेटा प्रवाहांचे वर्णन https://assuredauth.com/privacy येथील गोपनीयता धोरणामध्ये केले आहे.

• Google Cloud / Firebase — डेस्कटॉप एक्सटेंशनसाठी रिले मेलबॉक्स (एंड-टू-एंड एनक्रिप्टेड एनव्हलप्स, वाचल्यावर डिलीट होतात), पुश टोकन्स, खरेदीची स्थिती आणि संपर्क फॉर्मद्वारे पाठवलेले संदेश.
• Vercel — assuredauth.com, त्याची पृष्ठे आणि त्यामागील लहान कार्यप्रणाली.
• व्हल्टर — खाजगी कनेक्शनचे एक्झिट सर्व्हर्स. ट्रॅफिक त्यांच्यामधून जाते; काहीही साठवले जात नाही.
• ॲपल आणि गुगल प्ले — त्यांच्या स्वतःच्या स्टोअरमधील खरेदी आणि सदस्यता.
• पोस्टहॉग — उत्पादन विश्लेषण: काय वापरले गेले याची गणना, कोणत्याही ओळखीशी जोडलेली नाही.
• रेव्हेन्यूकॅट — सदस्यतेची स्थिती: सक्रिय किंवा कालबाह्य, आणि कोणत्या योजनेवर आहे.

प्रत्येक घटक त्याच्या ओळीत नमूद केलेली माहितीच ठेवतो आणि संग्रहातील काहीही ठेवत नाही. जेव्हा उत्पादन बदलते, तेव्हा यादी बदलते आणि त्यासोबत हा विभागही बदलतो.

कमकुवतपणाची तक्रार करणे

येथे वर्णन केलेल्या कोणत्याही गोष्टीत तुम्हाला त्रुटी आढळल्यास, hello@assuredauth.com वर "Security" या विषयासह लिहा. कृपया प्लॅटफॉर्म, ॲप आवृत्ती आणि आवश्यक पायऱ्यांचा समावेश करा; तुमच्या स्वतःच्या डेटाचा वापर करणारा पुरावा पुरेसा आहे, आणि आम्ही विनंती करतो की तुम्ही इतर लोकांच्या डेटावर चाचणी करू नका. आम्ही PGP की देत ​​नाही; जर अहवाल साध्या ईमेलमध्ये पाठवला जाऊ नये असे वाटत असेल, तर पहिल्याच संदेशात तसे सांगा आणि आम्ही दुसऱ्या मार्गाची व्यवस्था करू.

या बदल्यात आम्ही तुम्हाला वचन देतो की: आम्ही तीन कामकाजाच्या दिवसांत पोचपावती देऊ, त्यावर काम करत असताना तुम्हाला माहिती देत ​​राहू, त्याबद्दल काहीही प्रकाशित करण्यापूर्वी जे सत्य आहे ते दुरुस्त करू, आणि तुम्हाला श्रेय हवे असल्यास आम्ही ते येथे देऊ. खालील मर्यादेत सद्भावनेने केलेल्या संशोधनावर आम्ही कोणतीही कायदेशीर कारवाई करणार नाही.

व्याप्तीमध्ये: iOS आणि अँड्रॉइड ॲप्स, वॉच ॲप्स, डेस्कटॉप एक्सटेंशन, assuredauth.com आणि त्याचा API. व्याप्तीबाहेर: स्वतः ॲप स्टोअर आणि गूगल प्ले, वर नमूद केलेले प्रोव्हायडर्स, कोणाचेही सोशल इंजिनिअरिंग, आणि सेवा नाकारणे (डिनायल ऑफ सर्व्हिस).

सध्या कोणतेही बक्षीस नाही. तक्रारीला उपाय आणि धन्यवाद देऊन उत्तर दिले जाते, पैसे देऊन नाही.