Invadir o servidor de um mensageiro não significa necessariamente ler todas as mensagens. O resultado depende dos dados armazenados, da localização das chaves e do nível de acesso do invasor. Mesmo quando o texto das conversas tem criptografia de ponta a ponta correta, informações de conta, horários, participação em grupos e rotas de entrega podem ser sensíveis.
Para avaliar um incidente, primeiro pergunte o que ficou nas mãos do invasor: uma cópia do banco de dados, chaves da infraestrutura, um servidor ativo ou o sistema de publicação de software? Esses cenários não têm as mesmas consequências.
Um banco de dados roubado não é o mesmo que um servidor controlado
Um invasor que possui apenas uma cópia antiga do banco fica limitado aos dados ali registrados. O controle do serviço em funcionamento pode permitir registrar novos dados, roubar sessões, alterar respostas ou tentar substituir a chave de um contato. O acesso à cadeia de publicação de software é outro risco: código malicioso no dispositivo final pode ver o texto antes da criptografia ou depois da descriptografia.
Portanto, afirmar que «o banco de dados não contém a chave do texto das mensagens» é importante, mas não responde completamente a todos os tipos de invasão.
Comparação de cinco padrões de arquitetura
Estes são padrões educativos, não um ranking de cinco produtos. Um serviço pode usar vários padrões em funcionalidades diferentes.
| Padrão | Dados acessíveis a partir do banco | Limite importante |
|---|---|---|
| Mensagens e senhas em texto claro | Conteúdo e credenciais podem ser lidos diretamente | Falta de proteção adequada para ambos os tipos de dados |
| Senhas com hash, mensagens em claro | O conteúdo é legível; pode ser possível testar tentativas de senha | A qualidade do armazenamento de senhas não protege o texto das conversas |
| Conteúdo criptografado com chave do servidor | Texto cifrado; a leitura depende do acesso à chave | A separação real entre chave e dados é importante |
| Conversa E2EE com backup acessível ao provedor | A conversa atual pode estar protegida, mas a cópia do histórico tem outra via de exposição | É preciso examinar a política e a chave do backup |
| Conversa E2EE com recuperação criptografada e chave independente | Texto cifrado e dados operacionais; a proteção do conteúdo depende do projeto e da proteção da chave | Dispositivo, frase de recuperação e autenticação do contato continuam importantes |
A criptografia do disco do servidor ajuda contra o roubo de um disco bruto. Quando o invasor também controla o serviço ativo ou a chave de descriptografia, não se deve presumir a mesma proteção. Na E2EE, o objetivo é que o serviço intermediário não possua a chave necessária para ler o conteúdo protegido.
O que os metadados revelam?
Os metadados podem mostrar quais contas se comunicaram, quando estiveram ativas, de quais grupos participam e quanto volume de dados foi transferido. Essas informações não são o texto das mensagens, mas têm valor para compreender redes de comunicação ou padrões de atividade.
A página de segurança do Livara descreve explicitamente o armazenamento e processamento de dados operacionais, incluindo roteamento, participação, horários, tamanho do texto cifrado e status de entrega. A confidencialidade do conteúdo privado não deve ser interpretada como anonimato completo nem como ausência de quaisquer dados no servidor.
SRP não elimina o risco de adivinhar senhas a partir dos dados de conta
SRP é um método para provar conhecimento de uma senha sem transmitir diretamente a própria senha. O servidor ainda armazena dados verificadores, ou verifier. A seção de segurança do RFC 5054 explica que o roubo do verifier pode possibilitar um ataque de dicionário para adivinhar a senha.
Assim, «a senha não é transmitida pela rede» é diferente de «não existem dados relacionados à senha que possam ser roubados». Uma senha forte e exclusiva, a proteção do dispositivo e uma resposta adequada ao incidente continuam necessárias. SRP também não substitui a criptografia de conteúdo nem a proteção das sessões de login.
Quais limites o Livara declara?
A documentação de segurança do Livara descreve LVR1 para mensagens diretas e LGS1 para grupos protegidos. A proteção de um grupo depende de seu estado real; um grupo antigo incompatível não deve receber o rótulo E2EE. Canais públicos ficam fora desse limite de confidencialidade.
O mesmo documento apresenta a recuperação v7 como um pacote de identidade criptografado, protegido antes do envio. Esse processo restaura a identidade criptográfica, não o histórico de conversas. A exposição da frase de recuperação ou do dispositivo que contém as chaves é um cenário diferente do simples roubo do banco de dados.
Estas são descrições publicadas do produto, não resultados de uma auditoria independente feita por este artigo. Citar AES ou ML-KEM, por si só, também não comprova a correção do gerenciamento de chaves e da implementação do aplicativo.
Que perguntas fazer quando um incidente é anunciado?
- Qual período e quais sistemas foram afetados? A expressão vaga «dados dos usuários» não basta.
- Ficaram acessíveis texto em claro, arquivos, chaves, verifier, sessões de login ou apenas texto cifrado?
- O invasor podia alterar o serviço ou o software entregue aos usuários?
- Quais ações são necessárias pelo canal oficial: encerrar sessões, mudar a senha, atualizar ou verificar a identidade de um contato?
- A recomendação de recuperação pode apagar o histórico local? Leia as limitações antes de remover o aplicativo.
Não use links de mensagens anônimas para «verificar a conta com urgência». Abra o comunicado de forma independente pelo endereço oficial. O modelo de ameaças do Livara ajuda a entender limites gerais; o alcance de um incidente real deve ser definido pelas evidências daquele incidente.
