it-swarm.it

A che serve un client nonce?

Dopo aver letto la parte I del libro di Ross Anderson, Security Engineering , e chiarito alcuni argomenti su Wikipedia, mi sono imbattuto nell'idea di Client Nonce (cnonce). Ross non lo menziona mai nel suo libro e faccio fatica a capire lo scopo che serve nell'autenticazione dell'utente.

Un normale nonce viene utilizzato per evitare attacchi di replay che comportano l'utilizzo di una risposta scaduta per ottenere privilegi. Il server fornisce al client un nonce (numero usato ONCE) che il client è costretto a utilizzare per hash la sua risposta, quindi il server esegue l'hashing della risposta che si aspetta con il nonce fornito e se l'hash del client corrisponde all'hash del server quindi il server può verificare che la richiesta sia valida e aggiornata. Questo è tutto ciò che verifica; valido e fresco .

Le spiegazioni che ho trovato per un cliente nonce sono tuttavia meno semplici e discutibili. La pagina di Wikipedia per l'autenticazione dell'accesso digitale e diverse risposte qui su StackOverflow sembrano suggerire che un nonce client viene utilizzato per evitare attacchi in chiaro. Ho diversi problemi con questa idea:

  • Se una persona può annusare e inserire pacchetti, la più grande vulnerabilità è un attacco man-in-the-middle che né un nonce né un ncece possono superare, rendendo quindi entrambi insignificanti.
  • Supponendo per un secondo che l'attaccante non vuole impegnarsi in un attacco man-in-the-middle e vuole recuperare i dettagli di autenticazione, in che modo un cnonce fornisce una protezione aggiuntiva? Se l'attaccante intercetta la comunicazione e risponde a una richiesta con il proprio nonce, la risposta del client sarà un hash del nonce, dei dati e del cnonce oltre al cnonce in forma non crittografata. Ora l'attaccante ha accesso al nonce, al cnonce e all'hash. L'attaccante può ora eseguire l'hashing dei propri tavoli Rainbow con il nonce e il cnonce e trovare una corrispondenza. Pertanto il cnonce fornisce zero protezione aggiuntiva.

Allora, qual è lo scopo di un cnonce?

Presumo che ci sia una parte dell'equazione che non capisco, ma non ho ancora trovato una spiegazione di quale parte sia.

EDIT Alcune risposte hanno suggerito che il client può fornire un nonce e servirà allo stesso scopo. Ciò rompe tuttavia il modello di risposta alla sfida, quali sono le implicazioni di ciò?

85
user2014

Un nonce è un valore univoco scelto da un'entità in un protocollo e viene utilizzato per proteggere tale entità dagli attacchi che rientrano nel raggio molto ampio di "replay".

Ad esempio, si consideri un protocollo di autenticazione basato su password che va così:

  • il server invia una "sfida" (un valore apparentemente casuale c ) al client
  • il cliente deve rispondere inviando h (c || p) dove h è una funzione hash sicura (es. SHA-256), p è la password dell'utente e ' || 'indica concatenazione
  • il server cerca la password nel proprio database, ricalcola la risposta del client prevista e vede se corrisponde a ciò che il client ha inviato

Le password sono valori segreti che si adattano al cervello umano; in quanto tali, non possono essere molto complessi ed è possibile creare un dizionario di grandi dimensioni che conterrà la password dell'utente con alta probabilità. Con "big" intendo "può essere elencato con un cluster di medie dimensioni in poche settimane". Per la discussione in corso, accettiamo che un utente malintenzionato sarà in grado di violare una singola password trascorrendo alcune settimane di calcolo; questo è il livello di sicurezza che vogliamo raggiungere.

Immagina un attaccante passivo: l'attaccante intercetta ma non altera i messaggi. Vede c e h (c || p) , quindi può usare il suo cluster per enumerare potenziali password fino a quando non viene trovata una corrispondenza. Questo sarà costoso per lui. Se l'attaccante vuole attaccare due password, deve fare il lavoro due volte . L'attaccante vorrebbe avere un po 'di condivisione dei costi tra le due istanze di attacco, usando tabelle precompilate (le "tabelle Rainbow" sono solo una specie di tabella precompilata con memoria ottimizzata, ma la creazione di una tabella Rainbow richiede comunque l'enumerazione del dizionario completo e l'hashing di ogni password). Tuttavia, la sfida casuale sconfigge l'attaccante: poiché ogni istanza comporta una nuova sfida, l'input della funzione hash sarà diverso per ogni sessione, anche se viene utilizzata la stessa password. Pertanto, l'attaccante non può creare utili tabelle precompilate, in particolare tabelle Rainbow.

Supponiamo ora che l'attaccante diventi attivo. Invece di semplicemente osservare i messaggi, modificherà attivamente i messaggi, lasciandone alcuni, duplicandone altri o inserendo messaggi propri. L'autore dell'attacco può ora intercettare un tentativo di connessione dal client. L'attaccante sceglie e invia la propria sfida ( c ') e attende la risposta del cliente ( h (c' || p) ). Si noti che il server vero non viene contattato; l'attaccante interrompe bruscamente la connessione immediatamente dopo la risposta del client, in modo da simulare un errore di rete benigno. In questo modello di attacco, l'attaccante ha apportato un grande miglioramento: ha ancora una sfida c ' e la risposta corrispondente, ma la sfida è un valore che l'attaccante ha scelto come meglio credeva. Quello che l'attaccante farà è sempre server la stessa sfida c '. L'uso della stessa sfida ogni volta consente all'attaccante di eseguire pre-calcoli: può costruire tabelle pre-calcolate (cioè tabelle Arcobaleno) che usano quella speciale "sfida". Ora l'attaccante può attaccare diverse password distinte senza incorrere nel costo di enumerazione del dizionario per ciascuna.

Un client nonce evita questo problema. Il protocollo diventa:

  • il server invia una sfida casuale c
  • il cliente sceglie un nonce n (dovrebbe essere sempre distinto)
  • il client invia n || h (c || n || p)
  • il server ricalcola h (c || n || p) (utilizzando il p dal suo database) e vede se questo valore corrisponde a quello inviato dal client

Poiché il client include un nuovo valore casuale ("nonce") nell'input della funzione hash per ogni sessione, l'input della funzione hash sarà sempre distinto, anche se l'attaccante può scegliere la sfida. Questo elimina le tabelle precompilate (Rainbow) e ripristina il livello di sicurezza previsto.

Un'emulazione grezza di un nonce univoco è il nome utente. Due utenti distinti all'interno dello stesso sistema avranno nomi distinti. Tuttavia, l'utente manterrà il suo nome quando cambia la password; e due utenti distinti possono avere lo stesso nome su due sistemi distinti (ad esempio ogni sistema simile a Unix ha un utente "root"). Quindi il nome utente non è un buon nonce (ma è comunque meglio che non avere alcun client nonce).

Per riassumere, il client nonce riguarda la protezione del client da un attacco replay (il "server" è in realtà un attaccante, che invierà la stessa sfida a tutti i client che desidera attaccare). Ciò non è necessario se la sfida viene eseguita su un canale che include un'autenticazione server avanzata (come SSL). Password Authenticated Key Exchange sono protocolli avanzati che garantiscono l'autenticazione reciproca basata su password tra client e server, senza la necessità di un po 'di fiducia a priori (i "certificati root" quando un client SSL autentica il certificato del server SSL) e proteggendo contro aggressori attivi e passivi (incluso l'attacco "cluster per due settimane" su una singola password, quindi è strettamente migliore del protocollo sopra, nonce o no nonce).

138
Thomas Pornin

Vorrei provare a rispondere alla domanda della tua domanda: "Supponendo per un secondo che l'attaccante non vuole impegnarsi in un attacco man-in-the-middle e vuole recuperare i dettagli di autenticazione, in che modo un cnonce fornisce ulteriori protezione?"

In genere un client non solo include un nonce con la richiesta, ma firma l'intera richiesta, incluso il nonce. Ciò significa che anche se l'attaccante intercetta un messaggio tra client e server:

  1. Un attacco di replay non funzionerà (perché il server sta tenendo traccia delle nonces del client).
  2. L'aggressore non può semplicemente generare un nuovo messaggio con un nuovo client nonce, perché non sa come segno il nuovo messaggio in modo appropriato (ovvero privo della chiave segreta o privata del client).
7
Bosh

Secondo RFC 2617 , i parametri cnonce e nc proteggono dagli attacchi in chiaro scelti. In che modo protegge da tali attacchi?

Se Eva cambia il nonce che il server invia al client che cosa ha guadagnato Eva? Eve non può generare h(password || nonce) da h(password || fake_nonce) e in teoria sembra che il server non dovrebbe accettare h(password || fake_nonce) comunque dal momento che il server dovrebbe sapere che nonce è stato emesso e che nonce non ha.

1
paynes_bay

Penso che una buona idea sarebbe quella di avere una lettura di come il valore nonce viene utilizzato in qualcosa come Oauth . In breve, quando un'applicazione che utilizza OAuth effettua una richiesta a un servizio supportato da OAuth, la richiesta deve contenere un gruppo di campi, due dei quali sono timestamp e nonce. Lo scopo del modulo è ovvio: fornisce un'indicazione del lasso di tempo in cui il messaggio è stato inviato in modo che il server possa fare una migliore ipotesi sul fatto che il messaggio sia obsoleto o meno. Quest'ultimo è ovviamente un gruppo di caratteri/byte casuali.

Quando l'intero OAuth viene hash con il segreto del consumatore, vengono inclusi entrambi questi campi. Quindi la firma ha aggiunto alla richiesta (che si tratti di parametri di query o intestazioni HTTP) e inviata al server. Il corpo effettivo della richiesta è non hash.

Il server OAuth dovrebbe tenere traccia del set precedente di N valori nonce per un determinato client per assicurarsi che non vengano riutilizzati. Dato che il corpo del messaggio può cambiare (essenzialmente senza effetto sull'hash) è importante avere qualcos'altro che cambierà (cioè il nonce) per assicurarsi che le richieste siano uniche. Data la natura di testo aperto/semplice di HTTP, questo è piuttosto importante.

Questo aiuta a chiarire il suo scopo? (lo spero :)).

1
OJ.