Dì, sei un utente "bob". Accedi con la tua password il 2014-07-30H12: 00: 00 e il server, utilizzando lo schema, imposta il token cookie su:
enc("bob", K)+enc("2014-07-30H12:00:00", K)
Tuttavia, bob è dannoso. Mentre il suo capo Alice è lontano dalla sua scrivania, controlla i cookie del suo browser e scopre il suo token:
enc("alice", K)+enc("2014-07-30H13:00:00", K)
Bob non ha bisogno di conoscere la chiave segreta K sul server, dal momento che il valore di enc("alice", K) non cambia mai, quindi tutto quello che deve fare per falsificare l'utente "alice" in qualsiasi momento nel futuro è cambiare il proprio cookie per sostituire l'output di enc("bob", K) con l'output di enc("alice", K) .
Lo schema con l'hmac suggerito sopra non è vulnerabile a questo attacco. Il token restituito dal server è simile al seguente:
bob$2014-07-30H12:00:00$b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
Bob può provare a cambiare "bob" in "alice", ma quando il server esegue il calcolo della convalida, l'hash sha256 calcolato non corrisponderà, e sarà ovvio che il nome utente o il timestamp sono stati manomessi. Bob non è in grado di calcolare l'hash, dal momento che non conosce la chiave segreta utilizzata dal server.
L'operazione di convalida di split() e hmac() è estremamente veloce e richiede microsecondi. Probabilmente saranno più veloci della decrittografia dei token. Ovviamente, invierai il token su un canale sicuro, ad esempio tramite https utilizzando un cookie sicuro, quindi non è necessario crittografare ulteriormente il nome utente e il timestamp in aggiunta a hmac.
Modificato per aggiungere:
Anche se si utilizza invece quanto segue:
enc("bob"+"$"+"2014-07-30H12:00:00", K)
questo non è ancora abbastanza buono. Ottenere la crittografia giusta è estremamente difficile e ci sono molte probabilità che ci siano dei punti deboli nella tua implementazione (tutti i token inviati a "alice" inizieranno allo stesso modo a meno che tu non faccia la cosa giusta con casualità e inizializzazione). Dato che l'hacker conoscerà sia il testo in chiaro che il crittotesto, c'è un numero di attacchi che possono provare a capire qual è il valore di K, a meno che non si utilizzi l'algoritmo corretto con i parametri di inizializzazione corretti.
Inoltre, tutta la buona crittografia incorpora sempre hmac per il controllo dell'integrità comunque , quindi tentando di semplificare il processo finirai per indebolirlo o renderlo più complicato e computazionalmente intensivo.
Basta attenersi alla raccomandazione username+timestamp+hmac(sha256, username+timestamp, K) e trasferirla al client su un canale sicuro. È uno schema che funziona bene.