Qual è l'approccio tipico alla memorizzazione nella cache dei tentativi di autenticazione non validi?

1

I client (in realtà pezzi di software sviluppati da alcuni tadri casuali su Internet) si stanno autenticando su un server web usando lo schema di autenticazione "base" e per farlo passano il nome utente e la password ad ogni richiesta. Ogni volta che viene passato un nome utente e una password non vuoti, il server deve inserire la password e controllare il nome utente e l'hash sul database. Questo mette un carico extra sul database.

L'approccio tipico per ridurre il carico del database consiste nel memorizzare nella cache i risultati dell'autenticazione nella memoria del server. È facile per i tentativi riusciti: solo il nome utente della cache, l'hash della password e un oggetto interno che rappresenta l'utente per circa 20 secondi. Sì, l'utente sarà in grado di utilizzare la vecchia password per non più di 20 secondi, ma non sembra un grosso problema la maggior parte del tempo.

E i tentativi falliti? Se li metto in cache per troppo tempo, gli utenti vedranno che inserire una password corretta "non funziona". Inoltre non sono sicuro di aver bisogno di memorizzare esattamente le coppie di nomi utente e password errate (in modo che la modifica di una password causi immediatamente un errore di cache) o ho bisogno di memorizzare nella cache solo il fatto che un utente specifico non è riuscito ad autenticare una password causa un colpo di cache e l'utente non può autenticarsi con alcuna password fino a quando la voce della cache non scade).

Qual è l'approccio tipico alla memorizzazione nella cache dei tentativi di autenticazione errati?

    
posta sharptooth 17.11.2014 - 15:55
fonte

1 risposta

1

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.

    
risposta data 17.11.2014 - 17:14
fonte

Leggi altre domande sui tag