Ripristino password di ASP.NET - problemi di sicurezza?

Question

Ho visto varie domande riguardo a questo problema, ma ci sono un paio di domande che non sono state poste. Se l'utente dimentica la propria password, vorrei che fossero in grado di ripristinare con solo il loro indirizzo di posta elettronica (vale a dire non c'è nessuna sicurezza domanda / risposta). La password viene memorizzata come hash salata, quindi non c'è nessun recupero possibile. Invece, vorrei solo all'utente di inserire una nuova password dopo aver confermato che essi hanno richiesto un reset.

  

Un metodo comune che è stato detto è semplicemente:

     

1) Creare un numero casuale Guid / crittografia forte casuale

     

2) Invia un URL univoco contenente il numero casuale per e-mail dell'utente   indirizzo

     

3) Quando ha confermato, all'utente viene chiesto di cambiare la password

Tuttavia, non è questo aperto a un attacco MITM? Se l'invio di una password temporanee su Internet ad una e-mail è insicuro, qual è la differenza tra il fare questo e il semplice invio di un URL univoco, che l'attaccante può navigare? Ho perso una qualche chiave di fase che renderà questo sistema più sicuro (o c'è un modo migliore di reimpostare la password)?

Grazie

Answer 1

Se si costruisce correttamente il hash, l'URL di click dovrà provenire dall'indirizzo IP che ha richiesto il reset. Ciò richiederebbe il MITM per falsificare l'indirizzo IP e / o falsificare le intestazioni. Anche se questo è possibile, il più unico è possibile identificare l'hash per il sistema in questione, tanto più difficile diventa per "end-around" l'hash.

Si raccomanda inoltre che il GUID sia un hash unidirezionale di determinati criteri. E 'anche possibile per crittografare i dati di sistema nella richiesta utilizzando una chiave pubblica che una chiave privata sblocca in modo che quando l'URL viene cliccato, questi stessi dati pubblici di sistema criptati devono accompagnare l'hash, e l'unico sistema che potrebbe decrittografare questi valori sarebbe la chiave privata tenutasi presso il server. Fondamentalmente un attacco pseudo-PKI per l'hash.

Answer 2

I tuoi mezzi di autenticare l'utente è un segreto condiviso (la password).

Se l'utente dimentica quel segreto, avete bisogno di un modo di stabilire un nuovo segreto condiviso. Non importa quale modo si va su di esso, avrai ancora il problema di autenticare l'utente al fine di condividere quel nuovo segreto.

Se l'unica cosa che sai sull'utente che potrebbero essere utilizzati per l'autenticazione di loro è il loro indirizzo di posta elettronica, quindi avrete bisogno di un modo per confermare che l'utente che richiede un reset è in controllo di tale indirizzo di posta elettronica.

E l'unico modo finora per farlo è quello di e-mail un segreto a questo indirizzo e-mail e verificare se hanno ricevuto.

che è sempre sta per essere aperto a un attacco sufficientemente subdolo MitM.

Il motivo non si invia una password temporanea è quello di evitare la questione della "l'utente non può essere disturbato cambiare e così mantiene utilizzando la password temporanea insicuro, invece di una propria sicura".

Answer 3

Per mitigare il rischio di un attacco man in the middle io uso le seguenti misure:

• Una richiesta di ripristino può essere utilizzato solo una volta.
• Se una richiesta di reset non viene utilizzato, scade dopo un'ora.
• Tutte le richieste di ripristino vengono registrati in modo permanente se è stato infine completato o scaduto.