Envie o segredo por um caminho e a chave que o abre por outro. Essa regra sozinha já é quase toda a resposta. Uma senha colada num e-mail é uma senha que agora mora na sua pasta de enviados, na caixa de entrada da outra pessoa, em dois servidores de e-mail e nos backups que essas empresas guardarem — e você não consegue apagar nada disso. Uma senha enviada como bloco cifrado por e-mail, com a frase secreta ditada por telefone, é uma senha que nada em nenhum dos dois arquivos consegue abrir. O resto deste texto é como fazer isso sem transformar um favor de dois minutos num projeto.
Por que colar a senha no e-mail ou no chat é pior do que parece
O transporte costuma estar em ordem. Os servidores de e-mail conversam entre si por TLS e a maioria dos apps de chat cifra em trânsito. O problema é que as mensagens ficam armazenadas, em mais lugares do que você está contando:
- A sua cópia e a dela. Apagar a sua não faz nada com a da outra pessoa. Você não faz ideia de por quanto tempo a caixa de entrada dela guarda as coisas, nem de quem mais consegue abri-la.
- A busca. As duas caixas são indexadas por texto completo. Qualquer um que depois entre em uma das duas contas pode digitar a palavra "senha" e receber uma lista.
- Os administradores. Num sistema de e-mail corporativo ou num workspace de chat pago, um administrador normalmente consegue exportar o histórico — e, dependendo do plano, isso pode incluir as mensagens diretas. Ninguém precisa ser mal-intencionado para isso doer; acontece durante uma retenção legal de rotina.
- O encaminhamento. Quem recebeu responde a um colega com a thread inteira citada embaixo, e agora a senha está numa quarta caixa de entrada.
- Backups e dispositivos. O celular que recebeu faz backup de si mesmo. O computador que leu sincroniza o seu armazenamento de e-mail. Cada um é mais uma cópia com a sua própria vida útil.
Nada disso exige que alguém intercepte coisa alguma. A mensagem causa o estrago só por continuar existindo.
Separe o segredo da chave que o abre
O princípio que funciona se chama entrega fora de banda (out-of-band) e não é complicado: aquilo que você envia e aquilo que o destrava precisam viajar por canais que não seriam comprometidos pelo mesmo evento.
Na prática, você transforma a senha em algo inútil sozinho antes que ela vá a qualquer lugar. Cole-a numa ferramenta de criptografia no navegador, escolha uma frase secreta e você recebe um bloco em base64 que dá para soltar sem medo num e-mail, num ticket ou numa mensagem de chat. É AES-256-GCM com uma chave derivada da sua frase secreta por PBKDF2 ao longo de 250.000 rodadas, e roda na própria página: nada é enviado, então nenhum terceiro servidor guarda o seu segredo. Depois você diz a frase secreta para a outra pessoa de viva voz.
Agora um atacante precisa das duas metades, vindas de dois lugares diferentes. O arquivo de e-mail dá a ele um bloco de base64; a ligação escutada dá a ele uma frase secreta sem nada para abrir.
O que conta como segundo canal
Um que falhe de forma independente do primeiro. O bloco por e-mail e a frase secreta por e-mail dez minutos depois são um único canal usado duas vezes.
- Bom: uma ligação telefônica, pessoalmente, ou um app de mensagens em outra conta e num aparelho diferente daquele que recebeu o bloco.
- Aceitável: o SMS. Realmente fraco — os SIM swaps existem — mas falha por razões diferentes das do e-mail corporativo, e é justamente esse o ponto.
- Não é um segundo canal: um segundo e-mail, uma resposta na mesma thread ou o mesmo app de chat que você acabou de usar. Mesma conta, mesmo comprometimento.
Os métodos que funcionam de verdade, mais ou menos em ordem
O recurso de compartilhamento do seu gerenciador de senhas
Se vocês dois já usam o mesmo gerenciador de senhas, essa é a melhor opção, disparado. A credencial é compartilhada como um item, e não como texto, então ela nunca chega a cair numa mensagem, você pode revogar o acesso depois e, quando a senha muda, a outra pessoa recebe a nova. Vários gerenciadores também geram links de uso único para gente de fora da sua conta, normalmente com prazo de validade e um limite de visualizações. Veja o que o seu oferece: o conjunto de recursos varia muito entre produtos e planos.
Um link que se autodestrói
Serviços que guardam um segredo uma vez, entregam uma URL e apagam o segredo depois que ele é lido. Prático, e os bem construídos mantêm a chave de descriptografia no fragmento da URL — a parte depois do #, que os navegadores nunca enviam ao servidor — de modo que quem opera o serviço não consegue ler o que guarda.
Duas coisas estragam isso. Você está confiando que a página que te entregaram é a página que você acha que é, e não dá para verificar isso de fora. E as prévias de link são uma praga: apps de chat e clientes de e-mail buscam as URLs automaticamente para montar uma miniatura, então se o segredo fica no caminho em vez de ficar no fragmento, o bot da prévia pode queimar a única visualização antes de a outra pessoa clicar. Quando dizem que o link já foi usado, normalmente foi isso que aconteceu.
Um bloco cifrado mais uma frase secreta dita em voz alta
Mais atrito, nenhum terceiro envolvido em momento algum. Bom quando o segredo precisa atravessar um sistema que guarda registros de propósito — um ticket de suporte, uma caixa de e-mail compartilhada, o portal de compras de um cliente — porque o registro que ele guarda não significa nada.
Simplesmente ler a senha em voz alta
Subestimado para segredos curtos. Nenhuma cópia em lugar nenhum, nenhum software, nenhum servidor em que confiar. Use o alfabeto fonético da OTAN para qualquer coisa que diferencie maiúsculas e leva trinta segundos. Isso desmorona com uma API key de 32 caracteres, que é quando as opções acima ganham o atrito que impõem.
A frase secreta é a parte mais fraca, sempre
A criptografia te dá um bloco que vale apenas o que vale aquilo que o protege, e um atacante que tem o bloco fica adivinhando offline — no hardware dele, em paralelo, pelo tempo que quiser. Sem limite de tentativas, sem bloqueio, sem ninguém olhando. Uma palavra do dicionário com um número atrás não sobrevive a isso, seja qual for a cifra.
Use quatro ou cinco palavras genuinamente aleatórias. "Aleatórias" é o que faz o trabalho nessa frase: as palavras que você escolhe sozinho se agrupam em torno do que você gosta e do que está no cômodo, o que encolhe o espaço de busca. Um gerador que escolhe por você elimina esse problema, e a diferença entre uma frase secreta e uma senha explica por que uma frase escolhida por uma máquina ganha de uma escolhida com esperteza por uma pessoa por cerca de trinta bits de entropia.
E ela serve só para esta mensagem. Não use a que abre o seu computador.
A melhor versão disso é não enviar senha nenhuma
Antes de criptografar qualquer coisa, veja se o sistema tem um fluxo de convite. A maioria tem. Um convite para que a pessoa crie as próprias credenciais significa que não existe segredo compartilhado algum, que não há nada para interceptar nem nada para lembrar de rotacionar. O mesmo vale para o SSO, para os tokens de API com escopo limitado e prazo de validade, e para uma senha temporária que o sistema obriga a trocar no primeiro login.
Quando você realmente precisa entregar uma senha de verdade — uma conta antiga, um login de cobrança compartilhado, um roteador — trate o momento do compartilhamento como o início de um prazo de validade. A senha já está no histórico de área de transferência da pessoa, possivelmente numa anotação que ela fez para não esquecer, e em qualquer lugar onde ela colou por engano. Troque a senha quando o motivo do compartilhamento terminar, e imediatamente se a pessoa sair.
Do que nada disso protege
A abordagem do bloco cifrado pode parecer mais completa do que é.
Ela não protege uma máquina comprometida. Com um keylogger em qualquer uma das duas pontas, o segredo se perde no instante em que é digitado ou colado, e cuidado no trânsito não muda nada.
A área de transferência é compartilhada. Tanto o bloco quanto o resultado descriptografado passam por ela, e outros aplicativos na mesma máquina muitas vezes conseguem lê-la. Alguns gerenciadores de área de transferência guardam meses de histórico pesquisável.
Ela não prova nada sobre quem enviou. Um bloco que descriptografa direitinho não foi modificado por ninguém sem a frase secreta — é isso que a tag de autenticação do GCM garante. Ele não prova quem escreveu, porque qualquer um com a frase secreta consegue escrever um. Criptografia, assinatura e o que um hash garante e o que não garante são três trabalhos diferentes, e confundi-los é o que faz as pessoas acabarem confiando na coisa errada.
Os hábitos de quem recebe estão fora do seu controle. Você pode entregar uma senha perfeitamente e ver a pessoa colá-la numa planilha compartilhada chamada Logins. Diga a ela onde guardar, não só o que é.
Para os casos em que uma senha precisa atravessar um canal que guarda registros, a ferramenta de criptografia de texto daqui a transforma num bloco que dá para colar em qualquer lugar, com a chave derivada no seu navegador e nada enviado a nenhum servidor. Depois diga a frase secreta em voz alta para a pessoa, e as duas metades nunca se encontram no mesmo arquivo.
Separar o segredo, porém, é só metade da defesa. A outra metade é fazer a senha valer menos para quem acabar encontrando, que é o que um segundo fator faz — como esses códigos de seis dígitos são gerados explica por que uma senha roubada sozinha deixa de ser suficiente.
Perguntas frequentes
Como envio uma senha com segurança por e-mail?
Não coloque a senha em si na mensagem. Transforme-a primeiro num bloco cifrado e envie a frase secreta por outro caminho, como uma ligação telefônica, ou compartilhe pelo gerenciador de senhas. O e-mail fica armazenado indefinidamente em pelo menos quatro lugares que você não controla, então qualquer coisa legível no corpo deve ser tratada como permanente.
É seguro enviar uma senha pelo Slack ou pelo Teams?
Não é mais seguro que o e-mail. O transporte é criptografado, mas a mensagem fica retida, é pesquisável e, em workspaces pagos, um administrador normalmente consegue exportar o histórico, que dependendo do plano pode incluir as mensagens diretas. Se você já fez isso, troque a senha em vez de apagar a mensagem.
WhatsApp ou Signal são bons o bastante para enviar uma senha?
Eles são melhores que o e-mail porque a mensagem é criptografada de ponta a ponta em trânsito, então o provedor não consegue lê-la. As cópias nos dois celulares continuam lá, porém, junto com tudo de que esses celulares fizerem backup. Use-os como segundo canal para uma frase secreta, não como o lugar onde você cola a credencial inteira.
O que é um link de segredo de uso único e dá para confiar nele?
É um serviço que guarda um segredo, te dá uma URL e apaga o segredo depois da primeira visualização. Os melhores mantêm a chave de descriptografia no fragmento da URL, para que o servidor nunca a receba, mas você ainda está confiando que a página que te entregaram se comporta como promete. Fique atento às prévias de link nos apps de chat, que podem consumir a única visualização antes de a pessoa clicar.
Devo trocar uma senha depois de compartilhá-la com alguém?
Sim, assim que o motivo do compartilhamento terminar, e imediatamente se a pessoa sair do time. Depois de compartilhada, a senha existe no histórico de área de transferência dela, possivelmente numa anotação que ela escreveu, e em qualquer lugar onde ela colou por acidente. Trate o momento em que você compartilha como o início do prazo de validade da senha.
Qual é a forma mais segura de enviar uma senha para um cliente não técnico?
Veja primeiro se o sistema consegue mandar para ele um convite para definir a própria senha, o que elimina o segredo compartilhado por completo. Se não der, leia a senha por telefone e peça que ele digite direto na tela de login. Segredos curtos ditos por voz ganham de qualquer ferramenta que você precise explicar passo a passo.
Última atualização 19 de setembro de 2026