Securitate
Cum este construită seiful și ce ar găsi o breșă.
Ultima actualizare 21 septembrie 2026 · AssuredAuth, de CircleRoll LLC
Aceasta este descrierea publică a modului în care AssuredAuth protejează secretele cu doi factori, parolele și cardurile pe care le păstrați în acesta. Este scrisă astfel încât un cititor preocupat de securitate să poată verifica fiecare afirmație în raport cu aplicația și cu vectorii de testare publicați (disponibili oricărui recenzent, la cerere, la adresa hello@assuredauth.com). Spune ceea ce este adevărat și nimic mai mult: nimic aici nu pretinde a fi dincolo de atac și nimic nu este promis în procente.
Pe scurt: seiful există într-un singur loc, telefonul tău. Fiecare valoare din el este criptată cu o cheie pe care hardware-ul de securitate al telefonului o deține și nu o poate exporta. Nu rulăm niciun server de seif, nu deținem nicio copie și nu deținem nicio cheie. Un fișier de rezervă părăsește telefonul numai după ce a fost criptat sub o parolă care nu este stocată nicăieri.
Raportează o problemă: hello@assuredauth.com. Vezi „Raportarea unei slăbiciuni” la sfârșit.
1. Ce este criptat, cu ce
| Date | Pe telefon | Cheie |
|---|---|---|
| Secrete cu doi factori (semințe TOTP/HOTP/Steam) | Pe telefonMagazin susținut de Keystore pentru breloc (iOS) / Android | CheieCheia hardware a platformei; rândul bazei de date conține doar o referință (secretRef), niciodată valoarea inițială (seed) |
| Parole (valoarea parolei, note) | Pe telefonRând sigilat: AES-256-GCM, un nonce aleatoriu de 96 de biți per valoare | CheieO cheie de date aleatorie pe 256 de biți, ea însăși încapsulată de cheia hardware din §2 |
| Carduri (număr, expirare, nume pe card, CVC) | Pe telefonAceeași sigiliu ca și parolele; CVC-ul este opțional și este stocat numai dacă îl introduceți | CheieAceeași cheie de date |
| Metadate (nume de servicii, nume de utilizator, pictograme, ordine de sortare) | Pe telefonBaza de date a aplicației (SwiftData / Room) | CheieProtejat de criptarea fișierelor sistemului de operare; tratat ca nesecret |
| Fișier de rezervă (.authbackup) | Pe telefonOriunde îl pui: Fișiere, iCloud Drive, Google Drive appDataFolder, o foaie de partajare | CheieO cheie derivată din parola dvs. (§3). Apple și Google primesc fișierul sigilat și nimic altceva. |
| Companion pentru Watch / Wear | Pe telefonBrelocul propriu al ceasului / Preferințe partajate criptate | CheieCheile platformei ceasului; transferate prin canalul de dispozitive asociate al platformei |
| Trafic extensie desktop (coduri unice la cerere) | Pe telefonNestocat; retransmis ca plicuri criptate end-to-end | CheieO pereche de chei X25519 per asociere, cheie privată în Keychain / Keystore; releul vede doar text cifrat |
Diagnosticarea nu are nicio metodă care să accepte un secret. Niciun eveniment de analiză nu conține un câmp din seif. Nicio valoare din seif nu este scrisă vreodată într-un jurnal, în nicio compilare.
2. Unde se află cheile, pe fiecare platformă
iOS. Cheia de date este încapsulată într-o cheie generată în cadrul Secure Enclave (kSecAttrTokenIDSecureEnclave) cu controlul accesului .privateKeyUsage + .userPresence, accesibilitate …ThisDeviceOnly, în grupul de acces partajat Keychain al aplicației, astfel încât extensia AutoFill poate utiliza aceeași cheie. Cheia privată nu poate fi citită din Enclave de către aplicație, de o copie de rezervă sau de un depanator; Enclave este de acord să o utilizeze doar după ce utilizatorul este prezent (Face ID, Touch ID sau parola dispozitivului). ThisDeviceOnly înseamnă că o copie de rezervă iCloud sau iTunes a telefonului nu conține cheia; un telefon restaurat începe cu un seif gol și solicită fișierul de rezervă și parola. Un telefon fără cod de acces nu poate accesa o cheie .userPresence (Enclave refuză să creeze una), iar simulatorul urmează aceeași cale prin design (solicitarea sa de prezență este o alertă la care niciun test nu poate răspunde): acolo, cheia de date este un element simplu, doar pentru dispozitiv - încă absent din fiecare copie de rezervă, încă ilizibil cât timp telefonul este blocat, dar fără o a doua solicitare - iar ecranul Securitate spune exact asta și sugerează setarea unui cod de acces.
Android. Cheia de date este încapsulată într-o cheie AndroidKeyStore AES-256, generată în StrongBox atunci când dispozitivul are una (altfel TEE), cu setUserAuthenticationRequired(true) și o valabilitate de autentificare de 30 de secunde după o biometrică sau o acreditare a dispozitivului, setUnlockedDeviceRequired(true) și setInvalidatedByBiometricEnrollment(true) lăsate activate. Acest ultim indicator este onestă, nu portantă: Android o aplică doar cheilor care necesită o biometrică la fiecare utilizare, așa că pentru această cheie de 30 de secunde cu acreditarea dispozitivului permisă, nu schimbă nimic - ceea ce ține degetul unui străin la distanță este faptul că înscrierea cuiva necesită codul PIN și că eliminarea blocării ecranului invalidează definitiv cheia. Cheile Keystore nu sunt exportabile și sunt excluse din backup-ul în cloud al Android. Un domeniu pe care o aplicație îl numește în propriile vizualizări (webDomain) este considerat acceptabil doar dintr-un browser cunoscut; din orice alt pachet trebuie să fie și unul pe care sistemul l-a verificat pentru acel pachet (Digital Asset Links), deoarece orice aplicație poate revendica orice domeniu.
Ce înseamnă asta pentru un fișier de bază de date furat. Fișierul SQLite și rândurile sigilate sunt text cifrat. Cheia care le deschide se află în hardware-ul de securitate al telefonului de pe care provine fișierul și nu poate fi copiată odată cu acesta. Nu există nimic de ghicit offline: cheia de date este aleatorie, nu este derivată din nimic ales de o persoană.
3. Fișierul de rezervă
Copiile de rezervă sunt singurul lucru care părăsește telefonul, așa că, în principiu, sunt singurul loc unde este posibil un atac offline. Designul face ca acest atac să fie costisitor și îi oferă cât mai puține resurse posibile:
- Parola are cel puțin 12 caractere (foaia refuză mai puține și afișează o bară de putere).
- Niciun indiciu pentru parolă nu este stocat nicăieri, în fișier sau în aplicație.
- O valoare salt aleatorie proaspătă de 16 octeți și o valoare nonce de 12 octeți pentru fiecare fișier scris.
- Întregul corp este AES-256-GCM, deci o parolă greșită sau un fișier deteriorat este refuzat și nu este niciodată decriptat.
- Antetul (format, versiune, parametri KDF, salt) este legat în eticheta GCM ca date autentificate suplimentare, astfel încât un fișier al cărui factor de lucru a fost editat redus nu se deschide.
Fișierul este JSON și poate fi citit în orice editor de text; doar textul cifrat este opac. Cineva care găsește fișierul peste cinci ani, după ce aplicația a dispărut, poate vedea exact cum a fost sigilat și îl poate deschide cu OpenSSL sau cu orice bibliotecă Argon2.
Format v1 (disponibil în versiunea 1.0, rămâne lizibil)
{
"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>"
}| Pas | Octeți |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (octeți de sare brută, nu base64) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); etichetă 16 octeți, stocată separat |
plaintext | JSON UTF-8, chei sortate: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Notă de compatibilitate: Android 1.0 a scris o variantă a versiunii 1 — kdf cu litere mici, fără cheie de etichetă (eticheta de 16 octeți adăugată la textul cifrat), fără date suplimentare. Ambele platforme continuă să citească acele fișiere (când eticheta lipsește: împarte ultimii 16 octeți, deschide cu AAD gol; comparați kdf fără a ține cont de majuscule/minuscule) și ambele scriu acum doar aspectul de mai sus.
Format v2 (curent; implicit pentru copiile de rezervă noi)
{
"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>"
}| Pas | Octeți |
|---|---|
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); etichetă 16 octeți, stocată separat |
plaintext | JSON UTF-8, chei sortate: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id este implementarea C de referință (phc-winner-argon2, CC0), disponibilă pe ambele platforme. 64 MiB și 3 treceri durează aproximativ o secundă pe un telefon actual și face ca fiecare încercare să coste acea memorie și timp pe orice hardware - proprietatea de care PBKDF2 nu dispune împotriva platformelor GPU și motivul pentru care există v2. Un cititor ignoră cheile pe care nu le cunoaște, așa că un cititor v1 căruia i se atribuie un corp v2 pur și simplu nu vede niciodată cardurile.
Dovadă
Trei fișiere vector-test (backup v1, backup v2 și Argon2id) sunt generate de o a treia implementare, independentă de ambele aplicații (OpenSSL-ul Node pentru PBKDF2 și AES-GCM, un Argon2id WebAssembly verificat la momentul generării în raport cu răspunsurile publicate ale implementării de referință). Fiecare conține fraza de acces, saltul, nonce-ul, textul clar, cheia derivată, AAD, textul cifrat și eticheta așteptate și fișierul complet. Testele unitare pe iOS și pe Android citesc aceleași fișiere și afirmă aceiași octeți - deci o copie de rezervă sigilată pe o platformă este dovedită, nu presupusă, că se deschide pe cealaltă, iar o concordanță a tuturor celor trei nu reprezintă două copii ale aceleiași greșeli. Un instrument însoțitor deschide un fișier scris de un telefon cu aceeași a treia implementare și verifică antetul în funcție de regulile de mai sus (exact cheile formatului, deci nu poate fi prezent niciun indiciu sau nume; salt de 16 octeți, nonce de 12 octeți, etichetă de 16 octeți stocată separat; versiunea 2 la exact 64 MiB / 3 / 1; parolă greșită refuzată); rularea automată iOS scrie unul pe simulator și îl deschide în acest fel și caută în containerul de aplicații al simulatorului, containerul App Group și baza de date keychain pentru fiecare parolă și număr de card introduse ca UTF-8 și UTF-16 (0 rezultate).
4. Modelul amenințării
| Situaţie | Ceea ce au | Ceea ce primesc |
|---|---|---|
| Telefon pierdut sau furat, blocat | Ceea ce auDispozitivul, fișierul bazei de date, rândurile sigilate | Ceea ce primescText cifrat. Cheia cifrată se află în Secure Enclave / StrongBox și se eliberează numai după blocarea dispozitivului plus introducerea unui cod biometric sau a unei parole noi. Ștergerea telefonului de la distanță (Find My / Find My Device) distruge odată cu aceasta materialul cheii. |
| Fișier de rezervă furat | Ceea ce auFișierul .authbackup dintr-un cont cloud, un e-mail, un laptop | Ceea ce primescUn corp AES-256-GCM sub o cheie derivată dintr-o parolă de cel puțin 12 caractere, cu o parolă saltă per fișier și Argon2id la 64 MiB × 3 pase (v2) sau PBKDF2 la 600.000 de runde (v1). Niciun indiciu, niciun nume de utilizator, nicio listă de conturi în clar. Fiecare presupunere costă derivarea completă; nu există nicio scurtătură. O parolă puternică este întreaga apărare aici, iar aplicația o menționează în foaie. |
| Dispozitiv furat cu ecranul deblocat | Ceea ce auUn telefon în mână, deblocat | Ceea ce primescLista de coduri. Seiful (parole, carduri) se află în spatele blocării aplicației și se reblochează la cronometrul de blocare automată (imediat / 1 min / 5 min); o valoare decriptată există în memorie doar cât timp este afișată pe ecran. Completarea automată și exportul în text simplu solicită date biometrice noi chiar și atunci când aplicația este deschisă. Activați blocarea aplicației cu „Imediat” dacă vă faceți griji în privința acesteia. |
| Aplicație rău intenționată pe același telefon | Ceea ce auCutia cu nisip a altei aplicații, clipboard-ul, accesibilitatea sau trucurile de suprapunere | Ceea ce primescNu poate citi fișierele noastre (platform sandboxing) și nici nu poate folosi cheia noastră (cheia este legată de identitatea noastră de semnătură și de prezența utilizatorului). Copiile sunt șterse din clipboard după 30 de secunde; pe Android, copia este marcată ca sensibilă și exclusă din istoricul clipboardului. Ecranele din seif sunt setate la FLAG_SECURE pe Android (fără capturi de ecran, fără înregistrare a ecranului, spațiu gol în comutator); iOS golește miniatura comutatorului. Completarea automată pe Android este servită numai aplicațiilor pe care sistemul le-a verificat în raport cu domeniul salvat (Digital Asset Links), așadar unei aplicații similare nu i se oferă parola. |
| Pagină de phishing | Ceea ce auUn site care arată ca cel pe care l-ai salvat | Ceea ce primescNimic nu se umple. Potrivirea se face după domeniul înregistrabil (listă publică de sufixe, inclusă și actualizată odată cu aplicația): login.example.com și example.com se potrivesc, example.com.evil.net și examp1e.com nu. Browserul din aplicație se potrivește în același mod și completează doar cadrul care a solicitat, verificat din nou în raport cu originea cadrului respectiv în momentul completării; o gazdă fără un domeniu înregistrabil propriu - o adresă IP, un nume simplu în rețeaua locală - se potrivește exact și nimic mai puțin convenabil. AutoFill-ul iOS adaugă verificarea domeniilor asociate de la Apple. O parolă pe care trebuie să o inserați manual într-un element similar este încă un risc; aplicația nu poate elimina acest lucru, ci doar evita să ajute. |
| Serverele noastre proprii | Ceea ce au— | Ceea ce primescNu există un server pentru seif. AssuredAuth nu are conturi, nu permite autentificarea și nu are copie a seifului dvs., deci nu există nimic al dvs. de partea noastră care să poată fi furat sau spart. Două lucruri rulează pe partea serverului, niciunul dintre ele nefiind implicat în seif: o cutie poștală de retransmisie pentru extensia desktop, care stochează plicuri criptate end-to-end (coduri de unică folosință, șterse la citire; retransmisia nu are niciodată o cheie) și serverele de ieșire ale conexiunii private opționale, care transportă trafic și nu păstrează jurnale de acces. |
| O citație sau o cerere guvernamentală | Ceea ce auProcesul legal adresat nouă | Ceea ce primescNimic de predat: nu deținem niciun seif, nicio cheie, nicio parolă și nicio copie de rezervă. Putem fi obligați să spunem asta; nu putem fi obligați să prezentăm ceea ce nu există. |
5. Clipboard, capturi de ecran și memorie
- Funcția „Copiere” pune valoarea în clipboard timp de 30 de secunde, apoi o șterge dacă este încă a noastră. Pe Android, clipul este marcat EXTRA_IS_SENSITIVE, astfel încât sistemul îl ascunde din previzualizarea și istoricul clipboardului; pe iOS, elementul de pasteboard este disponibil doar local (nu este transferat către alte dispozitive).
- Ecranele din seif (Parole, Parolă, Carduri, Card, foile cu fraze de acces, exportul de text simplu) setează FLAG_SECURE pe Android. iOS nu are un flag echivalent; aplicația își golește miniatura în comutatorul de aplicații, iar valorile sunt în mod implicit în spatele unui comutator cu ochi.
- Valorile decriptate rămân în memorie doar cât timp sunt afișate pe ecran și sunt șterse când aceasta dispare sau aplicația se blochează. Cheia de date este despachetată pentru o solicitare și nu este stocată în cache prin lacăt.
- Există export în text simplu (deci poți pleca oricând) și se află în spatele unei foi de confirmare și a unor date biometrice noi, iar ecranul său este, de asemenea, FLAG_SECURE.
6. Completare automată: ce se completează și ce nu
| Unde | Parole | Carduri |
|---|---|---|
| iOS: Safari și aplicații (extensia AutoFill) | ParoleDa, după un nou Face ID / Touch ID / cod de acces în extensie (LAContext) și numai pentru domeniul înregistrat pentru care a fost salvată intrarea, cu verificarea aplicațiilor pentru domeniile asociate de la Apple. | CarduriNu. Completarea automată a cardului în Safari este exclusiv la Apple; ecranul cardului spune „Completează în browserul AssuredAuth și cu copie” și nu promite nimic altceva. |
| Android: aplicații și Chrome (Autofill Service) | ParoleDa, autentificare per set de date: sistemul afișează BiometricPrompt înainte de completare; pachetul aplicației se potrivește numai atunci când Digital Asset Links îl leagă de domeniul salvat. | CarduriDa, indiciile creditCardNumber, creditCardExpiration* și creditCardSecurityCode, aceeași poartă biometrică |
| Browserul AssuredAuth (ambele platforme) | ParoleDa, prin domeniu înregistrabil — o gazdă fără nicio potrivire exactă — în cadrul care a solicitat, biometric înainte de completare | CarduriDa, prin detectare pe teren, biometric înainte de umplere |
| Butoane de copiere | ParoleÎn spatele blocării aplicației, clipboard de 30 de secunde | CarduriNumăr, expirare, CVC (aceleași reguli) |
Nimic nu se umple pe o gazdă care seamănă cu ceilalți. Nimic nu se umple fără biometrie.
7. Ceea ce nu se întâmplă niciodată
Fără server de seif. Fără analize care conțin un câmp de seif. Fără export de text simplu fără o foaie de confirmare și date biometrice noi. Fără SDK-uri terțe încărcate pe ecranul seifului. Fără captură de ecran a ecranului seifului. Fără indicii pentru parolă. Fără înregistrare a valorilor, în nicio versiune.
8. Împotriva a ceea ce nu ne putem proteja
O parolă suficient de slabă pentru a fi ghicită. Un telefon al cărui sistem de operare este compromis la nivel de rădăcină (un dispozitiv jailbreakat sau rootat poate minți aplicația despre tot ce este menționat mai sus). O persoană care este supravegheată în timp ce tastează. Programe malware pe desktopul în care lipiți. Spunem asta pentru ca lista de mai sus să fie citită pentru ceea ce este: lucrurile pe care un design le poate elimina, eliminate.
9. Starea revizuirii
Acest design a fost testat unitar în raport cu răspunsurile cunoscute publicate pe ambele platforme și cu propriii vectori multiplatformă. O recenzie externă se află pe lista proprietarului înainte ca seiful să fie anunțat în lista din magazin; până când acest lucru se va întâmpla, acest document va menționa acest lucru aici.
10. Unde rulează fiecare lucru
Nimic din seif nu părăsește telefonul, dar câteva lucruri din jurul său rulează pe mașinile altor persoane. Aceasta este lista și ce conține fiecare; fluxurile de date în sine sunt descrise în politica de confidențialitate de la https://assuredauth.com/privacy.
- Google Cloud / Firebase — căsuța poștală de retransmitere pentru extensia desktop (plicuri criptate end-to-end, șterse la citire), token-uri push, starea achiziției și mesajele trimise prin formularul de contact.
- Vercel — assuredauth.com, paginile sale și micile funcții din spatele lor.
- Vultr — serverele de ieșire ale conexiunii private. Traficul trece prin ele; nimic nu este stocat.
- Apple și Google Play — achiziții și abonamente, în propriile magazine.
- PostHog — analiză de produs: numără ce este utilizat, fără nicio identitate.
- RevenueCat — starea unui abonament: activ sau expirat și planul în care este utilizat.
Fiecare conține informațiile de pe linia sa și nimic din seif. Lista se schimbă odată cu schimbarea produsului, iar această secțiune se schimbă odată cu acesta.
Raportarea unei slăbiciuni
Dacă credeți că ați găsit o slăbiciune în oricare dintre cele descrise aici, scrieți la hello@assuredauth.com cu subiectul „Securitate”. Includeți platforma, versiunea aplicației și pașii; o dovadă care folosește propriile date este suficientă și vă rugăm să nu testați pe datele altor persoane. Nu oferim o cheie PGP; dacă un raport nu ar trebui să circule prin e-mail necriptat, spuneți acest lucru într-un prim mesaj și vom găsi o altă cale.
Ceea ce promitem în schimb: vom confirma dezvăluirea în termen de trei zile lucrătoare, vă vom ține la curent în timp ce lucrăm la acest document, vom corecta informațiile reale înainte de publicarea oricărui aspect și vă vom menționa creditul aici dacă doriți să fiți creditați. Nu vom lua măsuri legale împotriva cercetărilor efectuate cu bună-credință, în limitele de mai jos.
În domeniul de aplicare: aplicațiile iOS și Android, aplicațiile pentru ceas, extensia pentru desktop, assuredauth.com și API-ul său. În afara domeniului de aplicare: App Store și Google Play în sine, furnizorii enumerați mai sus, ingineria socială a oricui și denial of service.
Nu există recompensă în acest moment. La un raport se răspunde cu o soluție și un mulțumesc, nu cu bani.