L'approccio generico per una cache è di mantenerlo sincronizzato con il database. In questo momento hai un sistema, con RAM, che può decidere se un nome utente + password è corretto o meno controllando in relazione al suo contenuto RAM, lasciandolo scorrere al database se l'informazione non è in RAM (o è considerata troppo vecchia in qualche modo). Se è possibile fare in modo che gli aggiornamenti delle password passino allo stesso modo, è possibile assicurarsi che, ogni volta che viene modificata una password, i contenuti della RAM siano aggiornati; una semplice implementazione sarebbe simile a questa:
-
La cache RAM contiene tuple ( utente , password , ok , età ) dove " ok "è un valore booleano (" true "per: user + password match," false "per una mancata corrispondenza conosciuta) e" age "è la data in cui il l'ultima informazione è stata utilizzata.
-
Quando viene effettuato un tentativo di accesso per utente "Bob" e password "p @ ssw0rd1":
- Se la cache RAM contiene una tripletta ("Bob", "p @ ssw0rd1", z , età ) quindi aggiorna età a la data e l'ora correnti e restituisce z ("true" sull'autenticazione riuscita, "false" sull'autenticazione fallita)
- Altrimenti, eseguire la verifica con il valore hash memorizzato nel database, ottenendo il risultato z ("true" o "false"); memorizzare ("Bob", "p @ assw0rd1", z , ora ) nella cache e restituire z .
-
Quando l'utente "Bob" cambia la sua password, rimuovi tutte le tuple ("Bob", *, *, *) dalla cache.
-
La cache ha una dimensione limitata. Se la cache è piena e si desidera inserire una nuova tupla, rimuovere quella più vecchia (quella per cui il campo " età " è il più lontano nel passato). Si chiama cache LRU (come in "Least Recently Used").
Non esiste una ragione specifica per trattare i risultati positivi e negativi in modo diverso; o contiene un'interessante informazione. Si noti che non è necessario un limite di tempo qui; fino a quando la cache viene aggiornata (o semplicemente svuotata) quando c'è una modifica della password, non c'è alcun problema nel mantenere le voci della cache per quantità arbitrarie di tempo.
Se non è possibile aggiornare la cache in seguito a modifiche della password, è necessario impostare un timeout breve in modo che le informazioni memorizzate nella cache non vengano utilizzate se sono più vecchie di, diciamo, 20 secondi (come previsto). Anche in questo caso, gli hit positivi e negativi non devono essere gestiti diversamente; infatti, si può sostenere che il caching di hit negativi (mancata corrispondenza utente + password) è necessariamente sicuro poiché, nel peggiore dei casi, impedisce agli utenti di uscire; la memorizzazione nella cache di hit positivi può, d'altra parte, consentire alle persone di entrare con una password che è stata invalidata (anche se con un timeout di 20 secondi, la finestra di vulnerabilità è piuttosto piccola).
Riepilogo: errori di autenticazione nella cache sono buoni, perché sono sicuri (non concederà la voce quando non dovrebbe). Tenete presente, tuttavia, che non ostacolerà DDoS: un utente malintenzionato DDoS invierà semplicemente molte richieste con password casuali, vale a dire richieste che non sono mai nella cache in ogni caso. Gli errori di autenticazione nella cache aiutano contro DDoS involontario , quando un utente ha inserito la password errata ma non lo capisce e fa clic su "Aggiorna" ripetutamente.