2013-09-22 6 views
5

Sto tentando di realizzare un "ricordati di me" di utilità utilizzando il sistema delineato qui: Improved persistent login cookieImplementazione ricordati di me con token e serie su più dispositivi

Tuttavia, v'è un problema con la logica qui per me e stavo chiedendo se chiunque può chiarirlo per me.

  • A un utente viene assegnato un ID di sessione. Questa è una stringa generata in modo casuale ed è persistente per tutta la durata dell'account dell'utente.

  • A un utente viene assegnato un ID token. Questa è una stringa generata in modo casuale e viene ricreato ogni volta che l'utente accede con successo.

Entrambi questi valori sono memorizzati i cookie firmati sulla macchina dell'utente e del database.

L'idea è che se qualcuno riesce a falsificare il token dell'utente e la serie e il log-in come utente, genererà un nuovo ID token. La volta successiva che l'utente legittimo tenta di accedere, avrà una serie corrispondente ma un token non valido, notificando così al sistema che è stata commessa una violazione della sicurezza e che è possibile intraprendere qualsiasi azione necessaria (cancellando il token dell'utente).

Questo è fantastico. Tuttavia cosa succede quando un utente tenta di utilizzare la mia applicazione da più dispositivi o browser? Dì che un utente accede al mio servizio con Chrome e controlla se mi ricorda. La prossima volta che accedono tramite Firefox e seleziona anche me. Un nuovo token sarà stato generato in modo che la prossima volta che l'utente tenti di accedere con Chrome venga attivato un falso furto - no?

Se questo è il caso, come posso implementare questa soluzione in modo più affidabile? Sono ben consapevole del fatto che l'autorizzazione basata sui cookie è per sua stessa natura meno sicura e non consentirebbe a un utente autorizzato di cookie di eseguire azioni dannose come gli acquisti.

risposta

4

Il post originale che il "Improved persistente login cookie" si riferisce, (trovato qui: http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/) afferma:

Il cookie dovrebbe consistere username dell'utente, seguito da un carattere separatore, seguito da alcuni grande numero casuale (128 bit sembra abbastanza impressionante da essere accettabile). Il server mantiene una tabella di numeri-> associazioni di nomi utente, che è cercato per verificare la validità del cookie. Se il cookie fornisce un numero casuale e il nome utente mappati l'uno con l'altro nella tabella, l'accesso è accettato.

In qualsiasi momento, un nome utente può associare a diversi tali numeri

Così, l'utente può avere molti gettoni persistenti allo stesso tempo.

+1

Grazie questo ha senso ora. Avrò un mucchio di token e darò loro una scadenza di 30 giorni in caso di mancato utilizzo, quindi non riempirò il database con dati ridondanti. –

Problemi correlati