Entre todos os e-mails que sua aplicação envia, os e-mails de redefinição de senha têm o maior risco. Se você fizer errado, cria uma vulnerabilidade de segurança que invasores vão explorar. Se fizer certo, constrói um fluxo de recuperação seguro e amigável que gera confiança.
E-mails de redefinição de senha também estão entre os mais sensíveis ao tempo. Um usuário que está bloqueado fora da conta fica frustrado e ansioso. Cada minuto que espera pelo e-mail de redefinição é um minuto em que pode desistir, contatar o suporte ou perder confiança no seu produto.
Fundamentos de segurança
E-mails de redefinição de senha são um alvo principal para invasores porque oferecem um caminho para assumir contas. Seu fluxo de redefinição precisa ser seguro por design.
Nunca envie senhas por e-mail. Nem senhas temporárias, nem senhas geradas, nem nada. E-mail não é um canal seguro—pode ser interceptado, encaminhado ou acessado por qualquer pessoa com acesso à caixa de entrada. Sempre use um link de redefinição seguro que permita ao usuário definir sua própria senha.
Tokens de redefinição devem ser criptograficamente aleatórios e impossíveis de adivinhar. Use o gerador de números aleatórios seguro da sua plataforma, não valores previsíveis como timestamps ou IDs sequenciais. Um token deve ter pelo menos 128 bits de entropia.
Tokens devem ter vida curta. De 15 minutos a 1 hora é razoável. Janelas de expiração mais longas dão mais tempo para invasores interceptarem ou adivinharem tokens. Usuários que não redefinirem dentro do prazo podem solicitar um novo token.
Tokens devem ser de uso único. Assim que um token for usado para redefinir a senha, invalide-o imediatamente. Isso evita ataques de replay, nos quais um invasor usa um token interceptado após o usuário legítimo.
Armazene tokens com segurança. Faça hash dos tokens antes de armazená-los no seu banco de dados, assim como senhas. Se seu banco de dados for comprometido, invasores não devem conseguir usar os tokens armazenados.
Experiência do usuário
Segurança e usabilidade não são opostos—um fluxo de redefinição confuso leva a chamados de suporte e contornos que criam seus próprios problemas de segurança.
Envie e-mails de redefinição imediatamente. Os usuários estão esperando. Um e-mail de redefinição que demora 10 minutos para chegar parece quebrado. Priorize e-mails de redefinição na sua fila de envio—eles devem sair em segundos.
Deixe o link de redefinição impossível de perder. Um botão grande e óbvio que diga 'Redefinir senha' funciona melhor do que um link de texto escondido em um parágrafo. Usuários estão procurando pela ação, não lendo com atenção.
Mantenha o e-mail focado. Não é hora de conteúdo promocional, links de redes sociais ou design elaborado. O usuário tem um objetivo: redefinir a senha. Todo o resto é distração.
Inclua contexto sobre a solicitação. Quando foi solicitada? De qual IP ou localização? Isso ajuda os usuários a identificar se a solicitação foi legítima ou se alguém está tentando acessar a conta deles.
Ofereça um caminho claro caso não tenham solicitado a redefinição. 'Se você não solicitou isto, pode ignorar este e-mail' é tranquilizador. Alguns usuários receberão e-mails de redefinição que não solicitaram (erros de digitação, tentativas maliciosas) e precisam saber que estão seguros.
O fluxo de redefinição
O fluxo completo de redefinição tem várias etapas, cada uma com implicações de segurança:
A página de solicitação deve pedir apenas um endereço de e-mail. Não confirme se o endereço existe no seu sistema—isso vaza informações para invasores tentando enumerar contas. Sempre mostre a mesma mensagem: 'Se existir uma conta com este e-mail, enviamos instruções de redefinição.'
Limite a taxa de solicitações de redefinição. Um invasor não deve ser capaz de inundar um endereço de e-mail com e-mails de redefinição (assédio) nem tentar muitos endereços rapidamente (enumeração). Limite solicitações por e-mail e por IP.
A página de redefinição (onde o usuário chega após clicar no link) deve validar o token antes de mostrar o formulário de senha. Se o token for inválido ou estiver expirado, mostre um erro claro e permita solicitar um novo.
Após a redefinição bem-sucedida, invalide o token, invalide todas as outras sessões da conta (o usuário pode estar redefinindo porque suspeita de comprometimento) e envie um e-mail de confirmação informando que a senha foi alterada.
O e-mail de confirmação é um recurso de segurança. Se outra pessoa redefiniu a senha, o usuário legítimo verá esse e-mail e saberá que sua conta foi comprometida. Inclua informações sobre como recuperar a conta caso não tenha sido ele.
Erros comuns
Mesmo desenvolvedores experientes cometem erros em fluxos de redefinição de senha:
Tokens previsíveis são surpreendentemente comuns. Usar o ID do usuário, hash do e-mail ou timestamp como token (ou parte dele) torna os tokens adivinháveis. Sempre use valores aleatórios criptograficamente seguros.
Não expirar tokens deixa uma janela aberta indefinidamente. Se um usuário solicitar a redefinição, mas não concluir, esse token não deve funcionar para sempre. Implemente expiração.
Não invalidar tokens após o uso permite ataques de replay. Uma vez usado, um token nunca deve funcionar novamente, mesmo que ainda não tenha expirado.
Confirmar a existência do e-mail ajuda invasores. Se sua página de redefinição diz 'nenhuma conta encontrada' para e-mails inválidos, invasores podem usar isso para construir uma lista de contas válidas. Sempre mostre a mesma resposta.
Não notificar após a redefinição deixa usuários sem saber de um possível comprometimento. O e-mail de confirmação é um controle de segurança crítico, não apenas um diferencial.
Entrega lenta frustra usuários e os leva a contornos inseguros. Se e-mails de redefinição são lentos, os usuários podem tentar várias vezes, contatar o suporte para redefinições manuais ou desistir completamente. Velocidade importa.
O conteúdo do e-mail
O e-mail de redefinição em si deve ser simples e claro:
Assunto: Mantenha direto. 'Redefina sua senha' ou 'Solicitação de redefinição de senha' funciona. Evite táticas de urgência que parecem phishing.
Remetente: Use um nome e endereço de remetente reconhecíveis. 'YourApp <[email protected]>' é melhor do que '[email protected]'. Os usuários devem reconhecer imediatamente de quem é o e-mail.
Corpo: Explique o que aconteceu ('Você solicitou uma redefinição de senha'), forneça o botão/link de redefinição, mencione a expiração ('Este link expira em 1 hora') e explique o que fazer caso não tenha solicitado.
Não inclua o nome de usuário ou outros detalhes da conta. Se o e-mail for interceptado, você não quer dar mais informações do que o necessário a invasores.
Considere incluir o contexto da solicitação (IP, localização, hora) para que os usuários possam verificar se a solicitação foi legítima. Mas equilibre isso com preocupações de privacidade—alguns usuários não querem sua localização no e-mail.
Frequently asked questions
Por quanto tempo os tokens de redefinição devem ser válidos?
De 15 minutos a 1 hora é típico. Mais curto é mais seguro, mas pode frustrar usuários que não checam e-mail imediatamente. 1 hora é um equilíbrio razoável para a maioria das aplicações.
Devo exigir a senha antiga para definir uma nova?
Não—todo o objetivo da redefinição de senha é que o usuário não sabe sua senha atual. O token de redefinição serve como prova de identidade. Exigir a senha antiga anularia o propósito.
E se o e-mail do usuário estiver comprometido?
A redefinição de senha via e-mail pressupõe que a conta de e-mail é segura. Se não for, o invasor pode redefinir senhas de quaisquer contas vinculadas. Considere oferecer métodos alternativos de recuperação (SMS, códigos de backup, perguntas de segurança) para aplicações de alta segurança.
Devo fazer login dos usuários automaticamente após a redefinição?
As opiniões variam. Login automático é mais conveniente, mas significa que qualquer pessoa com o link de redefinição obtém acesso. Exigir login após a redefinição adiciona fricção, mas garante que o usuário saiba que a nova senha funciona. Para aplicações de alta segurança, exija login.