Sto costruendo una nuova app MVC.
Considerando questo flusso "password dimenticata":
1) Immetti un'email.
2) Premi "invia password di ripristino".
3) Una email attende nella casella di posta, premendo il link in essa porta alla schermata "nuova password".
Nella fase 1, non ci sono limiti sull'e-mail che fornisci. (Potrebbe anche non esistere).
Ci sono grossi problemi di sicurezza con questo flusso?
È possibile. Non è immediatamente chiaro se si sta facendo affidamento sull'indirizzo e-mail come unico identificatore (cioè lo si sta usando come nome utente) o se è in gioco un nome utente separato. In quest'ultimo caso, il difetto evidente è che un utente malintenzionato può fornire il nome utente di qualcun altro, ma fornire il proprio indirizzo email come destinazione per la password di ripristino.
Supponendo che l'indirizzo email sia l'unico identificativo per un utente, ovviamente dovrà essere fornito da questi per reimpostare la password. Suggerirei che indipendentemente dal fatto che esista effettivamente un account associato a quell'indirizzo email, il sistema dovrebbe rispondere in modo simile. (Ad esempio, "Le informazioni per il recupero della password sono state inviate"). Tuttavia, ovviamente, si desidera inviare l'e-mail di recupero solo se è presente un account corrispondente; se non esiste un account di questo tipo, non c'è nulla da recuperare. Ciò impedisce a un utente malintenzionato di provare più indirizzi per vedere quali utenti riescono e quali non riescono e quindi crea un elenco di account validi sul sistema. (Se la tua applicazione è più veloce per rispondere se non ha bisogno di inviare l'e-mail, potresti voler aggiungere intenzionalmente un po 'di ritardo temporale per nasconderlo.)
Ci sono alcuni potenziali problemi significativi, per lo più legati ad aspetti della tua procedura che non sono stati specificati (quindi "potenziali"). Queste sono considerazioni aggiuntive, piuttosto che problemi con il tuo metodo:
I robot automatici possono inviare spam agli utenti inviando un sacco di indirizzi email diversi. L'invio tramite e-mail (o almeno la risposta allo stesso modulo), indipendentemente dal fatto che un utente sia valido o meno, è un buon modo di prevenire l'enumerazione dei nomi utente, ma ti apre a questo rischio. Prendi in considerazione l'utilizzo di un CAPTCHA quando gli utenti richiedono l'email di ripristino per impedire l'invio automatico.
Il valore segreto incorporato nel link potrebbe essere troppo facile da indovinare. Se il token incluso nel link non viene generato casualmente con un alto livello di entropia, un utente malintenzionato potrebbe essere in grado per indovinarlo.
Il valore segreto potrebbe essere riutilizzato da un utente malintenzionato se l'e-mail è compromessa in un secondo momento. Il token dovrebbe essere monouso (cioè un nonce) e scadrà idealmente dopo un determinato periodo di tempo (appropriato per la base utente e i requisiti di sicurezza - OWASP consiglia un minimo di 20 minuti qui , ma potresti considerare la tua applicazione non troppo sensibile).
Il valore segreto potrebbe essere intercettato. l'email non dispone della crittografia end-to-end e non sai quanto siano sicuri gli endpoint oi server di posta dell'utente. Alcune applicazioni richiedono quindi ulteriori passaggi di verifica prima o dopo l'invio e il successivo collegamento. OWASP consiglia le domande segrete in addizionale all'e-mail, sebbene potresti ritenere che ciò sia eccessivo per la sensibilità della tua applicazione.
La nuova password non viene inviata con sicurezza di trasporto. Naturalmente l'URL nella tua email dovrebbe puntare a una pagina HTTPS (parzialmente così l'utente può verificare che sta inviando direttamente la nuova password al server), quindi il modulo deve inviare la password anche su HTTPS.
Un utente malintenzionato richiede un'e-mail di ripristino per conto di un utente e l'utente non è in grado di impedire che il token rimanga attivo. Prendi in considerazione la possibilità per gli utenti di annullare la reimpostazione della password dal email, consentendo loro di disattivare il collegamento se non lo richiedevano.
L'utente non riceve alcuna notifica se un utente malintenzionato riesce a modificare la sua password. Considera almeno di informare l'utente via e-mail di ogni reimpostazione corretta della password, nel caso in cui non sia stata avviata da essi.
Penso sia importante verificare che gli indirizzi email inseriti appartengano effettivamente a uno dei tuoi utenti prima di inviare l'e-mail di recupero. Supponendo che il tuo modulo di iscrizione raccolga già indirizzi email, sarebbe sciocco non usarli per eseguire questo semplice controllo.
Senza verifiche, una delle principali preoccupazioni sarebbe rappresentata dagli spammer / hacker che immettono tonnellate di indirizzi email inventati e non validi. Ciò farebbe sì che il server invii molti messaggi che rimbalzano e attira l'attenzione da filtri spam e database di spammer. Alla fine, il tuo server potrebbe essere messo in blacklist e nessuna email proveniente dal tuo sito andrebbe più passata.
Inoltre, gli indirizzi email errati sono abbastanza comuni, quindi potresti avere istanze in cui un utente invia per errore un'email di recupero alla posta in arrivo di qualcun altro.
Senza ulteriori informazioni sulla tua implementazione, non posso davvero segnalare altri problemi, ma nella fase 3, ci sono alcune misure di sicurezza aggiuntive che puoi prendere in considerazione. Ad esempio, devi assicurarti che gli URL di ripristino siano lunghi e casuali, in modo che non possano essere facilmente indovinati o forzati. Probabilmente anche tu non vuoi che gli URL siano attivi per sempre; è una buona idea espirarli dopo un'ora o due se un utente genera un URL di ripristino ma non lo visita mai, o se l'utente lo visita ma non fornisce mai una nuova password. Per ridurre ulteriormente la possibilità di un hack, è possibile disabilitare completamente la funzionalità di recupero della password se l'account è stato utilizzato nei giorni scorsi, o se la posizione basata su IP è atipica per quell'utente (sebbene queste misure possano arrecare disturbo agli utenti). / p>
Gli spammer potrebbero falsificare la tua e-mail di reimpostazione della password e indurre altri utenti a fare clic su un link che consente di ottenere informazioni
Inviando il modulo rapidamente, il tuo server potrebbe non essere in grado di tenere il passo con la potenza di elaborazione richiesta per l'invio di e-mail abbastanza veloce
Leggi altre domande sui tag passwords password-management