Esta é a parte mais sensível de segurança no Server Manager. Veja exatamente o que acontece com suas credenciais SSH em cada etapa.
Ao conectar um servidor (sem salvar)
O caminho padrão: digite o IP do servidor, o nome de usuário e a senha/chave privada no modal de conexão e clique em Conectar.
- Suas credenciais são enviadas por HTTPS para o Server Manager
- Elas ficam na memória do processo da sessão no lado do servidor que se comunica com seu VPS
- Nada é gravado em disco. Nem banco de dados, nem arquivo de log, nem cache.
- Quando você desconecta, fecha a aba do navegador ou a sessão expira, as credenciais são descartadas da memória
Se nosso servidor for reiniciado, suas credenciais desaparecem — você vai precisar reconectar manualmente da próxima vez. Isso é intencional.
Ao salvar um perfil de servidor (opcional)
Se você marcar "Salvar este servidor" durante a conexão, criptografamos suas credenciais com uma frase-senha que só você conhece.
O que é criptografado
O blob criptografado contém sua senha SSH OU sua chave privada + a frase-senha opcional da chave. Ele também inclui um pequeno cabeçalho de metadados para sabermos qual tipo de credencial usar.
Como a criptografia funciona
- Você informa uma frase-senha ao salvar (recomendamos usar algo que você não use para mais nada)
- A frase-senha passa pelo scrypt — uma função de derivação de chave baseada em senha que é deliberadamente lenta — com um salt aleatório de 16 bytes por servidor, para gerar uma chave AES de 256 bits
- Suas credenciais são criptografadas com AES-256-GCM (criptografia autenticada — texto cifrado adulterado não descriptografa, sem ataques de oráculo de padding)
- Armazenamos no banco de dados o texto cifrado criptografado, o salt, o nonce do GCM e a tag de autenticação do GCM
- Sua frase-senha nunca é armazenada. Nem como hash, nem derivada, nem presente em qualquer lugar do nosso lado.
Como diferenciamos "frase-senha errada" de "dados adulterados"
As duas situações falham da mesma forma: a verificação da tag de autenticação do AES-GCM falha. Não existe um verificador armazenado para comparar com sua frase-senha, nem um hash que possa vazar. Frase-senha errada = erro de descriptografia = você digita de novo e tenta novamente.
Ao reconectar a um servidor salvo
Você cola sua frase-senha. Nós derivamos a chave novamente com scrypt + o salt armazenado, descriptografamos o blob de credenciais, usamos as credenciais descriptografadas para abrir a sessão SSH e então descartamos imediatamente as credenciais descriptografadas da memória assim que a sessão é estabelecida.
As credenciais SSH descriptografadas existem apenas no código que gerencia a sessão durante a vida útil da própria conexão SSH. Igual ao fluxo sem salvar acima — somente em memória, nada em disco.
O que acontece se nosso servidor for comprometido
Esta é a ameaça contra a qual projetamos o sistema. Na prática:
- O invasor obtém acesso de leitura ao banco de dados: ele recebe texto cifrado. Para usar qualquer credencial salva, precisa tentar quebrar a frase-senha por força bruta em cada servidor. - scrypt é intencionalmente lento — cada tentativa de frase-senha leva ~100ms+ de tempo de CPU em hardware moderno. Quebrar por força bruta até mesmo uma frase-senha aleatória de 6 caracteres levaria anos em uma única máquina, décadas em GPUs comuns.
- O invasor consegue comprometer totalmente o servidor (RCE — execução remota de código — durante uma sessão ativa): ele poderia ler credenciais descriptografadas de usuários que estão online naquele momento. Mas não consegue acessar credenciais de usuários salvos que estão offline.
- O invasor obtém um backup do banco de dados da semana passada: igual ao acesso de leitura — ele tem apenas texto cifrado.
O que isso significa para você, na prática
Os três cenários acima representam exposições muito diferentes no mundo real:
- Leitura do banco de dados ou backup roubado (o tipo mais comum de violação): o invasor obtém blobs criptografados e nada mais. Para realmente usar qualquer credencial salva, ele teria que quebrar sua frase-senha por força bruta, e o scrypt torna isso inviável quando a frase-senha é forte. Seus servidores continuam seguros.
- Servidor totalmente comprometido enquanto você está conectado ativamente (raro e grave): como uma sessão SSH aberta precisa das suas credenciais reais em memória, um invasor que controle nosso processo em execução nesse intervalo poderia extrair as credenciais descriptografadas de usuários conectados naquele momento e usá-las para entrar nos servidores reais desses usuários. Se você estiver offline nesse momento, suas credenciais salvas ainda são apenas texto cifrado para ele — você não é afetado.
A propriedade principal: mesmo no cenário de pesadelo com comprometimento total, o raio de impacto fica limitado a "quem por acaso estiver online durante o ataque", não a "todo mundo que já usou o Server Manager." A maioria das violações catastróficas expõe os segredos de todos os usuários de uma vez; este desenho evita isso de propósito.
| Tipo de violação | O que o invasor obtém |
|---|---|
| Leitura do banco de dados (mais comum) | Apenas texto cifrado — nenhuma credencial utilizável de ninguém |
| Backup do banco de dados roubado | Apenas texto cifrado |
| RCE em sessão ativa (raro, grave) | Credenciais descriptografadas de apenas usuários conectados naquele intervalo |
Esta é uma proteção relevante contra o padrão mais comum de violação (exfiltração de dados), e aceita deliberadamente que um invasor com comprometimento total do servidor em tempo real é uma ameaça diferente e mais difícil, que não afirmamos derrotar por completo — ainda assim limitando até esse pior caso aos usuários online no momento.
Recomendações para uma frase-senha forte
Todo o esquema de criptografia é tão forte quanto sua frase-senha. Recomendamos:
- Pelo menos 20 caracteres aleatórios, ou
- Cinco palavras aleatórias em inglês (no estilo de "correct horse battery staple") — fáceis de lembrar, difíceis de quebrar por força bruta
- Nunca reutilize a frase-senha que você usa para entrar no notebook, no gerenciador de senhas ou no email
- Não compartilhe. O próprio Server Manager não precisa dela — ela fica apenas entre você e o blob criptografado.
Se você perder a frase-senha, as credenciais salvas não poderão ser recuperadas. Você precisaria apagar o perfil de servidor salvo e adicioná-lo novamente do zero.
Por que não oferecemos acesso a chaves "sem senha" ou por "conveniência"
Alguns produtos armazenam chaves SSH sem criptografia ("confie na gente, vamos mantê-las seguras") ou protegidas apenas pela senha da conta do usuário. O Server Manager não faz isso. O mecanismo de frase-senha é a linha que separa "qualquer pessoa com nosso banco de dados pode acessar seus servidores por SSH" de "qualquer pessoa com nosso banco de dados precisa primeiro quebrar sua frase-senha por força bruta." Achamos que isso vale o pequeno inconveniente de escolher uma frase-senha uma única vez.
O que NUNCA é enviado ou armazenado
- Chaves privadas SSH em texto claro no nosso banco de dados
- Senhas SSH em texto claro no nosso banco de dados
- Sua frase-senha de criptografia — em qualquer lugar, de qualquer forma
- Credenciais descriptografadas em qualquer armazenamento persistente — disco, logs, backups, cache
O único lugar onde credenciais descriptografadas existem é na memória do processo da sessão ativa, e somente durante a duração da sessão.
Dúvidas ou preocupações?
Se algo neste artigo não estiver claro, ou se você tiver uma pergunta específica de segurança sobre como suas credenciais são tratadas, fale conosco pelo Contato — teremos prazer em explicar com mais detalhes.