Troy Hunt destaca alguns pontos excelentes em seu artigo, Tudo o que você sempre quis saber sobre a criação de um recurso de redefinição de senha segura . Os trechos mais relevantes são:
[T] aqui estão duas abordagens comuns:
- Gere uma nova senha no servidor e envie-a por email
- Enviar por e-mail um URL exclusivo que facilitará um processo de redefinição
Apesar de muita orientação em contrário, o primeiro ponto não é realmente onde queremos estar. O problema é que isso significa que uma senha persistente - uma senha com a qual você pode voltar e usar a qualquer momento - foi enviada por um canal inseguro e reside na sua caixa de entrada.
...
Mas há mais um grande problema com a primeira abordagem, na medida em que simplifica completamente o bloqueio malicioso de uma conta. Se eu souber o endereço de e-mail de alguém que possui uma conta em um site, posso bloqueá-lo sempre que quiser, simplesmente redefinindo sua senha; é um ataque de negação de serviço servido em uma bandeja de prata! É por isso que uma redefinição é algo que só deve ocorrer após a verificação bem-sucedida do direito do solicitante.
Quando falamos sobre um URL de redefinição, estamos falando de um endereço de site exclusivo para esta instância específica do processo de redefinição.
...
O que queremos fazer é criar um token exclusivo que possa ser enviado em um email como parte do URL de redefinição e depois corresponder a um registro no servidor ao lado da conta do usuário, confirmando assim que o proprietário da conta de email é realmente aquele que está tentando redefinir o senha. Por exemplo, o token pode ser "3ce7854015cd38c862cb9e14a1ae552b" e é armazenado em uma tabela ao lado do ID do usuário que está executando a redefinição e o horário em que o token foi gerado (mais sobre isso em um momento). Quando o email é enviado, ele contém um URL como "Redefinir /? Id = 3ce7854015cd38c862cb9e14a1ae552b" e, quando o usuário carrega isso, a página verifica a existência do token e, consequentemente, confirma a identidade do usuário e permite a senha. ser alterado.
...
A outra coisa que queremos fazer com um URL de redefinição é limitar o token por tempo, para que o processo de redefinição seja concluído dentro de uma certa duração, digamos, dentro de uma hora.
...
Finalmente, queremos garantir que este seja um processo único. Após a conclusão do processo de redefinição, o token deve ser excluído para que o URL de redefinição não funcione mais. Como no ponto anterior, isso garante que um invasor tenha uma janela muito limitada na qual possa abusar do URL de redefinição. Além disso, é claro que o token não será mais necessário se o processo de redefinição for concluído com êxito.
Ele faz muitos outros pontos positivos sobre como evitar vazamentos de informações, CAPTCHAs, autenticação de dois fatores e, claro, as práticas recomendadas básicas, como hash de senha. Acho importante notar que discordo de Troy sobre a utilidade das questões de segurança, preferindo o ceticismo de Bruce Schneier quanto à prática :
O objetivo de todas essas perguntas é o mesmo: uma senha de backup. Se você esquecer sua senha, a pergunta secreta poderá verificar sua identidade, para que você possa escolher outra senha ou fazer com que o site envie a sua senha atual por e-mail. É uma ótima idéia do ponto de vista do atendimento ao cliente - é menos provável que o usuário esqueça o nome do primeiro animal de estimação do que alguma senha aleatória -, mas é péssimo para a segurança. A resposta para a pergunta secreta é muito mais fácil de adivinhar do que uma boa senha, e as informações são muito mais públicas.