Se usiamo solo client nonce e non server nonce, quali vettori di attacco diventano possibili?

Question

Se usiamo solo client nonce e non server nonce, quali vettori di attacco diventano possibili?

#1 da (3 voti)

1

Come tutti sappiamo, nonce è necessario per prevenire gli attacchi di riproduzione. Ovunque legga di nonce, vedo che il client recupera sempre uno dal server, e , per migliorare ulteriormente la sicurezza, può anche aggiungere il proprio client nonce (cnonce).

Proprio come in questo diagramma:

Questo schema aggiunge un overhead di un altro roundtrip al server; e sto cercando di capire quali vettori di attacco diventeranno possibili se usiamo solo il nonce del client, e assicuriamo sul server che le cose non vengano mai riutilizzate (per evitare di memorizzare tutte le cose usate, ovviamente potremmo semplicemente richiedere che ogni successivo errore per una determinata chiave API è maggiore di quello precedente e memorizza solo l'ultimo valore per la chiave API fornita).

Finora non riesco a trovare alcun nuovo vettore di attacco: assicurandoci che non si possano mai riutilizzare i vantaggi per ogni chiave API, eliminiamo completamente gli attacchi di riproduzione. Mi manca qualcosa?

authentication cryptography nonce

posta Dmitry Frank 18.05.2018 - 23:36

fonte

1 risposta

Leggi altre domande sui tag authentication cryptography nonce

Cifra un corpo invece di firmarlo (con JWT per esempio) Gli hash di dati sensibili devono essere crittografati

score 3 · Accepted Answer

L'attacco di riproduzione diventa possibile. Poiché un utente malintenzionato può scegliere il suo cliente nonce, può semplicemente scegliere un nonce che un utente legittimo ha scelto e riprodotto il suo login.

Si noti che tecnicamente è possibile eliminare il round trip aggiuntivo scegliendo un nonce prevedibile come nonce del server, ad esempio l'ora corrente + il nome utente. Quindi si memorizza l'ultimo tempo utilizzato dall'utente e si accettano solo nonces con un tempo maggiore per impedire la riproduzione. Anche se questo non è sicuro come un nonce casuale, potrebbe essere sufficiente per alcuni casi d'uso.

Vale a dire con questo approccio, potrebbe essere necessario implementare un periodo di prova per gli orologi, che non sono precisi, accettando nonce che sono fuori da un po 'di tempo. Un utente malintenzionato potrebbe essere in grado di ottenere un token e usarlo entro questo periodo di tempo, dove non sarebbe in grado di usarlo direttamente, anche se questo è abbastanza improbabile. Un attaccante può anche essere in grado di ottenere gettoni per il futuro se può manipolare l'orologio dei client. E probabilmente altri vettori potrebbero essere aperti usando questo approccio.