Richiede lo stesso ID sessione tramite tutti i passaggi del processo di reimpostazione della password

2

La nostra logica di reimpostazione della password funziona come segue:

  1. l'utente fa clic su "ha dimenticato la mia password" e inserisce l'indirizzo email dell'account
  2. La posta
  3. viene inviata con un token crittograficamente protetto e l'indirizzo email dell'account per cui è necessario ripristinare la pw.
  4. l'utente fa clic sul link e, se il token corrisponde, vede una casella per inserire una nuova password.

Ho letto che dovremmo richiedere che il sessionId corrisponda a tutto il processo.

È una cosa fattibile da richiedere? Ci sono "casi d'uso normale" in cui richiedere lo stesso ID di sessione non funzionerebbe? Potrebbe essere più appropriato l'indirizzo IP, ad es. per aggirare il problema seguente:

es. i primi due passaggi del browser A, ma quando fanno clic sul collegamento nell'e-mail, apre il browser B, quindi, il nuovo ID di sessione.

    
posta GWR 14.11.2015 - 23:43
fonte

3 risposte

2

EDIT - Due risposte di seguito.

Risposta originale

Potresti incorporare un altro ID nel link che riporta all'ID sessione originale.

Il requisito è che il link di posta elettronica, quando viene cliccato, venga avviato nello stesso browser o possa essere su un altro browser? Cosa succede se è su una macchina diversa? Ad esempio, cosa succede se reimposti la password dal mio telefono, quindi passa al mio computer o tablet, fai clic sul link nell'email e configuro una nuova password? Potrei farlo se voglio usare l'archivio delle password sul mio computer anche se ho avviato il mio telefono. Dal punto di vista della facilità d'uso, sembra che il link della password nell'e-mail e non l'ID della sessione dal browser originale sia importante.

Inoltre, se il link "Password dimenticata" è stato cliccato da un utente malintenzionato che sta tentando di ottenere la voce e si forza l'ID sessione a essere lo stesso, l'utente reale che riceve il link per la reimpostazione della password potrebbe sperimenta un DOS a seconda di come funziona il tuo sistema. Certamente, l'utente legittimo non può reimpostare la propria password con il collegamento fornito poiché l'ID sessione che ha generato la richiesta "Password dimenticata" risiede nel browser degli hacker.

Come sviluppatore di applicazioni, dovresti essere in grado di svolgere una delle seguenti operazioni:

  1. Riconoscere una seconda sessione avviata dal link di reimpostazione password come legittima e lasciarla passare.
  2. Elabora il link di ripristino e lo riporta al primo ID di sessione.

Tuttavia, penso davvero che il n. 2 sia sconsiderato dato che un utente malintenzionato potrebbe cliccare sul link Password dimenticata. Penso che la cosa migliore da fare sia usare la seconda sessione.

Per inciso, i sistemi più paranoici che ho visto costringono un nuovo login una volta che la password è stata resettata. Cioè, fai clic su "Password dimenticata", ricevi l'e-mail, fai clic sul link, reimposta la password, quindi ti viene presentata una nuova pagina di accesso che richiede di inserire il tuo nome utente e la nuova password (invece di essere loggato tranquillamente come conseguenza della reimpostazione della password).

Seconda risposta: chiarimento nei commenti alle domande

Sembra che tu ti interessi con l'articolo di OWASP a cui si fa riferimento. In questo caso, l'articolo consiglia di eseguire una sessione continua per la reimpostazione della password e utilizzare un canale OOB (Alternate or Out Of Band) per aumentare la probabilità che si parli con l'utente legittimo. In questo caso, l'utente avvia la procedura di reimpostazione della password, risponde correttamente alle domande di sicurezza, è bloccato dall'account , un codice PIN OOB viene inviato tramite SMS o e-mail (nota, non un link di ripristino), l'utente inserisce il codice PIN corretto, quindi può essere inserita una nuova password.

Questo non era ciò che la domanda originale conteneva. In questo caso, un collegamento per la reimpostazione della password è non da inviare e solo un codice PIN da visualizzare con un lettore di e-mail e inserito nello stesso flusso della sessione di reimpostazione della password. Saltare su un nuovo ID di sessione (anche se possibile) dovrebbe essere visto come un attacco o un bug di sistema e rifiutato.

    
risposta data 15.11.2015 - 00:41
fonte
2

Devo davvero essere in disaccordo con le altre risposte, quando rispondo alla domanda come richiesto.

In primo luogo, supponiamo che l'utente malintenzionato conosca il tuo indirizzo email e abbia un modo di leggere un'email di ripristino inviata a te.

Se l'utente malintenzionato può leggere l'e-mail che ti è stata inviata, quasi sicuramente sa qual è il tuo indirizzo email. Hai anche detto che tutto ciò di cui ha bisogno per generare l'e-mail di reimpostazione della password è la tua e-mail (che abbiamo appena detto che ha.)

Questo significa che:

  • Non può leggere la tua email, quindi il token di reimpostazione della password è al sicuro da lui (quindi non è necessario che sia la stessa sessione)
  • Può leggere la tua email e probabilmente conosce il tuo indirizzo. Ciò significa che può facilmente fare clic sul link per la reimpostazione della password e generare una nuova password.

Ora ci sono casi d'angolo:

  • L'autore dell'attacco ritiene che la seconda email possa rivelare al proprietario dell'account che l'account è compromesso e che non può eliminare la posta dalla posta in arrivo
  • L'utente malintenzionato può in qualche modo leggere l'email senza conoscere effettivamente il tuo indirizzo email

In generale, penso che questi casi siano piuttosto improbabili e molto meno importanti del problema dell'usabilità. Ecco tre esempi:

  • Sto navigando sul mio tablet, ma dimentico la mia password. Faccio clic su "Password dimenticata" e poi uso l'e-mail sul mio desktop. Ora il recupero della password non è riuscito. Spero che tu abbia un messaggio di errore veramente buono, o penserò che il tuo sito sia rotto.
  • Sto navigando su Chrome e fai clic su "Password dimenticata". Alt-tab su un altro browser in cui sono connesso all'altro account di posta elettronica a cui è legato questo account. Faccio clic sul link di ripristino e di nuovo non è riuscito.
  • Sono in una scheda privata e fai clic su Password dimenticata. Vedo il messaggio nel mio client di posta elettronica e clicco sul link, aprendo il collegamento con il browser predefinito di sistema. Di nuovo, fallimento.

Penso che i problemi di UX siano molto più importanti di qualsiasi piccolo miglioramento della sicurezza che potresti ottenere richiedendolo.

Dove questo potrebbe essere più utile è se "Password dimenticata" richiede più di un'e-mail. Se si invia l'e-mail di ripristino è necessario rispondere a una domanda di sicurezza, quindi potrebbe essere effettivamente utile. Altrimenti probabilmente è solo fastidioso.

    
risposta data 20.03.2016 - 06:34
fonte
1

Come per la maggior parte degli articoli di OWASP, il ragionamento su alcuni dei passaggi di implementazione suggeriti non viene sempre spiegato, lasciando ai lettori indovinare quali sono i vantaggi e i rischi di non tenere conto di ogni raccomandazione. Alcuni di essi possono essere tranquillamente ignorati, mentre altri sono fondamentali per mitigare il rischio originale. Ti suggerisco di utilizzare sempre OWASP come un buon punto di partenza e poi cercare di capire se l'intera soluzione è effettivamente necessaria (come hai già fatto).

Is that a feasible thing to require? Are there any "normal use cases" where requiring the same session id would not work?

Ignorando l'implementazione nell'articolo OWASP e parlando in generale dei meccanismi di reimpostazione della password, il requisito di consentire solo i ripristini dalla stessa sessione impedisce che un token di reimpostazione della password inviato tramite e-mail venga intercettato e utilizzato da un intercettatore di e-mail. Supponiamo che un utente malintenzionato abbia impostato una regola di inoltro della posta in modo da ottenere una copia di ogni e-mail inviata a un account. Si noti che questo si applica solo se è associato a domande di sicurezza (che hanno i loro problemi). In caso contrario, un utente malintenzionato potrebbe semplicemente richiedere il ripristino direttamente, quindi seguire il collegamento dalla propria sessione.

Funzionerebbe anche per i token di ripristino SMS, in cui un utente malintenzionato era riuscito a trasferire malware sul telefono della vittima per leggere i messaggi o era riuscito a clonare la propria SIM per ricevere SMS indirizzati alla vittima.

Non funzionerebbe per alcuni meccanismi di reimpostazione della password non associati, come l'invio di un token di ripristino tramite posta ordinaria a meno che questo identificativo di sessione non venga mantenuto per un lungo periodo di tempo (questo potrebbe essere ottenuto in modo sicuro tramite un token cookie aggiuntivo , non correlato alla sessione effettiva registrata).

Alla fine della giornata, la decisione di utilizzare un tale meccanismo dipende dalla propensione al rischio del tuo sito e dal suo "livello di sicurezza". In sostanza, richiede lo stesso identico browser per completare il processo di reimpostazione della password (attualizzazione della sessione di sconto o attacchi di furto di sessioni). Ha delle limitazioni, come non permettere che un roken di reset attivato da un browser mobile venga attivato su un PC. In tal caso, la restrizione potrebbe essere allentata per richiedere lo stesso IP, tuttavia non offre alcuna protezione quando l'utente malintenzionato si trova sulla stessa rete o nel caso in cui siano in uso proxy ISP condivisi (ad es. AOL, 3 / 4G provider).

    
risposta data 21.11.2015 - 14:53
fonte

Leggi altre domande sui tag