Redefinindo a senha do ASP.NET - Problemas de segurança?

Question

Vi várias perguntas sobre esse problema, mas há algumas perguntas que não foram feitas. Se o usuário esquecer sua senha, gostaria que eles pudessem redefini -la apenas com o endereço de e -mail (ou seja, não há pergunta/resposta de segurança). A senha é armazenada como um hash salgado, então não há recuperação possível. Em vez disso, gostaria que o usuário insira uma nova senha depois de confirmar que eles solicitaram uma redefinição.

Um método comum mencionado é simplesmente:

1) Crie um número aleatório aleatório/criptograficamente forte

2) Envie um URL exclusivo que contém o número aleatório para o endereço de e -mail do usuário

3) Quando confirmado, o usuário é solicitado a alterar a senha

No entanto, isso não é aberto a um MITM ataque? Se o envio de senhas temporárias pela Internet para um email é inseguro, qual é a diferença entre fazer isso e simplesmente enviar um URL exclusivo para o qual o invasor pode navegar? Perdi uma etapa -chave em algum lugar que tornará esse sistema mais seguro (ou existe uma maneira melhor de redefinir a senha)?

Obrigado

Answer 1

Houve alguma confusão em torno da depreciação de soluções de sandbox. Essencialmente, apenas código gerenciado personalizado (em soluções Sandbox) foi reprovada.

a partir do (oficial) blog do SharePoint dev :

.

Ao desenvolver soluções sandboxes que contenham apenas marcação declarativa e JavaScript - que chamamos de soluções de sandbox (NCSS) de nenhum código (NCSS) - ainda é viável, reprovamos o uso de código gerenciado personalizado dentro da solução Sandboxed ... A natureza dinâmica dos serviços on-line, determinaremos as necessidades de suporte para soluções de sandbox codificadas no SharePoint Online com base na demanda do cliente. NCSSS continuam a ser suportados.

Em termos de melhor prática, isso é um pouco debatível, embora eu acredite que o CSOM está ganhando a batalha sobre as soluções de sandbox declarativas.

Confira este ótimo Blog Post Sobre isso.

Answer 2

Seus meios de autenticar o usuário são um segredo compartilhado (a senha).

Se o usuário esquecer esse segredo, você precisa de uma maneira de estabelecer um novo segredo compartilhado. Não importa de que maneira você faça isso, você ainda terá o problema de autenticar o usuário para compartilhar esse novo segredo.

Se a única coisa que você souber sobre o usuário que pode ser usado para autenticá -los é o endereço de e -mail deles, você precisará de alguma maneira de confirmar que o usuário que solicita uma redefinição está no controle desse endereço de email.

E a única maneira de fazer isso é enviar um segredo por e -mail para esse endereço de e -mail e verificar se eles o receberam.

Que sempre será aberto a um ataque de MITM suficientemente sorrateiro.

O motivo pelo qual você não envia uma senha temporária é evitar a questão de "o usuário não pode se incomodar em mudar e, portanto, continua usando a senha temporária insegura em vez de sua própria segura".

Answer 3

Para mitigar o risco de um homem no ataque intermediário, uso as seguintes medidas:

• Uma solicitação de redefinição pode ser usada apenas uma vez.
• Se uma solicitação de redefinição não for usada, ela expirará após uma hora.
• Todas as solicitações de redefinição são registradas permanentemente se foram finalmente concluídas ou expiradas.