it-swarm.dev

I collegamenti per la reimpostazione della password che non scadono rappresentano un rischio per la sicurezza?

Attualmente sto lavorando su un flusso di reimpostazione della password. Abbiamo deciso di utilizzare un collegamento per reimpostare la password che viene inviato tramite e-mail all'indirizzo e-mail registrato dell'utente e che consente loro di seguirlo e inserire una nuova password di propria scelta.

L'attuale implementazione che abbiamo in mente fornisce un token monouso ma non una funzionalità di timeout. Attualmente la ricerca che ho fatto sulla questione sembra suggerire che la scadenza di questi token è in qualche modo più sicura che no. Tuttavia, le persone non hanno citato il perché.

Qualcuno può fornire un caso d'uso in cui quel token (pur continuando a essere usato una volta) che non scade sarebbe dannoso per la sicurezza?

Dettagli aggiuntivi: Sono ben consapevole che l'invio di un collegamento di reimpostazione della password non è il modo più sicuro per gestire questo problema. Idealmente, non vorremmo offuscare questa sicurezza al provider di posta elettronica. Tuttavia, abbiamo preso la decisione di scegliere un collegamento per reimpostare la password. Stiamo solo cercando di determinare se vogliamo che scada o meno. Per maggiori informazioni in merito:

http://www.fishnetsecurity.com/sites/default/files/media/10WP0003_BestPractices_SecureForgotPassword%5B1%5D_0.pdf

24
Austin DeVinney

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

Ora, se il mio account e-mail viene successivamente compromesso (o se visito il link e qualcuno decide di esaminare la mia cronologia di navigazione), possono cambiare la mia password a piacimento e non c'è modo di impedirlo se non per cambiare il mio propria password.

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

14
Jon Newmuis

Oltre agli scenari che sono stati menzionati in altre risposte, il motivo principale che ho potuto vedere per la scadenza dei collegamenti di reimpostazione della password è che il collegamento potrebbe essere memorizzato nella cache o archiviato in una varietà di posizioni e che (in determinate circostanze) potrebbe consentire a qualcun altro per 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 acceda alla cronologia del browser, quindi chiunque possa accedere a quel browser può reimpostare la password dell'utente e assumere il controllo dell'account.
  • Memorizzato nella cache da un server proxy. Ovviamente se hai HTTPS, la maggior parte dei proxy non vedrà il collegamento, tuttavia in molte aziende, viene utilizzata l'intercettazione SSL, quindi quei proxy memorizzeranno nella cache il collegamento e anche IIRC alcuni operatori mobili fanno questo tipo di cose in nome del risparmio sui costi.
  • Aggiunto ai preferiti. L'utente segue il collegamento, pensa che "questo è utile" lo aggiunge ai preferiti, ora chiunque utilizzi quel browser ha accesso al proprio account. Non particolarmente probabile ma possibile.

Se questi scenari contano per te dipenderà dai tuoi casi d'uso e dal livello di sicurezza che stai cercando di fornire.

12
Rory McCune

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

Dovrei anche menzionare: i token di reimpostazione della password sono un segreto grande quanto le password. Cioè, non li memorizzi in testo normale, li generi, li invii all'utente e li memorizzi con hash nel tuo database. Ciò impedisce anche agli aggressori con accesso in lettura di leggere e abusare dei token.

6
Madara's Ghost

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:

[...] se l'utente non riesce a controllare la propria e-mail e il suo account e-mail viene successivamente compromesso, il token casuale utilizzato per reimpostare la password non sarebbe più valido se l'utente non reimposta mai la propria password e la "reimposta password "il token è stato scoperto da un utente malintenzionato. Ovviamente, una volta ripristinata la password di un utente, il token generato casualmente non dovrebbe più essere valido.

6
null

Punto preso in considerazione su come un compromesso dell'account e-mail che sta ricevendo il token nega alcuni dei vantaggi della scadenza del token. Penso ancora che la scadenza dei token abbia un certo valore, per Jonathan Newmuis.

Scenario:

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

Scenario A: nessuna scadenza

5b. L'attaccante trova il token di ripristino ACME e lo utilizza per compromettere il mio account ACME.

Secnario B: Scadenza dopo N giorni

5b. L'attaccante trova il token di ripristino ACME che è scaduto , ma ora sa che ho un account ACME. Emette nuovamente il token di reimpostazione ACME e, poiché ho modificato Gmail (e modificato di conseguenza il mio indirizzo di reimpostazione sul sito Web ACME), il token di reimpostazione passa a Gmail, impedendo una violazione e che mi indica che sono sotto attacco.

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

Forse una buona via di mezzo è avere un elenco di token di reimpostazione "attualmente validi" che l'utente viene mostrato al momento del login e che ha la possibilità di revocarli.

5
scuzzy-delta

Il problema più grande è che non si desidera archiviare il token di reimpostazione della password nel database in chiaro. Questo produce un collegamento, in cui l'attaccante non deve decifrare l'hash della password, può semplicemente reimpostare la password. La memorizzazione di 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 venga utilizzato solo una volta. Tuttavia, questo non è un grosso problema quanto la memorizzazione di questi token in testo semplice. Il motivo principale per far scadere il token è rendere più difficile per l'attaccante indovinare questo valore. Se l'attaccante ha accesso all'email dell'utente, può semplicemente inviare un altro token, che è un punto controverso.

4
rook

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 ottenere l'accesso a un account. Non sai esattamente cosa farà l'utente con il link - cosa fa il suo provider di posta elettronica; cosa fanno i proxy web con i link visitati; se si tratta di un account di posta elettronica di gruppo rispetto a un account individuale ecc. (Altri rispondenti hanno fornito vari scenari). Limitare la validità del token per limitare il danno potenziale.

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

1
Manish

La scadenza offre una protezione aggiuntiva ma, come sottolineato 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 e-mail (come menzionato da OWASP), l'attaccante lo fa!

Un approccio molto migliore consiste nel chiedere all'utente ulteriori informazioni durante la fase di token di convalida, 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 di "richiesta di collegamento di una nuova password" e quindi impostare una variabile cookie/sessione a tempo limitato che indichi che le informazioni sono corrette. Quando l'utente fa clic sul collegamento nell'e-mail, controlli anche questo cookie. In un certo senso è un po 'meno sicuro perché se l'attaccante ha accesso al browser (o ai cookie) può comunque reimpostare la password se è abbastanza veloce. Tuttavia, questa strategia ha il vantaggio di prevenire e-mail indesiderate, in quanto l'utente deve verificarsi prima ancora di inviare l'e-mail di reimpostazione.

0
user78220