सुरक्षा
भल्ट कसरी बनाइन्छ, र कस्तो प्वाल पर्न सक्छ।
अन्तिम अपडेट 21 सेप्टेम्बर 2026 · AssuredAuth, CircleRoll LLC द्वारा
यो AssuredAuth ले तपाईंले यसमा राख्नुहुने दुई-कारक गोप्य कुराहरू, पासवर्डहरू र कार्डहरूलाई कसरी सुरक्षित राख्छ भन्ने सार्वजनिक विवरण हो। यो लेखिएको छ ताकि सुरक्षा-मनन गर्ने पाठकले एप र प्रकाशित परीक्षण भेक्टरहरू विरुद्ध प्रत्येक दावी जाँच गर्न सकून् (hello@assuredauth.com मा अनुरोधमा कुनै पनि समीक्षकलाई उपलब्ध छ)। यसले के सत्य हो र के होइन भनेर भन्छ: यहाँ कुनै पनि कुराले आक्रमणभन्दा बाहिरको दाबी गर्दैन, र प्रतिशतमा केही पनि वाचा गरिएको छैन।
छोटो संस्करण: भल्ट एकै ठाउँमा अवस्थित छ, तपाईंको फोनमा। यसमा भएका प्रत्येक मानहरू फोनको सुरक्षा हार्डवेयरले राख्ने र निर्यात गर्न नसक्ने कुञ्जीसँग इन्क्रिप्ट गरिएको हुन्छ। हामी कुनै भल्ट सर्भर चलाउँदैनौं, कुनै प्रतिलिपि राख्दैनौं र कुनै कुञ्जी राख्दैनौं। ब्याकअप फाइल फोनलाई पासफ्रेज अन्तर्गत इन्क्रिप्ट गरिसकेपछि मात्र छोडिन्छ जुन कहिल्यै कतै भण्डारण हुँदैन।
समस्या रिपोर्ट गर्नुहोस्: hello@assuredauth.com. अन्त्यमा "कमजोरी रिपोर्ट गर्दै" हेर्नुहोस्।
1. के इन्क्रिप्ट गरिएको छ, के सँग
| डेटा | फोनमा | कुञ्जी |
|---|---|---|
| दुई-कारक रहस्यहरू (TOTP/HOTP/स्टीम बीउहरू) | फोनमाकिचेन (iOS) / एन्ड्रोइड किस्टोर-समर्थित स्टोर | कुञ्जीप्लेटफर्मको हार्डवेयर-बाउन्ड कुञ्जी; डाटाबेस पङ्क्तिले केवल एउटा सन्दर्भ (secretRef) राख्छ, कहिल्यै पनि बीज |
| पासवर्डहरू (पासवर्ड मान, नोटहरू) | फोनमासिल गरिएको पङ्क्ति: AES-256-GCM, प्रति मान एक अनियमित 96-बिट नन्स | कुञ्जीएउटा अनियमित 256-बिट डेटा कुञ्जी, जुन आफैं §2 मा हार्डवेयर कुञ्जीद्वारा बेरिएको हुन्छ। |
| कार्डहरू (नम्बर, म्याद समाप्ति, कार्डमा नाम, CVC) | फोनमापासवर्डहरू जस्तै छाप; CVC वैकल्पिक हो र तपाईंले प्रविष्ट गर्नुभयो भने मात्र भण्डारण गरिन्छ। | कुञ्जीउही डेटा कुञ्जी |
| मेटाडेटा (सेवा नाम, प्रयोगकर्ता नाम, आइकन, क्रमबद्ध क्रम) | फोनमाएपको डाटाबेस (स्विफ्टडेटा / कोठा) | कुञ्जीअपरेटिङ सिस्टमको फाइल इन्क्रिप्शनद्वारा सुरक्षित; गोप्य नभएको रूपमा व्यवहार गरिन्छ। |
| ब्याकअप फाइल (.authbackup) | फोनमातपाईंले जहाँ राख्नुहुन्छ: फाइलहरू, iCloud ड्राइभ, गुगल ड्राइभ एपडेटा फोल्डर, एउटा सेयर पाना | कुञ्जीतपाईंको पासफ्रेज (§3) बाट लिइएको कुञ्जी। एप्पल र गुगलले सिल गरिएको फाइल प्राप्त गर्छन् र अरू केही पनि प्राप्त गर्दैनन्। |
| Watch / Wear साथी एप | फोनमाघडीको आफ्नै किचेन / इन्क्रिप्टेडशेयरप्रिफरन्सेस | कुञ्जीवाच प्लेटफर्मको कुञ्जीहरू; प्लेटफर्मको जोडी-उपकरण च्यानल मार्फत स्थानान्तरण गरियो |
| डेस्कटप एक्सटेन्सन ट्राफिक (अनुरोधमा एक-पटके कोडहरू) | फोनमाभण्डारण गरिएको छैन; एन्ड-टु-एन्ड इन्क्रिप्टेड खामको रूपमा रिले गरिएको | कुञ्जीप्रति जोडी X25519 कुञ्जी जोडी, किचेन / किस्टोरमा निजी कुञ्जी; रिलेले सिफरटेक्स्ट मात्र देख्छ। |
डायग्नोस्टिक्ससँग गोप्य कुरा स्वीकार गर्ने कुनै विधि छैन। कुनै पनि विश्लेषणात्मक कार्यक्रममा भल्ट क्षेत्र हुँदैन। कुनै पनि निर्माणमा, भल्टबाट कुनै पनि मान कहिल्यै लगमा लेखिएको हुँदैन।
2. प्रत्येक प्लेटफर्ममा साँचोहरू कहाँ बस्छन्
आईओएस। डेटा कुञ्जी सुरक्षित एन्क्लेभ (kSecAttrTokenIDSecureEnclave) भित्र उत्पन्न भएको कुञ्जीद्वारा बेरिएको हुन्छ जसमा पहुँच नियन्त्रण .privateKeyUsage + .userPresence, पहुँचयोग्यता ...ThisDeviceOnly हुन्छ, एपको साझा किचेन पहुँच समूहमा ताकि AutoFill एक्सटेन्सनले उही कुञ्जी प्रयोग गर्न सकोस्। निजी कुञ्जीलाई एपद्वारा, ब्याकअपद्वारा, वा डिबगरद्वारा एन्क्लेभबाट पढ्न सकिँदैन; प्रयोगकर्ता उपस्थित भएपछि मात्र एन्क्लेभले यसलाई प्रयोग गर्न सहमत हुन्छ (फेस आईडी, टच आईडी वा उपकरण पासकोड)। ThisDeviceOnly को अर्थ फोनको iCloud वा iTunes ब्याकअपले कुञ्जी बोक्दैन; पुनर्स्थापित फोन खाली भल्टबाट सुरु हुन्छ र तपाईंको ब्याकअप फाइल र पासफ्रेजको लागि सोध्छ। पासकोड नभएको फोनले .userPresence कुञ्जी गेट गर्न सक्दैन (एनक्लेभले एउटा सिर्जना गर्न अस्वीकार गर्छ), र सिम्युलेटरले डिजाइनद्वारा उही बाटो लिन्छ (यसको उपस्थिति प्रम्प्ट एउटा चेतावनी हो जुन कुनै परीक्षणले जवाफ दिन सक्दैन): त्यहाँ डेटा कुञ्जी एक सादा उपकरण-मात्र किचेन वस्तु हो - अझै पनि प्रत्येक ब्याकअपबाट बाहिर, फोन लक हुँदा पनि पढ्न नसकिने, तर दोस्रो प्रम्प्ट बिना - र सुरक्षा स्क्रिनले ठ्याक्कै त्यही भन्छ र पासकोड सेट गर्न सुझाव दिन्छ।
एन्ड्रोइड। डेटा कुञ्जीलाई AndroidKeyStore AES-256 कुञ्जीद्वारा बेरिएको हुन्छ, जुन उपकरणमा एउटा (अन्यथा TEE) हुँदा StrongBox मा उत्पन्न हुन्छ, setUserAuthenticationRequired(true) र बायोमेट्रिक वा उपकरण प्रमाणीकरण, setUnlockedDeviceRequired(true), र setInvalidatedByBiometricEnrollment(true) पछि 30-सेकेन्ड प्रमाणीकरण वैधता हुन्छ। त्यो अन्तिम झण्डा लोड-बेयरिङको सट्टा इमानदार छ: एन्ड्रोइडले यसलाई प्रत्येक प्रयोगमा बायोमेट्रिक माग गर्ने कुञ्जीहरूमा मात्र लागू गर्दछ, त्यसैले उपकरण प्रमाणीकरणको साथ यो 30-सेकेन्ड कुञ्जीमा यसले केहि परिवर्तन गर्न अनुमति दिन्छ - अपरिचित व्यक्तिको औंला बाहिर राख्ने कुरा के हो भने दर्ता गर्न PIN आवश्यक पर्दछ, र स्क्रिन लक हटाउनाले कुञ्जीलाई राम्रोको लागि अमान्य बनाउँछ। Keystore कुञ्जीहरू निर्यात योग्य छैनन् र एन्ड्रोइडको क्लाउड ब्याकअपबाट बहिष्कृत छन्। एउटा डोमेन जुन एपले आफ्नै दृश्यहरू (webDomain) मा नाम दिन्छ, केवल ज्ञात ब्राउजरबाट मात्र विश्वास गरिन्छ; कुनै पनि अन्य प्याकेजबाट यो प्रणालीले त्यो प्याकेज (डिजिटल सम्पत्ति लिङ्कहरू) को लागि प्रमाणित गरेको हुनुपर्छ, किनकि कुनै पनि एपले कुनै पनि डोमेन दाबी गर्न सक्छ।
चोरी भएको डाटाबेस फाइलको लागि यसको अर्थ के हो? SQLite फाइल र सिल गरिएका पङ्क्तिहरू सिफरटेक्स्ट हुन्। तिनीहरूलाई खोल्ने कुञ्जी फाइल आएको फोनको सुरक्षा हार्डवेयरमा रहन्छ र फाइलसँग प्रतिलिपि गर्न सकिँदैन। अफलाइन अनुमान गर्न केहि छैन: डेटा कुञ्जी अनियमित छ, व्यक्तिले रोजेको कुनै पनि कुराबाट व्युत्पन्न गरिएको छैन।
3. ब्याकअप फाइल
ब्याकअपहरू फोनबाट बाहिरिने एउटा चीज हो, त्यसैले सिद्धान्तमा अफलाइन आक्रमण सम्भव हुने एक मात्र ठाउँ तिनीहरू हुन्। डिजाइनले त्यो आक्रमणलाई महँगो बनाउँछ र यसलाई सकेसम्म कम काम गर्न दिन्छ:
- पासफ्रेज कम्तिमा 12 वर्णको छ (पानाले कमलाई अस्वीकार गर्छ र बलियो पट्टी देखाउँछ)।
- कुनै पनि पासफ्रेज सङ्केत फाइल वा एपमा कतै पनि भण्डारण गरिएको छैन।
- प्रत्येक फाइल लेखिएको लागि ताजा अनियमित 16-बाइट नुन र 12-बाइट नन्स।
- सम्पूर्ण भाग AES-256-GCM हो, त्यसैले गलत पासफ्रेज वा बिग्रिएको फाइल अस्वीकार गरिन्छ, कहिल्यै फोहोरमा डिक्रिप्ट गरिँदैन।
- हेडर (ढाँचा, संस्करण, KDF प्यारामिटरहरू, साल्ट) 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) हो, जुन दुवै प्लेटफर्महरूमा बिक्री गरिन्छ। हालको फोनमा ६४ MiB र ३ पासहरूले लगभग एक सेकेन्ड लिन्छ र प्रत्येक अनुमानले कुनै पनि हार्डवेयरमा त्यो मेमोरी र समय खर्च गर्छ — GPU रिगहरू विरुद्ध PBKDF2 को अभाव भएको गुण, र v2 अवस्थित हुनुको कारण। पाठकले थाहा नभएको कुञ्जीहरूलाई बेवास्ता गर्छ, त्यसैले v2 बडी दिइएको v1 पाठकले कहिल्यै कार्डहरू देख्दैन।
प्रमाण
तीन परीक्षण-भेक्टर फाइलहरू (ब्याकअप v1, ब्याकअप v2 र Argon2id) तेस्रो कार्यान्वयनद्वारा उत्पन्न हुन्छन्, जुन दुवै एपहरूबाट स्वतन्त्र हुन्छन् (PBKDF2 र AES-GCM को लागि नोडको OpenSSL, सन्दर्भ कार्यान्वयनको प्रकाशित उत्तरहरू विरुद्ध जेनेरेसन समयमा जाँच गरिएको WebAssembly Argon2id)। प्रत्येकमा पासफ्रेज, साल्ट, नोन्स, प्लेनटेक्स्ट, व्युत्पन्न कुञ्जी, AAD, अपेक्षित साइफरटेक्स्ट र ट्याग, र पूर्ण फाइल हुन्छ। iOS र एन्ड्रोइडमा युनिट परीक्षणहरूले एउटै फाइलहरू पढ्छन् र एउटै बाइटहरू दाबी गर्छन् — त्यसैले एउटा प्लेटफर्ममा छापिएको ब्याकअप अर्कोमा खोल्न प्रमाणित हुन्छ, मानिएको छैन, र तीनवटैको सम्झौता एउटै गल्तीको दुई प्रतिलिपि होइन। एउटा साथी उपकरणले फोनले वास्तवमा त्यही तेस्रो कार्यान्वयनको साथ लेखेको फाइल खोल्छ र माथिका नियमहरू विरुद्ध हेडर जाँच गर्दछ (ठ्याक्कै ढाँचाको कुञ्जीहरू, त्यसैले कुनै संकेत वा नाम उपस्थित हुन सक्दैन; 16-बाइट साल्ट, 12-बाइट नोन्स, 16-बाइट ट्याग छुट्टै भण्डारण गरिएको; संस्करण 2 ठीक 64 MiB / 3 / 1 मा; गलत पासफ्रेज अस्वीकार गरियो); स्वचालित iOS रनले सिम्युलेटरमा एउटा लेख्छ र त्यसरी खोल्छ, र सिम्युलेटरको एप कन्टेनर, एप ग्रुप कन्टेनर र किचेन डाटाबेसलाई UTF-8 र UTF-16 (0 हिट) को रूपमा प्रत्येक सीडेड पासवर्ड र कार्ड नम्बरको लागि खोजी गर्दछ।
4. खतरा मोडेल
| अवस्था | उनीहरूसँग के छ | उनीहरूले के पाउँछन् |
|---|---|---|
| हराएको वा चोरी भएको फोन, लक गरिएको | उनीहरूसँग के छउपकरण, डाटाबेस फाइल, सिल गरिएका पङ्क्तिहरू | उनीहरूले के पाउँछन्साइफरटेक्स्ट। र्यापिङ कुञ्जी सेक्योर एन्क्लेभ / स्ट्रङ्गबक्समा हुन्छ र उपकरण लक र नयाँ बायोमेट्रिक वा पासकोड पछि मात्र रिलीज हुन्छ। फोनलाई टाढाबाट वाइप गर्दा (मेरो खोज्नुहोस् / मेरो उपकरण खोज्नुहोस्) यसको साथमा कुञ्जी सामग्री नष्ट हुन्छ। |
| चोरी भएको ब्याकअप फाइल | उनीहरूसँग के छक्लाउड खाता, इमेल, ल्यापटपबाट .authbackup फाइल | उनीहरूले के पाउँछन्कम्तिमा १२ वर्णको पासफ्रेजबाट लिइएको कुञ्जी अन्तर्गत AES-256-GCM बडी, प्रति-फाइल साल्ट र Argon2id ६४ MiB × ३ पास (v2) मा वा PBKDF2 ६००,००० राउन्ड (v1) मा। कुनै संकेत छैन, कुनै प्रयोगकर्ता नाम छैन, कुनै खाता सूची छैन। प्रत्येक अनुमानले पूर्ण व्युत्पन्न खर्च गर्छ; कुनै सर्टकट छैन। बलियो पासफ्रेज यहाँ सम्पूर्ण बचाउ हो, र एपले पानामा त्यसै भन्छ। |
| स्क्रिन अनलक भएको चोरी भएको उपकरण | उनीहरूसँग के छतपाईंको हातमा फोन, अनलक | उनीहरूले के पाउँछन्कोडहरूको सूची। भल्ट (पासवर्ड, कार्डहरू) एप लकको पछाडि हुन्छ र अटो-लक टाइमरमा पुन: लक हुन्छ (तुरुन्तै / 1 मिनेट / 5 मिनेट); यसको स्क्रिनले देखाउँदा मात्र मेमोरीमा डिक्रिप्ट गरिएको मान अवस्थित हुन्छ। अटोफिल र प्लेन-टेक्स्ट एक्सपोर्टले एप खुला हुँदा पनि नयाँ बायोमेट्रिकको लागि सोध्छ। यदि तपाईंलाई यस्तो चिन्ता छ भने "तुरुन्तै" भनेर एप लक खोल्नुहोस्। |
| एउटै फोनमा हानिकारक एप | उनीहरूसँग के छअर्को एपको स्यान्डबक्स, क्लिपबोर्ड, पहुँच वा ओभरले ट्रिक्सहरू | उनीहरूले के पाउँछन्यसले हाम्रा फाइलहरू (प्लेटफर्म स्यान्डबक्सिङ) पढ्न सक्दैन वा हाम्रो कुञ्जी प्रयोग गर्न सक्दैन (कुञ्जी हाम्रो हस्ताक्षर पहिचान र प्रयोगकर्ता उपस्थितिमा बाँधिएको हुन्छ)। प्रतिलिपिहरू क्लिपबोर्डबाट 30 सेकेन्ड पछि खाली हुन्छन्; एन्ड्रोइडमा प्रतिलिपिलाई संवेदनशील फ्ल्याग गरिएको छ र क्लिपबोर्ड इतिहासबाट बहिष्कृत गरिएको छ। भल्ट स्क्रिनहरूले एन्ड्रोइडमा FLAG_SECURE सेट गर्दछ (कुनै स्क्रिनसट छैन, कुनै स्क्रिन रेकर्डिङ छैन, स्विचरमा खाली छ); iOS ले स्विचर थम्बनेल खाली गर्दछ। एन्ड्रोइडमा अटोफिल केवल एपहरूमा मात्र सेवा गरिन्छ जुन प्रणालीले बचत गरिएको डोमेन (डिजिटल सम्पत्ति लिङ्कहरू) विरुद्ध प्रमाणित गरेको छ, त्यसैले एक जस्तै देखिने एपलाई तपाईंको पासवर्ड प्रस्ताव गरिएको छैन। |
| फिसिङ पृष्ठ | उनीहरूसँग के छतपाईंले सुरक्षित गर्नुभएको साइट जस्तै देखिने साइट | उनीहरूले के पाउँछन्केहि पनि भरिँदैन। मिलान दर्तायोग्य डोमेन (सार्वजनिक प्रत्यय सूची, एपसँग बन्डल र अद्यावधिक गरिएको) द्वारा गरिन्छ: login.example.com र example.com मिलान, example.com.evil.net र examp1e.com ले गर्दैन। इन-एप ब्राउजरले उस्तै तरिकाले मेल खान्छ र सोधेको फ्रेममा मात्र भर्छ, भर्ने समयमा त्यो फ्रेमको आफ्नै उत्पत्ति विरुद्ध पुन: जाँच गरिन्छ; आफ्नै दर्तायोग्य डोमेन नभएको होस्ट - IP ठेगाना, स्थानीय नेटवर्कमा खाली नाम - ठ्याक्कै मेल खान्छ र केहि पनि हराउँदैन। iOS AutoFill ले एप्पलको सम्बद्ध-डोमेन जाँच थप्छ। तपाईंले हातले टाँस्नुपर्ने पासवर्ड समान देखिने ठाउँमा अझै पनि जोखिम हो; एपले त्यो हटाउन सक्दैन, केवल मद्दत गर्नबाट बच्न सक्छ। |
| हाम्रा आफ्नै सर्भरहरू | उनीहरूसँग के छ— | उनीहरूले के पाउँछन्त्यहाँ कुनै भल्ट सर्भर छैन। AssuredAuth सँग कुनै खाता छैन, साइन-इन छैन र तपाईंको भल्टको प्रतिलिपि छैन, त्यसैले हाम्रो तर्फबाट चोरी र क्र्याक गर्न तपाईंको केहि पनि छैन। दुई चीजहरू सर्भर-साइडमा चल्छन्, जसमध्ये कुनै पनि भल्टलाई छुँदैन: डेस्कटप एक्सटेन्सनको लागि रिले मेलबक्स, जसले एन्ड-टु-एन्ड इन्क्रिप्टेड खामहरू भण्डारण गर्दछ (एक-पटके कोडहरू, पढ्दा मेटाइन्छ; रिलेमा कहिल्यै कुञ्जी हुँदैन), र वैकल्पिक निजी जडानको निकास सर्भरहरू, जसले ट्राफिक बोक्छ र कुनै पहुँच लगहरू राख्दैन। |
| समन वा सरकारी अनुरोध | उनीहरूसँग के छहामीलाई सम्बोधन गरिएको कानुनी प्रक्रिया | उनीहरूले के पाउँछन्हस्तान्तरण गर्न केही छैन: हामीसँग कुनै भल्ट छैन, कुनै चाबी छैन, कुनै पासफ्रेज छैन र कुनै ब्याकअप छैन। हामीलाई त्यो भन्न बाध्य पार्न सकिन्छ; हामीलाई त्यस्तो चीज उत्पादन गर्न बाध्य पार्न सकिँदैन जुन अवस्थित छैन। |
5. क्लिपबोर्ड, स्क्रिनसट र मेमोरी
- प्रतिलिपिले मानलाई क्लिपबोर्डमा 30 सेकेन्डको लागि राख्छ, त्यसपछि यदि यो अझै पनि हाम्रो हो भने यसलाई खाली गर्छ। एन्ड्रोइडमा क्लिपलाई EXTRA_IS_SENSITIVE चिन्ह लगाइएको छ त्यसैले प्रणालीले यसलाई क्लिपबोर्ड पूर्वावलोकन र इतिहासबाट लुकाउँछ; iOS मा पेस्टबोर्ड वस्तु स्थानीय-मात्र हो (अन्य उपकरणहरूमा ह्यान्डअफ गरिएको छैन)।
- भल्ट स्क्रिनहरू (पासवर्डहरू, पासवर्ड, कार्डहरू, कार्ड, पासफ्रेज पानाहरू, सादा-पाठ निर्यात) ले एन्ड्रोइडमा FLAG_SECURE सेट गर्दछ। iOS मा कुनै समान झण्डा छैन; एपले एप स्विचरमा यसको थम्बनेल खाली गर्दछ र मानहरू पूर्वनिर्धारित रूपमा आँखा टगल पछाडि हुन्छन्।
- डिक्रिप्ट गरिएका मानहरू स्क्रिनले देखाउँदा मात्र मेमोरीमा रहन्छन् र यो टाढा जाँदा वा एप लक हुँदा छोडिन्छन्। अनुरोधको लागि डेटा कुञ्जी खोलिएको हुन्छ र लकभरि क्यास गरिएको हुँदैन।
- प्लेन-टेक्स्ट एक्सपोर्ट अवस्थित छ (तपाईं सधैं छोड्न सक्नुहुन्छ) र पुष्टि पाना र ताजा बायोमेट्रिक पछाडि छ, र यसको स्क्रिन पनि FLAG_SECURE छ।
6. अटोफिल: के भरिन्छ, के भरिँदैन
| कहाँ | पासवर्डहरू | कार्डहरू |
|---|---|---|
| iOS: सफारी र एपहरू (स्वत: भरण विस्तार) | पासवर्डहरूहो, एक्सटेन्सन (LAContext) मा नयाँ फेस आईडी / टच आईडी / पासकोड पछि, र केवल दर्तायोग्य डोमेनको लागि प्रविष्टि सुरक्षित गरिएको थियो, एप्पलको सम्बद्ध-डोमेनहरूले एपहरूको लागि जाँच गर्दछ। | कार्डहरूहोइन। सफारीमा कार्ड अटोफिल एप्पलको मात्र हो; कार्ड स्क्रिनमा "AsuredAuth ब्राउजरमा र प्रतिलिपि सहित भरिन्छ" भनिएको छ र अरू केही वाचा गर्दैन। |
| एन्ड्रोइड: एप्स र क्रोम (अटोफिल सेवा) | पासवर्डहरूहो, प्रति-डेटासेट प्रमाणीकरण: प्रणालीले भर्नु अघि बायोमेट्रिकप्रम्प्ट देखाउँछ; डिजिटल एसेट लिङ्कहरूले बचत गरिएको डोमेनमा जोड्दा मात्र एप प्याकेज मिल्छ। | कार्डहरूहो, क्रेडिटकार्ड नम्बर, क्रेडिटकार्ड म्याद समाप्ति* र क्रेडिटकार्डसुरक्षा कोड संकेतहरू, एउटै बायोमेट्रिक गेट |
| AssuredAuth ब्राउजर (दुबै प्लेटफर्महरू) | पासवर्डहरूहो, दर्तायोग्य डोमेनद्वारा — एउटा होस्ट जसको आफ्नै कुनै पनि कुरा ठ्याक्कै मिल्दैन — सोधिएको फ्रेममा, भर्नु अघि बायोमेट्रिक | कार्डहरूहो, फिल्ड पत्ता लगाउने, भर्नु अघि बायोमेट्रिक द्वारा |
| प्रतिलिपि बटनहरू | पासवर्डहरूएप लक पछाडि, 30-सेकेन्डको क्लिपबोर्ड | कार्डहरूनम्बर, म्याद समाप्ति, CVC (समान नियमहरू) |
उस्तै देखिने होस्टमा केही पनि भरिँदैन। बायोमेट्रिक बिना केही पनि भरिँदैन।
7. के कहिल्यै हुँदैन
कुनै भल्ट सर्भर छैन। भल्ट फिल्ड बोक्ने कुनै एनालिटिक्स छैन। पुष्टि पाना र ताजा बायोमेट्रिक बिना कुनै प्लेन-टेक्स्ट निर्यात छैन। भल्ट स्क्रिनमा कुनै तेस्रो-पक्ष SDK लोड गरिएको छैन। भल्ट स्क्रिनको स्क्रिनसट छैन। कुनै पासफ्रेज संकेत छैन। कुनै पनि निर्माणमा मानहरूको लगिङ छैन।
8. हामी के विरुद्ध सुरक्षा गर्न सक्दैनौं
अनुमान गर्न सक्ने गरी कमजोर पासफ्रेज। एउटा फोन जसको अपरेटिङ सिस्टम रुटमा समस्याग्रस्त छ (जेलब्रोकन वा रुट गरिएको उपकरणले माथिको सबै कुराको बारेमा एपलाई झूट बोल्न सक्छ)। टाइप गर्दा निगरानी गरिएको व्यक्ति। तपाईंले टाँस्ने डेस्कटपमा मालवेयर। माथिको सूची के हो भनेर पढ्नको लागि हामी यो भन्छौं: डिजाइनले हटाउन सक्ने चीजहरू, हटाइयो।
9. समीक्षा स्थिति
यो डिजाइन दुवै प्लेटफर्महरूमा प्रकाशित ज्ञात उत्तरहरू र यसको आफ्नै क्रस-प्लेटफर्म भेक्टरहरू विरुद्ध एकाइ-परीक्षण गरिएको छ। स्टोर सूचीमा भल्टको विज्ञापन गर्नु अघि बाह्य समीक्षा मालिकको सूचीमा छ; यो नभएसम्म, यो कागजातले यहाँ त्यसो भन्नेछ।
10. जहाँ चीजहरू चल्छन्
फोनमा भल्टको केही पनि बाँकी रहँदैन, तर यसको वरिपरि रहेका केही चीजहरू अरू मानिसहरूको मेसिनमा चल्छन्। यो सूची हो, र प्रत्येकमा के हुन्छ; डेटा प्रवाहहरू आफैं https://assuredauth.com/privacy मा रहेको गोपनीयता नीतिमा वर्णन गरिएको छ।
- गुगल क्लाउड / फायरबेस — डेस्कटप एक्सटेन्सनको लागि रिले मेलबक्स (एन्ड-टु-एन्ड इन्क्रिप्टेड खामहरू, पढ्दा मेटाइन्छ), पुश टोकनहरू, खरिद स्थिति, र सम्पर्क फारम मार्फत पठाइएका सन्देशहरू।
- Vercel — assuredauth.com, यसका पृष्ठहरू र तिनीहरू पछाडि रहेका साना कार्यहरू।
- Vultr — निजी जडानको एक्जिट सर्भरहरू। ट्राफिक तिनीहरूबाट गुज्रन्छ; केही पनि भण्डारण गरिएको छैन।
- एप्पल र गुगल प्ले - खरिद र सदस्यताहरू, आफ्नै स्टोरहरूमा।
- पोस्टहग — उत्पादन विश्लेषण: प्रयोग गरिएको कुराको गणना, कुनै पहिचान बिना बाँधिएको।
- RevenueCat — सदस्यताको अवस्था: सक्रिय वा म्याद सकिएको, र कुन योजनामा।
प्रत्येकले आफ्नो लाइनले भनेको कुरा राख्छ र भल्टबाट केही पनि राख्दैन। उत्पादन परिवर्तन हुँदा सूची परिवर्तन हुन्छ, र यो खण्ड पनि त्यससँगै परिवर्तन हुन्छ।
कमजोरी रिपोर्ट गर्दै
यदि तपाईंलाई लाग्छ कि तपाईंले यहाँ वर्णन गरिएको कुनै पनि कुरामा कमजोरी फेला पार्नुभएको छ भने, "सुरक्षा" विषयको साथ hello@assuredauth.com मा लेख्नुहोस्। कृपया प्लेटफर्म, एप संस्करण र चरणहरू समावेश गर्नुहोस्; तपाईंको आफ्नै डेटा प्रयोग गर्ने प्रमाण पर्याप्त छ, र हामी तपाईंलाई अरू मानिसहरूको विरुद्ध परीक्षण नगर्न अनुरोध गर्दछौं। हामी PGP कुञ्जी प्रदान गर्दैनौं; यदि रिपोर्ट सादा इमेलमा यात्रा गर्नु हुँदैन भने, पहिलो सन्देशमा भन्नुहोस् र हामी अर्को तरिकाले व्यवस्था गर्नेछौं।
बदलामा हामी के वाचा गर्छौं: हामी तीन कार्य दिन भित्र स्वीकार गर्छौं, हामी यसमा काम गर्दा तपाईंलाई जानकारी गराउँछौं, यसको बारेमा केहि प्रकाशित हुनु अघि वास्तविक कुराहरू ठीक गर्छौं, र यदि तपाईं श्रेय पाउन चाहनुहुन्छ भने तपाईंलाई यहाँ श्रेय दिन्छौं। तलको दायरा भित्र असल विश्वासका साथ गरिएको अनुसन्धानमा हामी कानुनी कारबाही गर्ने छैनौं।
दायरामा: iOS र एन्ड्रोइड एपहरू, वाच एपहरू, डेस्कटप एक्सटेन्सन, assuredauth.com र यसको API। दायरा बाहिर: एप स्टोर र गुगल प्ले आफैं, माथि सूचीबद्ध प्रदायकहरू, कसैको सामाजिक इन्जिनियरिङ, र सेवा अस्वीकार।
यस समयमा कुनै इनाम छैन। रिपोर्टको जवाफ पैसाले होइन, समाधान र धन्यवादले दिइन्छ।