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.
- L'ID utente: u
- 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.