Attack Challenge / Response Autenticazione richiedendo sfide

Question

Attack Challenge / Response Autenticazione richiedendo sfide

#1 da (3 voti)

2

Se un'applicazione client / server utilizza un modello di richiesta / risposta per l'autenticazione, ad es. SCRAM o simili, spesso implica l'uso di nonces (client nonce e server nonce) per prevenire attacchi di replay.

Il server genererà un server nonce, basato su un numero generato casualmente sicuro concatenato con il nonce del client. Supponendo che il server memorizzi il nonce del client ricevuto più recente e abbia emesso il nonce del server, per garantire che non vengano accettati "non vecchi" o "non validi", questo aprirebbe un vettore di attacco.

Un utente malintenzionato potrebbe sottoporre a richieste di forza bruta a userid che egli indovina, al fine di ignorare il nonce client / server valido e concordato con un nuovo valore, che il client effettivo non conosce. Se questo accade tra la sfida e la risposta del cliente reale, il server negherà l'accesso poiché il nonce non sarà più valido. Quale sarebbe una sorta di attacco di tipo Denial Of Service.

Se il server decide di aggiornare solo il nonce / server effettivamente valido nella memoria solo se la richiesta / risposta è stata eseguita correttamente nel suo complesso, dovrebbe rifiutare le richieste di verifica per gli utenti che non hanno risposto alla sfida più recente . Ciò aprirebbe anche una finestra di attacco. L'attacco potrebbe richiedere sfide agli utenti (indovinati) al fine di impedire loro di richiedere una sfida in primo luogo.

Supponendo che il server tenga traccia di un elenco di nonces inutilizzati, entrambi gli attacchi sarebbero prevenuti, ma questo apre un altro vettore affinché l'attaccante possa richiedere una quantità enorme di sfide, portando il server a memorizzare tutti quei punti in memoria. Provoca il carico di I / O e potenzialmente porta nuovamente a DoS.

In ogni caso, attualmente non capisco come implementare in modo sicuro la gestione di nonce sul lato server per prevenire quegli attacchi DoS. Attualmente ho la sensazione che si venda la protezione dagli attacchi di replay a favore del DoS.

So che ci sono altri modi per impedirlo, tramite la limitazione delle richieste sui firewall, ecc., ma vorrei risolvere questo problema sul livello di implementazione della sfida / risposta, se possibile. Grazie per le idee e le risposte.

authentication attacks attack-prevention challenge-response

posta Tobias N. Sasse 20.04.2016 - 14:37

fonte

1 risposta

Leggi altre domande sui tag authentication attacks attack-prevention challenge-response

Il forzamento bruto richiede una password e un elenco di nomi utente? Perché un attacco con tavolo arcobaleno non può identificare e spazzare il sale?

score 3 · Accepted Answer

I due dubbi che hai sollevato sono:

La copia del server del server nonce può essere modificata da un utente malintenzionato che non conosce la password.
Man mano che l'elenco dei client di client nonces cresce senza limiti, può essere utilizzato in un DoS.

Una tecnica comune è quella di limitare il tempo dei nonces. Dì, per M minuti per un M. appropriato

Per il primo problema, limitando nel tempo i nonce, il server può mantenere più sessioni di autenticazione con il client, ognuna delle quali tiene traccia del proprio nonce. Questo non è un grande drenaggio di risorse sul server poiché queste sessioni vengono automaticamente cancellate dopo M minuti.

Il secondo problema è risolto da nonce client limitanti nel tempo. Perché ciò funzioni, il client nonce deve includere un timestamp. Altrimenti puoi aprire attacchi di riproduzione post-timeout, quando il server cancella i suoi punti scaduti, quindi "dimenticando" i nonces usati. Quindi il nonce del client dovrebbe essere timestamp + secure random number . Includendo il timestamp nel nonce, assicura che il nonce non possa essere utilizzato dopo il timeout.

Quando si determina il valore di M, deve essere sufficientemente grande da gestire i tempi di comunicazione di rete e le differenze di clock tra il server e il client. M deve essere sufficientemente piccolo da ridurre sufficientemente i requisiti delle risorse. M essere 1 o anche meno di 1 può essere appropriato se non è richiesta alcuna interazione da parte dell'utente durante il processo di autenticazione. Se è richiesto l'input dell'utente, sarà necessario un M più grande.

Un attaccante con risorse adeguate può ancora essere in grado di eseguire un DoS su di te poiché esiste ancora una finestra di minuti M affinché ciò avvenga. Ma questa è una piccola finestra e richiederebbe molte risorse da attaccante. Cioè, sarebbe un DDoS e non un DoS diretto. Sopravvivere agli attacchi DDoS è un problema a sé stante.