Quando, esattamente, i vecchi token di reimpostazione della password dovrebbero essere cancellati?

Question

Quando, esattamente, i vecchi token di reimpostazione della password dovrebbero essere cancellati?

#1 da (8 voti)
#2 da (0 voti)

8

Sto cercando di capire le best practice per lavorare con i token di reimpostazione della password.

Supponiamo che un utente avvii il processo di reimpostazione della password e che venga inviato via email il token di ripristino e che archiviamo una copia con hash nel database. Il token è timbrato nel nostro DB e verrà considerato scaduto, diciamo, per 24 ore.

Consideriamo ora due scenari per ciò che potrebbe accadere dopo:

1) L'utente pensa di non aver ricevuto l'e-mail, prova a reimpostare di nuovo. Dovremmo permettergli di generare un altro token? Se lo facciamo, dovremmo eliminare immediatamente il vecchio token? (Saranno tutti invalidi da 24 ore dopo il rilascio di datetime comunque ...) Penso che ridurrebbe al minimo le chiamate di supporto se consentiremo un po 'di flessibilità purché scadano comunque. C'è un tipo di attacco che non sto considerando qui?

2) L'utente ha ricevuto l'e-mail e fa clic sul link di ripristino ma non completa il modulo di ripristino. Quando dovrei cancellare il token di reset? Solo dopo un reset corretto, l'utente può fare clic sul collegamento più e più volte durante le 24 ore e diventa non valido una volta reimpostata la password. O devo cancellare il token non appena fa clic sul link per qualche problema di sicurezza? (tutto ciò si verifica prima della scadenza)

passwords defense

posta John 25.02.2013 - 21:28

fonte

2 risposte

0

Suggerirei di consentire all'utente di richiedere una reimpostazione della password una sola volta in modo da avere un solo token di reset alla volta.
Puoi sempre controllare se la posta è stata inviata con successo e solo allora memorizzare il token di reset nel database.
Se l'utente prova a farlo di nuovo (e un link di reset attivo è presente) avvisa l'utente dicendo che "il link di reset è già stato inviato".
Informazioni sull'eliminazione dei token password: devono essere eliminati immediatamente dopo che la password è stata ripristinata correttamente e non dopo aver fatto clic sul resto del link.
~~Una possibile alternativa consiste nel reimpostare la password dell'utente e aggiornarla nel DB. Invia una mail all'utente che notifica che "questa è la tua nuova password cambia immediatamente~~
Si noti che il processo di reimpostazione della password sarà sempre vulnerabile se la comunicazione e-mail non è criptata. Per tempo limitato l'URL di ripristino, puoi provare a ridurre a icona la finestra di attacco per un potenziale attacco.

risposta data 26.02.2013 - 08:07

fonte

Leggi altre domande sui tag passwords defense

Posso bloccare l'indirizzo IP vero usando l'intestazione X-Forwarded-For in IIS? Come utilizzare un Yubikey NEO (o qualsiasi scheda OpenPGP o GnuPG in generale) per firmare CSR X.509?

score 8 · Accepted Answer

Non dovresti resettare il token quando l'utente fa clic su di esso, perché l'utente potrebbe essere disturbato nel processo (ad esempio il suo gatto è saltato sulla tastiera - il mio lo fa su base troppo regolare).

(Due giorni fa stavo usando questo link - non per la reimpostazione della password, ma simile - che è stato disattivato non appena ho cliccato su di esso, e si è scoperto che la pagina dietro non era compatibile con Chrome. Quindi ho dovuto richiedere un nuovo collegamento, eseguire l'intera procedura ancora una volta e li ho maledetti per questo: quando si ha a che fare con le password, si vuole e si deve creare un alleato cooperativo dell'utente, e certamente non farlo arrabbiare. )

Quando la password viene effettivamente ripristinata, tutti i link di reimpostazione password in attesa devono essere disattivati. È più semplice se si consente solo un collegamento di ripristino alla volta; se l'utente richiede una reimpostazione della password mentre il link precedente è ancora valido, è sufficiente inviarlo di nuovo (eventualmente, resettare il contatore del timeout). Non è necessario supportare diversi link di reset della password distinti simultaneamente validi. Un link alla volta significa una struttura di database più semplice e quindi meno spazio per i bug.