Quali problemi ha questa procedura di "recupero account"?

Nel complesso, ciò sembra ragionevole per un sito medio. Suggerirei alcune modifiche minori:

• Personalmente, vorrei prendere in considerazione la rimozione della domanda segreta. Non penso che le domande di sicurezza aggiungano molta sicurezza; ma sono un altro segreto che l'utente può dimenticare o sbagliare, quindi le domande di sicurezza hanno un costo reale per l'esperienza dell'utente. C'è stata una ricerca accademica che suggerisce che le risposte a domande segrete hanno una bassa entropia e che possono essere ricercate con la stessa facilità con cui le password possono essere scaricate. Pertanto, penso che rimuovere la domanda segreta migliorerà l'usabilità e non avrà molto effetto sulla sicurezza. In effetti, la sicurezza del sistema diventa dipendente dall'indirizzo email dell'utente. Il principale rischio che la domanda segreta affronta è quello in cui l'utente chiude il proprio account e-mail, quindi qualcun altro registra la stessa e-mail ed è in grado di indovinare il nome utente dell'utente; o dove l'account e-mail dell'utente viene dirottato; o dove l'utente condivide il suo account e-mail con altre persone.

• Aggiungerei un indicatore di forza della password alla pagina in cui l'utente sceglie la sua password. Scopri quali siti come Google usano, dove c'è una barra che indica in modo dinamico la forza della password e che cambia i colori (rosso = Scarso, giallo = Borderline, verde = Buono). Ciò potrebbe indurre / aiutare gli utenti a scegliere password migliori. Probabilmente non hai bisogno di imporre requisiti minimi di forza - questo potrebbe fornire una spinta sufficiente.

• Renderei il codice di ripristino limitato nel tempo, in modo che debba essere usato entro (diciamo) un'ora o due, e quindi non è più accettato dopo la fine del periodo di validità. Inoltre, il link dovrebbe scadere immediatamente al primo utilizzo (grazie, @AviD, per segnalarlo).

• Utilizza SSL / TLS (ad esempio, HTTPS) per tutte le attività relative alla scelta / impostazione / invio della password dell'utente. Questo proteggerà contro l'intercettazione della password per gli utenti che accedono al tuo sito tramite una rete wireless aperta; tuttavia, non protegge da Firesheep. Prendi in considerazione l'adozione di SSL / TLS in tutto il sito, che proteggerà da Firesheep.

(presumo che tu non abbia esigenze di sicurezza particolarmente delicate: ad esempio, non è per l'online banking o simili.)

Come al solito - dipende dalla natura di ciò che stai proteggendo. Sembra abbastanza decente per le informazioni di base. Potrebbe essere necessario altro se stai scrivendo il codice per qualcosa di high-end, come il web banking.

Ogni volta che vengono usate domande / risposte segrete, la risposta finisce per prendere il posto di una password da qualche parte, ed è facile che questo sia il tuo anello più debole. Dal momento che le risposte segrete possono facilmente essere le cose che un utente malintenzionato potrebbe scoprire con Google, possono essere un vero fattore di rischio - ed è difficile seguire la linea di domande così insolite che non sono relativamente facili da capire e porre domande che sono così esoterici o non applicabili che il proprietario dell'account non può rispondere.

Mi piace l'idea di Iszi di lasciare che la persona scriva il proprio Q & Un set - che aggira il problema in modo appropriato.

Nel caso in cui menzioni se un utente malintenzionato può intercettare l'email proveniente dal tuo sistema, allora non ha bisogno dell'account dell'utente. Ciò significa che la più grande linea di difesa è quella segreta condivisa.

Non hai detto, ma presumo che tutta la configurazione dell'account e la reimpostazione della password avvengano con la protezione SSL / TLS, giusto? Altrimenti, questo sarebbe probabilmente il problema più grande.