Segurança
Como o cofre é construído e o que seria encontrado em caso de violação.
Última atualização: 21 de setembro de 2026 · AssuredAuth, da CircleRoll LLC
Esta é a descrição pública de como o AssuredAuth protege os segredos de autenticação de dois fatores, senhas e cartões que você armazena nele. O texto foi escrito de forma que um leitor com conhecimento em segurança possa verificar cada afirmação em relação ao aplicativo e aos vetores de teste publicados (disponíveis para qualquer revisor mediante solicitação pelo e-mail hello@assuredauth.com). Ele descreve apenas a verdade: nada aqui afirma ser invulnerável a ataques, e nada é prometido em porcentagens.
Resumindo: o cofre existe em um único lugar, seu telefone. Todos os dados nele contidos são criptografados com uma chave que o hardware de segurança do telefone guarda e não pode exportar. Não temos servidor de cofre, não armazenamos cópias e não guardamos nenhuma chave. Um arquivo de backup só sai do telefone depois de ser criptografado com uma senha que nunca é armazenada em lugar nenhum.
Reportar um problema: hello@assuredauth.com. Veja "Como reportar uma vulnerabilidade" no final.
1. O que está criptografado e com o quê?
| Dados | No telefone | Chave |
|---|---|---|
| Segredos de dois fatores (sementes TOTP/HOTP/Steam) | No telefoneKeychain (iOS) / Loja com suporte do Keystore para Android | ChaveA chave vinculada ao hardware da plataforma; a linha do banco de dados contém apenas uma referência (secretRef), nunca a semente. |
| Senhas (o valor da senha, observações) | No telefoneLinha selada: AES-256-GCM, um nonce aleatório de 96 bits por valor. | ChaveUma chave de dados aleatória de 256 bits, ela própria encapsulada pela chave de hardware em §2. |
| Cartões (número, validade, nome no cartão, CVC) | No telefoneO mesmo selo das senhas; o CVC é opcional e só é armazenado se você o inserir. | ChaveMesma chave de dados |
| Metadados (nomes de serviços, nomes de usuário, ícones, ordem de classificação) | No telefoneO banco de dados do aplicativo (SwiftData / Room) | ChaveProtegido pela criptografia de arquivos do sistema operacional; tratado como não secreto. |
| Arquivo de backup (.authbackup) | No telefoneOnde quer que você o coloque: Arquivos, iCloud Drive, pasta appData do Google Drive, uma folha de compartilhamento | ChaveUma chave derivada da sua senha (§3). A Apple e o Google recebem o arquivo lacrado e nada mais. |
| Complemento para Watch / Wear | No telefoneO próprio Keychain do relógio / Preferências Compartilhadas Criptografadas | ChaveAs chaves da plataforma do relógio; transferidas pelo canal de dispositivo emparelhado da plataforma. |
| Tráfego de extensão para desktop (códigos únicos sob solicitação) | No telefoneNão armazenado; retransmitido como envelopes criptografados de ponta a ponta. | ChaveUm par de chaves X25519 por emparelhamento, chave privada no Keychain/Keystore; o relay vê apenas o texto cifrado. |
O módulo de diagnóstico não possui nenhum método que aceite um segredo. Nenhum evento analítico contém um campo do cofre. Nenhum valor do cofre é gravado em um log, em nenhuma versão do sistema.
2. Onde as chaves estão localizadas, em cada plataforma.
iOS. A chave de dados é encapsulada por uma chave gerada dentro do Secure Enclave (kSecAttrTokenIDSecureEnclave) com controle de acesso .privateKeyUsage + .userPresence, acessibilidade …ThisDeviceOnly, no grupo de acesso às Chaves compartilhado do aplicativo, para que a extensão AutoFill possa usar a mesma chave. A chave privada não pode ser lida do Enclave pelo aplicativo, por um backup ou por um depurador; o Enclave só concorda em usá-la após a presença do usuário (Face ID, Touch ID ou senha do dispositivo). ThisDeviceOnly significa que um backup do iCloud ou iTunes do telefone não contém a chave; um telefone restaurado inicia com um cofre vazio e solicita seu arquivo de backup e senha. Um telefone sem senha não consegue acessar uma chave .userPresence (o Enclave se recusa a criar uma), e o simulador segue o mesmo caminho por design (seu aviso de presença é um alerta que nenhum teste consegue responder): nele, a chave de dados é um item simples do Keychain, exclusivo do dispositivo — ainda ausente de todos os backups, ainda ilegível enquanto o telefone estiver bloqueado, mas sem um segundo aviso — e a tela de Segurança diz exatamente isso e sugere definir uma senha.
Android. A chave de dados é encapsulada por uma chave AES-256 do AndroidKeyStore, gerada no StrongBox quando o dispositivo possui um (caso contrário, o TEE), com setUserAuthenticationRequired(true) e validade de autenticação de 30 segundos após a autenticação biométrica ou por credencial do dispositivo, setUnlockedDeviceRequired(true) e setInvalidatedByBiometricEnrollment(true) ativados. Essa última flag é honesta, não determinante: o Android a aplica apenas a chaves que exigem biometria a cada uso, portanto, nesta chave de 30 segundos com a credencial do dispositivo permitida, ela não altera nada — o que impede o acesso não autorizado é que o cadastro exige o PIN e que a remoção do bloqueio de tela invalida a chave permanentemente. As chaves do Keystore não são exportáveis e são excluídas do backup em nuvem do Android. Um domínio que um aplicativo nomeia em suas próprias visualizações (webDomain) é considerado válido apenas para navegadores conhecidos; De qualquer outro pacote, também deve ser um que o sistema tenha verificado para esse pacote (Links de Ativos Digitais), já que qualquer aplicativo pode reivindicar qualquer domínio.
O que isso significa para um arquivo de banco de dados roubado. O arquivo SQLite e as linhas seladas são texto cifrado. A chave que os abre reside no hardware de segurança do telefone de onde o arquivo foi obtido e não pode ser copiada junto com ele. Não há nada para adivinhar offline: a chave de dados é aleatória, não derivada de nenhuma escolha humana.
3. O arquivo de backup
Os backups são o único dado que sai do telefone, sendo, portanto, o único ponto vulnerável a um ataque offline em princípio. O design do dispositivo torna esse ataque dispendioso e oferece ao atacante o mínimo de recursos possível:
- A frase secreta tem pelo menos 12 caracteres (a tela não aceita menos e mostra uma barra de força).
- Nenhuma dica de senha é armazenada em qualquer lugar, seja no arquivo ou no aplicativo.
- Um novo salt aleatório de 16 bytes e um nonce de 12 bytes para cada arquivo gravado.
- Todo o corpo da criptografia utiliza AES-256-GCM, portanto, uma senha incorreta ou um arquivo corrompido são rejeitados, nunca sendo descriptografados e resultando em dados ilegíveis.
- O cabeçalho (formato, versão, parâmetros KDF, salt) é vinculado à tag GCM como dados autenticados adicionais, portanto, um arquivo cujo fator de trabalho foi reduzido não será aberto.
O arquivo é JSON e pode ser lido em qualquer editor de texto; apenas o texto cifrado é opaco. Alguém que encontrar o arquivo daqui a cinco anos, quando o aplicativo já tiver sido descontinuado, poderá ver exatamente como ele foi criptografado e abri-lo com o OpenSSL ou qualquer biblioteca Argon2.
Formato v1 (incluído na versão 1.0, permanece legível)
{
"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>"
}| Etapa | Bytes |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (bytes de sal brutos, não base64) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); etiqueta de 16 bytes, armazenada separadamente |
plaintext | JSON UTF-8, chaves ordenadas: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Nota de compatibilidade: o Android 1.0 gravou uma variante da v1 — kdf em minúsculas, sem chave de tag (a tag de 16 bytes anexada ao texto cifrado) e sem dados adicionais. Ambas as plataformas continuam lendo esses arquivos (quando a tag está ausente: dividem os últimos 16 bytes, abrem com AAD vazio; comparam o kdf sem distinção entre maiúsculas e minúsculas) e agora ambas gravam apenas o layout acima.
Formato v2 (atual; padrão para novos backups)
{
"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>"
}| Etapa | 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); etiqueta de 16 bytes, armazenada separadamente |
plaintext | JSON UTF-8, chaves ordenadas: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id é a implementação de referência em C (phc-winner-argon2, CC0), incluída em ambas as plataformas. 64 MiB e 3 passagens levam cerca de um segundo em um telefone atual, fazendo com que cada tentativa consuma essa memória e tempo em qualquer hardware — a característica que o PBKDF2 não possui contra sistemas com GPU, e a razão pela qual a versão 2 existe. Um leitor ignora chaves que não conhece, então um leitor da versão 1, ao receber um corpo da versão 2, simplesmente nunca vê os cartões.
Prova
Três arquivos de vetor de teste (backup v1, backup v2 e Argon2id) são gerados por uma terceira implementação, independente de ambos os aplicativos (OpenSSL do Node para PBKDF2 e AES-GCM, um Argon2id em WebAssembly verificado no momento da geração em relação às respostas publicadas da implementação de referência). Cada um contém a senha, o salt, o nonce, o texto plano, a chave derivada, o AAD, o texto cifrado esperado e a tag, além do arquivo completo. Os testes unitários no iOS e no Android leem os mesmos arquivos e verificam os mesmos bytes — portanto, um backup selado em uma plataforma é comprovadamente aberto na outra, e não presumido, e a concordância entre os três não representa duas cópias do mesmo erro. Uma ferramenta complementar abre um arquivo que um telefone realmente gravou com essa mesma terceira implementação e verifica o cabeçalho em relação às regras acima (exatamente as chaves do formato, portanto, nenhuma dica ou nome pode estar presente; salt de 16 bytes, nonce de 12 bytes, tag de 16 bytes armazenados separadamente; versão 2 em exatamente 64 MiB / 3 / 1; senha incorreta recusada); a execução automatizada do iOS grava um arquivo no simulador e o abre dessa forma, e pesquisa no contêiner do aplicativo do simulador, no contêiner do Grupo de Aplicativos e no banco de dados do chaveiro por todas as senhas e números de cartão predefinidos como UTF-8 e UTF-16 (0 resultados).
4. Modelo de ameaça
| Situação | O que eles têm | O que eles recebem |
|---|---|---|
| Celular perdido ou roubado, bloqueado | O que eles têmO dispositivo, o arquivo de banco de dados, as linhas seladas | O que eles recebemTexto cifrado. A chave de encapsulamento está no Secure Enclave / StrongBox e só é liberada após o bloqueio do dispositivo e a inserção de uma nova biometria ou senha. Apagar o telefone remotamente (Encontrar Meu Dispositivo) destrói o material da chave. |
| Arquivo de backup roubado | O que eles têmO arquivo .authbackup de uma conta na nuvem, um e-mail ou um laptop | O que eles recebemUm corpo AES-256-GCM sob uma chave derivada de uma senha de pelo menos 12 caracteres, com um salt por arquivo e Argon2id em 64 MiB × 3 passagens (v2) ou PBKDF2 em 600.000 iterações (v1). Sem dicas, sem nome de usuário, sem lista de contas em texto simples. Cada tentativa custa a derivação completa; não há atalhos. Uma senha forte é toda a defesa aqui, e o aplicativo indica isso na planilha. |
| Aparelho roubado com a tela desbloqueada | O que eles têmUm telefone na sua mão, desbloqueado. | O que eles recebemLista de códigos. O cofre (senhas, cartões) está protegido pelo bloqueio do aplicativo e é bloqueado automaticamente após um determinado período (imediatamente / 1 min / 5 min); um valor descriptografado existe na memória apenas enquanto estiver sendo exibido na tela. O preenchimento automático e a exportação de texto simples solicitam uma nova biometria mesmo quando o aplicativo está aberto. Ative o bloqueio do aplicativo com a opção "Imediatamente" se isso for uma preocupação para você. |
| Aplicativo malicioso no mesmo telefone | O que eles têmO ambiente de testes (sandbox) de outro aplicativo, a área de transferência, recursos de acessibilidade ou truques de sobreposição. | O que eles recebemNão é possível ler nossos arquivos (sandbox da plataforma) nem usar nossa chave (a chave está vinculada à nossa identidade de assinatura e à presença do usuário). As cópias são apagadas da área de transferência após 30 segundos; no Android, a cópia é sinalizada como confidencial e excluída do histórico da área de transferência. As telas do Vault são definidas como FLAG_SECURE no Android (sem capturas de tela, sem gravação de tela, tela em branco no seletor); no iOS, a miniatura do seletor fica em branco. O preenchimento automático no Android é oferecido apenas para aplicativos que o sistema verificou em relação ao domínio salvo (Links de Ativos Digitais), portanto, um aplicativo semelhante não recebe sua senha. |
| Página de phishing | O que eles têmUm site que se parece com aquele que você salvou. | O que eles recebemNada é preenchido. A correspondência é feita por domínio registrável (lista pública de sufixos, incluída e atualizada com o aplicativo): login.example.com e example.com correspondem, example.com.evil.net e example.com não. O navegador integrado ao aplicativo faz a correspondência da mesma forma e preenche apenas no frame solicitado, verificando novamente a origem desse frame no momento do preenchimento; um host sem domínio registrável próprio — um endereço IP, um nome simples na rede local — corresponde exatamente e nada mais. O Preenchimento Automático do iOS adiciona a verificação de domínios associados da Apple. Uma senha que você precisa colar manualmente em um campo semelhante ainda representa um risco; o aplicativo não pode eliminar esse risco, apenas evitar ajudar. |
| Nossos próprios servidores | O que eles têm— | O que eles recebemNão existe um servidor de cofre. O AssuredAuth não possui contas, não exige login e não tem cópia do seu cofre; portanto, não há nada seu em nosso servidor que possa ser roubado ou invadido. Duas coisas são executadas no servidor, mas nenhuma delas afeta o cofre: uma caixa de correio de retransmissão para a extensão de desktop, que armazena envelopes criptografados de ponta a ponta (códigos de uso único, excluídos após a leitura; a caixa de retransmissão nunca possui uma chave), e os servidores de saída da conexão privada opcional, que transportam o tráfego e não mantêm registros de acesso. |
| Uma intimação ou uma solicitação do governo | O que eles têmProcesso legal dirigido a nós | O que eles recebemNada a entregar: não possuímos cofre, chave, senha ou backup. Podemos ser obrigados a dizer isso; não podemos ser obrigados a apresentar o que não existe. |
5. Área de transferência, capturas de tela e memória
- A ação de copiar coloca o valor na área de transferência por 30 segundos e, em seguida, a apaga se ainda estiver em nosso domínio. No Android, o item copiado é marcado como EXTRA_IS_SENSITIVE, de modo que o sistema o oculta da pré-visualização e do histórico da área de transferência; no iOS, o item da área de transferência é apenas local (não é compartilhado com outros dispositivos via Handoff).
- As telas do cofre (Senhas, Senha, Cartões, Cartão, as folhas de senhas, exportação de texto simples) definem FLAG_SECURE no Android. O iOS não possui uma opção equivalente; o aplicativo oculta sua miniatura no seletor de aplicativos e os valores ficam ocultos por um ícone de ícone de olho por padrão.
- Os valores descriptografados permanecem na memória apenas enquanto a tela os exibe e são descartados quando a tela é fechada ou o aplicativo é bloqueado. A chave de dados é descriptografada para uma solicitação e não é armazenada em cache durante o bloqueio.
- Existe a opção de exportação em texto simples (portanto, você sempre pode sair), que está protegida por uma folha de confirmação e uma nova coleta de dados biométricos, e sua tela também possui o selo FLAG_SECURE.
6. Preenchimento automático: o que preenche e o que não preenche
| Onde | Senhas | Cartões |
|---|---|---|
| iOS: Safari e aplicativos (extensão AutoFill) | SenhasSim, após um novo Face ID/Touch ID/senha na extensão (LAContext), e somente para o domínio registrável para o qual a entrada foi salva, com a verificação de domínios associados da Apple para aplicativos. | CartõesNão. O preenchimento automático de cartões no Safari é exclusivo da Apple; a tela do cartão diz "Preenche no navegador AssuredAuth e com a opção Copiar" e não promete nada além disso. |
| Android: aplicativos e Chrome (Serviço de preenchimento automático) | SenhasSim, autenticação por conjunto de dados: o sistema exibe o BiometricPrompt antes do preenchimento; o pacote do aplicativo corresponde somente quando o Digital Asset Links o vincula ao domínio salvo. | CartõesSim, as dicas creditCardNumber, creditCardExpiration* e creditCardSecurityCode, mesmo portão biométrico |
| O navegador AssuredAuth (ambas as plataformas) | SenhasSim, por domínio registrável — um host sem nenhuma correspondência exata própria — no quadro que solicitou, biométrico antes do preenchimento. | CartõesSim, por detecção de campo, biometria antes do preenchimento. |
| Botões de copiar | SenhasAtrás do bloqueio do aplicativo, área de transferência de 30 segundos | CartõesNúmero, data de validade, CVC (mesmas regras) |
Nada funciona com um hospedeiro idêntico. Nada funciona sem a biometria.
7. O que nunca acontece
Sem servidor de cofre. Sem análises que incluam um campo de cofre. Sem exportação de texto simples sem uma folha de confirmação e uma nova biometria. Sem SDK de terceiros carregado na tela do cofre. Sem captura de tela da tela do cofre. Sem dica de senha. Sem registro de valores, em nenhuma versão.
8. Aquilo contra o que não podemos nos proteger
Uma senha fraca o suficiente para ser adivinhada. Um telefone cujo sistema operacional está comprometido na raiz (um dispositivo com jailbreak ou root pode enganar o aplicativo sobre tudo o que foi mencionado acima). Uma pessoa sendo observada enquanto digita. Malware na área de trabalho onde você cola o texto. Dizemos isso para que a lista acima seja lida pelo que ela é: as coisas que um design pode remover, de fato, foram removidas.
9. Status da avaliação
Este projeto foi testado em comparação com respostas conhecidas publicadas em ambas as plataformas e com seus próprios vetores multiplataforma. Uma revisão externa está na lista do proprietário antes que o cofre seja anunciado na loja; até que isso aconteça, este documento informará sobre isso aqui.
10. Onde cada coisa é executada
Nenhum dado do cofre sai do telefone, mas alguns processos relacionados a ele são executados em computadores de terceiros. Esta é a lista e o conteúdo de cada um; os fluxos de dados em si são descritos na política de privacidade em https://assuredauth.com/privacy.
- Google Cloud / Firebase — a caixa de correio de retransmissão para a extensão de desktop (envelopes criptografados de ponta a ponta, excluídos após a leitura), tokens push, estado da compra e mensagens enviadas pelo formulário de contato.
- Vercel — assuranceauth.com, suas páginas e as pequenas funções por trás delas.
- Vultr — os servidores de saída da conexão privada. O tráfego passa por eles; nada é armazenado.
- Apple e Google Play — compras e assinaturas, em suas próprias lojas.
- PostHog — análise de produtos: contagem do que é usado, sem vinculação a nenhuma identidade.
- RevenueCat — o estado de uma assinatura: ativa ou expirada, e em qual plano.
Cada item contém apenas o que está descrito em sua linha, e nada do cofre. A lista muda conforme o produto é atualizado, e esta seção acompanha essa mudança.
Reportar uma fraqueza
Se você acredita ter encontrado alguma vulnerabilidade em qualquer item descrito aqui, escreva para hello@assuredauth.com com o assunto "Segurança". Inclua a plataforma, a versão do aplicativo e os passos utilizados; uma prova utilizando seus próprios dados é suficiente, e pedimos que não teste com dados de terceiros. Não fornecemos chave PGP; caso o relatório não deva ser enviado por e-mail em formato físico, informe-nos na primeira mensagem e encontraremos outra forma de envio.
O que prometemos em troca: confirmaremos o recebimento em até três dias úteis, manteremos você informado enquanto trabalhamos na pesquisa, corrigiremos qualquer informação incorreta antes de publicarmos qualquer conteúdo a respeito e daremos o devido crédito aqui, caso você deseje. Não tomaremos medidas legais contra pesquisas realizadas de boa-fé dentro do escopo descrito abaixo.
Abrangência: os aplicativos para iOS e Android, os aplicativos para Apple Watch, a extensão para desktop, o site assuranceauth.com e sua API. Ausência de abrangência: a App Store e o Google Play em si, os provedores listados acima, engenharia social de qualquer pessoa e ataques de negação de serviço.
Não há recompensa no momento. Uma denúncia é respondida com uma solução e um agradecimento, não com dinheiro.