Variabili di sessione basate sui cookie

3

Ho una situazione in cui non posso utilizzare una sessione lato server, ma devo consentire agli utenti di accedere e che lo stato di accesso è persistente tra le query.

Come per qualsiasi altra cosa che coinvolge la crittografia di qualsiasi tipo, so quanto sia facile commettere un errore e volevo solo alcune coppie di occhi in più per esaminare ciò che sto proponendo.

u = the unique, numerical user id
s = a global server-side secret composed of a long, random, alpha-numeric string,  64 characters or more

Al momento dell'accesso, propongo di impostare due cookie sul client.

  1. L'ID utente: u
  2. Il token di autenticazione: hash (u + s)

Su richieste successive, il server utilizzerà il valore dato di u e il valore segreto noto di s per calcolare e confrontare il token di autenticazione indicato. Se corrispondono, questo deve essere un utente valido, giusto?

Un utente malintenzionato non può generare un token di autenticazione senza conoscere il segreto e quindi non può generare un token per l'account utente di qualcun altro.

Se faccio in modo che i cookie abbiano una durata relativamente breve, forse un'ora, e forniscano funzionalità di logout che distruggono i cookie, anche i computer condivisi sarebbero relativamente sicuri.

Il segreto globale s potrebbe essere modificato (forse da un cron-job giornaliero) per proteggersi da una forza bruta a lungo termine su una coppia hash / userID nota.

Suona bene?

Modifica

Nel rileggerlo di nuovo, mi rendo conto che l'introduzione di un timestamp sarebbe molto utile. Quindi un terzo cookie con il timestamp e l'hash dovrebbero includere il timestamp, l'userID e il segreto. Quindi un TTL potrebbe essere impostato sul token di autenticazione e la scadenza del cookie (che comunque non è un metodo di revoca sicuro a distanza) non avrebbe più importanza.

    
posta 24.04.2012 - 23:49
fonte

1 risposta

4

La tua idea di base sembra valida, ma ti consiglio di utilizzare HMAC anziché un semplice hash. Quindi il cookie inviato al client conterrà tre valori:

  1. ID utente u ,
  2. timestamp t e
  3. token di autenticazione HMAC ( s ; [ u , t ]),

dove s è la chiave segreta e [ u , t ] è una stringa che codifica in modo inequivocabile i valori di u e t .

Un ovvio svantaggio di questo schema è che non c'è modo per un utente di disconnettersi esplicitamente. Sfortunatamente, questo difetto è inerente a qualsiasi schema che non memorizza nessuno stato per utente sul server. Come noterai, rendere le pedine valide solo per un breve periodo aiuterà a mitigare questo problema, anche se considererei anche un'ora un periodo abbastanza lungo per tale scopo.

Se puoi fare affidamento sul browser dell'utente che esegue JavaScript, potresti includere uno script che invia regolarmente una richiesta AJAX di background al server per aggiornare il cookie di autenticazione. Questo potrebbe consentire di ridurre il periodo di validità fino a, ad esempio, un paio di minuti.

    
risposta data 25.04.2012 - 00:15
fonte

Leggi altre domande sui tag