Secondo il link , avendo il server scelto un nonce ma non avendo il client scelto un nonce si apre l'autenticazione Digest Access agli attacchi di testo normale scelti. La mia domanda è due volte ...
Si tratta di un problema con SHA1? L'autenticazione dell'accesso al digest utilizza MD5, quindi forse il client nonce è destinato specificamente a questo?
Inoltre, in che modo essere in grado di controllare il server scelto nonce aiuta? Il link nella RFC è morto.
L'obiettivo dell'attaccante è indovinare la password. Osservando il messaggio di autenticazione, l'hacker impara già abbastanza per "provare" le password a casa (cioè un "attacco di dizionario offline"), ma non è quello di cui parla RFC 2617 a quel punto. Piuttosto, si concentra sull'idea di un utente malintenzionato che impersona il server, alimentando quindi "non server" di sua scelta per il client. Il client risponde a tale nonce eliminando il server nonce, il client nonce e la password insieme (salgo volontariamente i dettagli qui). L'utente malintenzionato può quindi tentare di sfruttare alcuni punti deboli interni della funzione di hash per ricalcolare la password da ciò che il client ha inviato. Ciò che la RFC 2617 cerca di dire è che omettere il nonce del client può solo rendere le cose più facili per l'attaccante (almeno non particolarmente difficile ed euristicamente più semplice) - come corollario, usando un client nonce può aiuto nella protezione del client nel caso in cui la funzione di hash sia instabile; un client nonce non farà certamente ulteriori danni.
Al momento non è nota alcuna vulnerabilità sfruttabile di MD5, se utilizzata nell'autenticazione dell'accesso al digest come descritto da RFC 2617. Anche se MD5 ha mostrato una notevole debolezza per quanto riguarda la resistenza alla collisione, che è un'altra proprietà di sicurezza distinta che un buon hash funzione dovrebbe avere (e che MD5 non ha). Quindi la protezione offerta qui dal cliente nonce è solo ipotetica. Ma, come ho detto, non danneggia nemmeno.
Quella sezione della RFC sta facendo alcune affermazioni discutibili, e non è scritta molto bene. Ecco cosa penso che dovrebbe aver detto.
Se si consente all'utente malintenzionato di controllare una parte dell'input in una funzione hash, allora si deve pensare se questo abilita gli attacchi di testo normale scelti sulla funzione hash. Se il client non ha fornito alcun nonce, allora si potrebbe temere che un server malevolo possa scegliere il suo server nonce maliziosamente nel tentativo di montare un qualche tipo di attacco di testo in chiaro nella funzione di hash.
Fortunatamente, le attuali funzioni di hash sono progettate per essere sicure contro gli attacchi con testo in chiaro, quindi questa preoccupazione non è realmente un rischio nella pratica.
D'altra parte, se vuoi essere molto cauto, immagino che potresti provare a ridurre il numero di opportunità per questo tipo di attacchi includendo un numero casuale scelto dal cliente. In questo modo, anche se il server è malevolo, è comunque garantito che faccia parte dell'input alla funzione di hash casuale, non controllabile dall'attaccante e non prevedibile dall'attaccante. Non è chiaro se questo fornisce effettivamente alcun vantaggio (probabilmente non è necessario), ma non può ferire.
Vedi la risposta di @ Thomas per ulteriori elaborazioni.
Generalmente è buona pratica ingegneristica avere entrambi gli endpoint che contribuiscono con il loro nonce casuale. Ad esempio, in alcune situazioni questo aiuta a prevenire alcuni tipi di attacchi di replay in cui un endpoint è dannoso.
Non so se lasciare fuori il client nonce abiliterebbe effettivamente una sorta di attacco di replay intelligente su RFC2617, ma perché correre il rischio? Se c'è una semplice modifica posso fare in modo che le regole escludano un'intera classe di possibili attacchi, quella modifica sembra attraente. Qualunque cosa mi impedisca di dover pensare a degli attacchi sottili (e magari a guardarne una, che è catastrofica) sembra una buona cosa.
Nel caso di RFC2617, incluso un client nonce impedisce gli attacchi di precomputazione (ad es., attacchi tempo / spazio, "tabelle rainbox" e simili) quando il server è malevolo. Vedi la risposta di @ ixe013 e il mio commento per ulteriori dettagli su questo.
Sì, è ancora un problema con SHA1. È irrilevante per l'algoritmo di hashing effettivo, a parte il fatto che l'attaccante avrà bisogno di più spazio per archiviare le tabelle di ricerca e forse un po 'più di tempo per calcolarle.
Il digest è un hash del nome utente, della password, del dato valore nonce, del metodo HTTP e dell'URI richiesto (RFC2617). L'hacker conosce tutti loro (ma la password) e quindi può preparare in anticipo una tabella di ricerca. Una tabella di questo tipo non può essere precalcolata in quanto il client aggiunge il proprio nonce (cnonce), sconosciuto all'avversario in anticipo.
Leggi altre domande sui tag authentication cryptography hash nonce