Utilizza l'autenticazione utilizzando 2 stringhe crittografate

Questo sembra essere molto più complicato del necessario. Qual è il punto delle due chiavi differenti? Qual è il punto della stringa di verifica? Perché la crittografia anziché la sola verifica (l'ID utente molto probabilmente non è un segreto)?

Penso che tu possa semplificare il tuo sistema fino a questo:

1. Quando un utente effettua l'accesso, genera un MAC utilizzando l'ID dell'utente, un timestamp e la chiave segreta e invia loro l'ID utente, il timestamp e il MAC come cookie.
2. Ad ogni richiesta, ricalcolare il MAC (utilizzando l'ID utente e la data / ora dal cookie e la chiave segreta memorizzata sul server Web). Rifiuta qualsiasi richiesta in cui il MAC calcolato non corrisponde o il timestamp è troppo vecchio.

Java ha una classe Mac integrata, e c'è esempi di persone che lo utilizzano su Stack Overflow.

Dovresti sapere che questo indebolisce la sicurezza:

• Se qualcuno riceve la tua chiave segreta, può accedere come chiunque e non te ne accorgi.
• Se qualcuno ruba il cookie dell'utente, può accedere come tale utente fino a quando il cookie diventa obsoleto (i normali cookie hanno questo problema).
• Non hai modo di revocare l'accesso, anche se sai che i cookie di un utente sono stati rubati (i normali cookie non hanno questo problema).

Per quanto riguarda la velocità:

• L'hashing è (in generale) estremamente veloce.
• L'accesso al database è più lento, ma comunque così veloce che la tua soluzione non è probabilmente necessaria.

Sembra che tu stia cercando di memorizzare un messaggio autenticabile con un client. Per questo, si desidera utilizzare un [HMAC]. Alcuni degli aspetti negativi di questa soluzione sono stati recentemente discussi nella domanda Link di reimpostazione password: valore casuale o messaggio autenticato? .

Personalmente preferisco i database in gran parte perché devi salvare qualcosa per essere autenticati in un dato momento e i controlli del database ti consentono di scadere . Una volta passato un messaggio autenticato, non puoi ucciderlo in anticipo a meno che tu non controlli un elenco di revoche ... accesso al database di nuovo.

Il problema è la revoca. Una volta che hai distribuito il cookie, è infinitamente riutilizzabile finché non cambiano la password. Se il loro cliente è compromesso, il cookie potrebbe perdere e sarebbe valido fino alla successiva modifica della password. Un possibile miglioramento sarebbe utilizzare una chiave sul server per crittografare un timestamp e includerlo con il cookie. Questo potrebbe quindi essere usato per limitare la validità temporale di un cookie, sebbene la revoca a causa del logout non sarebbe ancora possibile senza un DB.