I link per la reimpostazione della password non scadono il rischio di sicurezza?

Ad esempio: se ricordo la mia password, non reimpostarla.

Ora, se il mio account e-mail viene in seguito compromesso (o se visito il link e chiunque decide di esaminare la mia cronologia di navigazione), possono cambiare la mia password a volontà e non c'è modo che io possa impedirlo eccetto che cambia la mia password.

A meno che, ovviamente, intendessi che il token è valido solo per una visita in una pagina. Questo è sicuramente sicuro, ma anche scomodo se chiudo la pagina, la mia sessione scade, ecc.

Oltre agli scenari citati in altre risposte, il motivo principale per cui ho potuto vedere di avere scaduto il link per la reimpostazione della password è che il link potrebbe essere memorizzato nella cache o archiviato in una varietà di posizioni e ciò potrebbe (in determinate circostanze) consentire a qualcun altro di accedere all'account degli utenti.

• Cronologia del browser. Questo sembra molto probabilmente un rischio. L'utente reimposta una password da un PC condiviso, mi aspetto che il link entri nella cronologia del browser, quindi chiunque possa accedere a quel browser può reimpostare la password degli utenti e assumere il controllo dell'account.
• Memorizzato nella cache da un server proxy. Ovviamente se hai HTTPS, la maggior parte dei proxy non vedranno il collegamento in molte aziende, viene utilizzata l'intercettazione SSL, quindi i proxy inseriranno nella cache il link e anche IIRC alcuni operatori mobili fanno questo genere di cose nel nome del risparmio.
• Aggiunto ai preferiti. L'utente segue il link, pensa "questo è utile" lo aggiunge ai preferiti, ora chiunque usi quel browser ha accesso al proprio account. Non particolarmente probabile ma possibile.

Se questi scenari ti interessano dipenderanno dai tuoi casi d'uso e dal livello di sicurezza che stai cercando di fornire.

È corretto. La scadenza di questi token è molto più sicura poiché un utente malintenzionato con accesso al tuo database sarà in grado di ottenere questi token e utilizzarli per reimpostare gli utenti che richiedono la reimpostazione della password ma non completano la richiesta.

Dovrei anche menzionare: Trattare i token di reimpostazione della password come un segreto più grande delle password. Cioè, non li si memorizza in testo normale, li si genera, li si invia all'utente e lo si memorizza nel database. Ciò impedisce anche agli attaccanti con accesso in lettura di leggere e abusare dei token.

OWASP ha un ottimo cheat sheet per la reimpostazione della password , il loro argomento sul periodo di validità limitato è come @Jonathan Newmuis ha detto che:

[...] if the user doesn't get around to checking their email and their email account is later compromised, the random token used to reset the password would no longer be valid if the user never reset their password and the "reset password" token was discovered by an attacker. Of course, by all means, once a user's password has been reset, the randomly-generated token should no longer be valid.

Punto preso su come un compromesso dell'account e-mail che sta ricevendo il token nega alcuni dei benefici dello scadere del token. Continuo a pensare che la scadenza del token abbia qualche valore, secondo Jonathan Newmuis.

Scenario:

1. Richiedo un reset per il mio account su ACME, che viene inviato via email alla mia casella di posta presso Big Kahuna Corp.
2. Ricordo la mia password ACME e non uso il token di reset.
3. Qualche tempo dopo, passo a Gmail, ma lascio il mio account Big Kahuna in giro.
4. Qualche tempo dopo, la mia cassetta postale Big Kahuna è stata compromessa.

Scenario A: Nessuna scadenza

5 ter. L'utente malintenzionato trova il token di ripristino ACME e lo utilizza per compromettere il mio account ACME.

Secnario B: Scadenza dopo N giorni

5 ter. L'utente malintenzionato trova il token di ripristino ACME che è scaduto , ma ora sa che ho un account ACME. Emette nuovamente il token di ripristino ACME e, poiché sono passato a Gmail (e modificato di conseguenza il mio indirizzo di ripristino sul sito Web ACME), il token di ripristino viene inviato a Gmail, impedendo una violazione e che mi indicano che sono sotto attacco.

Sì, l'esempio è inventato, ma completamente plausibile.

Forse una buona via di mezzo è quella di avere un elenco di token di ripristino "correntemente validi" che l'utente è mostrato al login e ha la possibilità di revocarli.

Il problema più grande è che non si desidera memorizzare il token di reimpostazione della password nel database in testo non crittografato. Questo produce una scorciatoia, dove l'attaccante non deve craccare l'hash della password, può semplicemente resettare la password. Memorizzare un hash del token di reimpostazione della password è una buona soluzione a questo problema.

È una buona idea che il token di reimpostazione della password scada e che sia utilizzato solo una volta. Tuttavia, questo non è un grosso problema come la memorizzazione di questi token nel testo normale. Il motivo principale per cui il token è scaduto è rendere più difficile per l'utente malintenzionato indovinare questo valore. Se l'utente malintenzionato ha accesso alla posta elettronica dell'utente, può semplicemente inviare un altro token, che è un punto controverso.

Posso pensare ad alcuni motivi per limitare la validità:

1. Difesa in profondità: stai fornendo un token sensibile e prezioso, poiché questo token può essere utilizzato per accedere a un account. Non sai esattamente cosa l'utente sta per fare con il link - cosa fa il loro provider di posta elettronica; cosa fanno i proxy Web con i link visitati; se si tratta di un account e-mail di gruppo o di un singolo account, ecc. (altri risponditori hanno fornito vari scenari). Limita la validità del token per limitare il danno potenziale.

2. Attacchi di enumerazione: se riesco a generare un token (ad esempio facendo clic sul pulsante "password dimenticata"), anche se non riesco ad accedere a quel token, posso provare per enumerarlo. Limitando la validità del token, limiti la quantità di tempo che devo indovinare correttamente.

La scadenza offre una protezione aggiuntiva ma, come si fa notare nei commenti, un utente malintenzionato che ha accesso all'account e-mail può semplicemente richiedere un nuovo token. Non importa se l'utente legittimo non accede più all'account di posta elettronica (come menzionato da OWASP), l'utente malintenzionato lo fa!

Un approccio molto migliore è chiedere all'utente alcune informazioni aggiuntive durante la fase di validazione del token, informazioni che non vengono mai inviate via e-mail. Ad esempio "qual è il nome da nubile di tua madre".

In alternativa puoi chiedere all'utente queste informazioni durante la fase "richiedi una nuova password" e poi impostare una variabile cookie / sessione a tempo limitato che indica che le informazioni sono corrette. Quando l'utente fa clic sul collegamento nell'e-mail, controlla anche questo cookie. In un certo senso è un po 'meno sicuro perché se l'utente malintenzionato ha accesso al browser (o ai cookie) può comunque reimpostare la password se è abbastanza veloce. Tuttavia, questa strategia ha il vantaggio di impedire la posta indesiderata, in quanto l'utente deve verificare se stesso prima ancora di inviare l'e-mail di ripristino.