Stiamo implementando la reimpostazione automatica della password su un'applicazione web e so come voglio farlo (indirizzo e-mail con password limitata per reimpostare l'URL per gli utenti all'indirizzo e-mail pre-registrato).
Il mio problema è che non riesco a trovare riferimenti per indicare agli sviluppatori di usare quella tecnica. Qualcuno può indicarmi delle buone referenze su questa tecnica?
Alcuni suggerimenti:
Non reimpostare la password dell'utente fino alla conferma. Non reimpostare immediatamente la password dell'utente. Ripristinalo solo quando l'utente fa clic su un link di conferma inviato al suo indirizzo email pre-registrato.
Richiedi un CAPTCHA. Quando un utente richiede che la sua password sia ripristinata, costringila a risolvere un CAPTCHA prima di procedere oltre. Questo per impedire che strumenti automatizzati provochino dolore a molti utenti e costringano l'utente a dimostrare di essere un essere umano (non un robot).
Casualità. L'URL di reimpostazione della password a tempo limitato dovrebbe includere un componente casuale non accessibile. Assicurati di utilizzare la casualità di cripto-qualità. L'output da /dev/urandom o System.Security.Cryptography.RNGCryptoServiceProvider sarebbe una buona scelta. L'output da rand() o random() o System.Random non è abbastanza casuale e sarebbe una scelta sbagliata. Un GUID o timestamp non è casuale abbastanza e non sarebbe una buona scelta.
Includi un limite di tempo. Il link di conferma del ripristino dovrebbe scadere dopo un tempo ragionevole: ad esempio, 24 ore. Il link dovrebbe essere utilizzabile solo una volta e dovrebbe scadere immediatamente non appena viene utilizzato.
Includi il testo esplicativo nell'email. Potresti voler aggiungere del testo esplicativo all'e-mail, per spiegare perché l'email è stata inviata, nel caso qualcuno richieda un reset per un account che non è il tuo proprio. Potresti includere del testo come "Qualcuno ha richiesto che la password venga ripristinata per il tuo account username su site . Se hai fatto questa richiesta, clicca qui per cambiare la tua password. Se non hai fatto questa richiesta, clicca qui per annullare la richiesta. "
Invia email dopo aver reimpostato la password. Una volta ripristinata la password, invia un'email all'utente per far sapere che la password è stata modificata. Non includere la nuova password in quell'email.
Annullamenti del monitoraggio. Potresti prendere in considerazione l'inclusione di una logica per monitorare la frequenza con cui gli utenti fanno clic sul link di cancellazione indicando che non hanno richiesto il ripristino. Se questo supera una certa soglia, potrebbe essere utile inviare un avviso agli operatori di sistema. Inoltre, se un link di cancellazione per qualche richiesta viene visitato dopo viene visualizzato il link di conferma, si tratta di una potenziale indicazione di un attacco contro quell'utente: potresti voler agire in quel momento, ad esempio invalidare la password dell'utente e chiedergli di reimpostare nuovamente la password. (Questa è una difesa contro il seguente attacco: l'attaccante ottiene l'accesso alla cassetta postale dell'utente, quindi richiede che la propria password sul sito venga ripristinata, quindi visita il link di conferma.) Se l'utente malintenzionato non cancella queste e-mail dalla posta in arrivo dell'utente, quindi, quando l'utente reale legge la sua email, può fare clic sul link di cancellazione, fornendo un'indicazione di possibili problemi.)
Utilizza HTTPS. Il link dovrebbe utilizzare https (non http :), per proteggere da vari attacchi (ad es. attacchi di Firesheep agli utenti che navigano sul Web da un Internet cafe).
Registra queste operazioni. Suggerisco di registrare tutte queste richieste. Oltre a registrare il nome utente dell'utente, è possibile che si desideri registrare l'indirizzo IP del client che ha richiesto l'invio di un link di reset all'utente, nonché l'indirizzo IP del client che ha visitato il link di ripristino.
Letture aggiuntive. Puoi anche leggere l'eccellente post sul blog di Troy Hunt, Tutto ciò che avresti sempre voluto sapere sulla creazione di una funzione di reimpostazione della password sicura . Grazie a @coryT per un link a questa risorsa.
Infine, considera l'autenticazione non-password. Le password hanno molti problemi come meccanismo di autenticazione e potresti prendere in considerazione altri metodi di autenticazione degli utenti, come la memorizzazione di un cookie persistente sicuro sulla loro macchina con un non accessibile segreto per autenticarli In questo modo, non vi è alcuna password da dimenticare e nessun modo per l'utente di essere phishing, anche se è necessario fornire un modo per un utente di autorizzare l'accesso da una nuova macchina o un nuovo browser (possibilmente via e-mail al indirizzo email registrato). Questo documento di indagine ha un'indagine eccellente su molti metodi di autenticazione di riserva e sui loro pregi e difetti.
Troy Hunt ha scritto molto bene su questa domanda esatta. Tutto ciò che avresti sempre voluto sapere sulla creazione di una funzione di reimpostazione sicura della password
OK, quindi la tua domanda è, come dovresti strutturare la password / il processo di recupero dell'account? Ciò dipenderà da ciò che desideri ottimizzare: esperienza utente senza problemi o buona sicurezza.
Se vuoi una buona sicurezza:
Durante la registrazione, l'utente deve immettere un canale secondario per l'autenticazione: numero di telefono cellulare o domanda di verifica & risposta (es. " qual è il nome da nubile di tua madre " o migliore).
Durante il recupero, il sistema ottiene prima una verifica approssimativa dell'identità tramite il canale secondario sopra riportato - la domanda di sfida o l'invio di un codice SMS al telefono cellulare o simili.
Quando il primo controllo dell'identità sopra è cancellato, il sistema invia una e-mail di reimpostazione della password all'indirizzo e-mail precedentemente inserito . Questa è una misura aggiuntiva importante per prevenire f.x. exploit tipo Sarah Palin .
L'e-mail non deve contenere una nuova password o simile. Dovrebbe avere un collegamento in grado di fare clic su una pagina Web crittografata HTTPS sul tuo sito che a) è collegato all'account tramite un valore segreto non immaginabile fornito nell'URL, b) è limitato nel tempo, quindi il recupero dell'account funziona solo per x ore dopo che è stato richiesto, c) fornisce un modo per l'utente finale di creare una nuova password.
Avere una buona registrazione su tutte le transazioni di resettaggio dell'account e fare in modo che un essere umano le controlli e agisca se appare sospetto (guarda i log del server per gli indirizzi IP fx, molte richieste provengono dallo stesso indirizzo IP , ci sono casi in cui un utente sta tentando di reimpostare le password da un paese diverso dal proprietario dell'account registrato ecc.)
Puoi anche aggirare questa complessità del tutto: È ancora presto, ma OAuth / OpenID / accedi tramite Facebook, Google ecc rimuove questa complessità interamente dai tuoi sistemi, ma con un forse usabilità meno consolidata .
Qualsiasi luogo che può inviarti una password significa che non ha hash la password, ma memorizzarla dove è in qualche modo decifrabile in "testo in chiaro". Questo di per sé è cattivo.
Probabilmente non è "il più" sicuro, ma più sicuro sarebbe:
Dopo la richiesta della password, invia un link per la reimpostazione della password all'utente con GUID incorporato. La sessione nel GUID scade tra, hmm, ora o giù di lì.
Un altro che può o non può essere appropriato per la tua applicazione, ma è usato nelle applicazioni di banking online e simili tipi di cose è quello di inviare metà del codice di reset via SMS a un telefono cellulare registrato. Dal punto di vista di un attaccante questo è un PITA completo in quanto richiede il compromesso di un paio di canali per poterlo rompere.
Il modo più sicuro per eseguire una reimpostazione della password consiste nel generare un token di ripristino unico e casuale unico di grandi dimensioni, con una data di scadenza, legata all'ID utente. Il token deve essere sottoposto a hash nel database, poiché un utente malintenzionato con accesso SQL potrebbe utilizzarlo per reimpostare le password arbitrarie dell'utente.
Un link di ripristino deve essere inviato all'indirizzo email, contenente il token di ripristino. Quando l'utente fa clic sul collegamento, l'hash del token deve essere trovato nel database e la data di scadenza è verificata per essere in futuro. Se queste condizioni sono soddisfatte, l'utente dovrebbe essere presentato con una schermata che permetta loro di digitare una nuova password.
L'intero processo deve essere eseguito su SSL, altrimenti un utente malintenzionato potrebbe annusare l'URL e reimpostare la password prima che l'utente lo faccia.
Alcuni altri suggerimenti:
Autenticazione a 2 fattori tramite SMS! 1 conosci il cliente e il loro numero di cellulare, invia loro un codice univoco da aggiungere al sito per convalidarlo :) :)
Fai qualche passo procedura. Ad esempio qualcosa come questo:
www.yourdomain.com/lostpassword?param_1=x;param_2=y
Una sola presa è al punto 3). I valori X e Y dovrebbero essere casuali, imprevedibili e collegati a questo particolare account. Dovrebbero anche essere utilizzati solo una volta e dovrebbero diventare obsoleti dopo un breve periodo di tempo (24 ore?). Memorizza entrambi i valori in una tabella dedicata con le colonne corrispondenti:
| some_id | user_id | X | Y | expire_time
Se un utente tenta di utilizzare il collegamento corretto, verifica se il tempo di scadenza non è rispettato e in caso contrario, permettigli di cambiare la password.
Leggi altre domande sui tag password-management web-application appsec