I client Nonces migliorano la sicurezza dell'autenticazione del digest HTTP?

Naviga le tue risposte
7

Per quanto ho capito, la risposta a link , i client nonces hanno lo scopo di impedire agli attaccanti di ammortizzare i costi della forza bruta calcoli hash essendo in grado di riutilizzare i risultati dei calcoli

  • per più utenti e / o
  • per più server

Tuttavia, anche nella più semplice variante di autenticazione del digest (qop = none), il username e il realm (apparentemente univoco per server) e il nonce (più che solo univoco per server) sono inclusi nel dati che ottengono (solitamente MD5) hash.

Questo non rende già impossibile il riutilizzo degli hash precompilati su utenti / server?

Quindi un client nonce aggiungerebbe alla sicurezza solo se il link è corretto:

The ability to choose the nonce is known to make cryptanalysis much easier [8].

Ma la stessa sezione continua dicendo

However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known.

Questa è una dichiarazione del 1999. Da allora, sono stati pubblicati vari attacchi di collisione per MD5, ma nessuno di questi sarebbe di aiuto in questo caso, se non sbaglio.

Cosa mi manca?

Aggiornamento Credo che sia logico precisare di cosa stiamo parlando esattamente. Nella forma più semplice di autenticazione del digest, il client calcola e invia al server il risultato di quanto segue: 

MD5(MD5(username + ":" + REALM + ":" + password)
    + ":" + NONCE + ":" +
    MD5(http-method) + ":" + uri))

Ad eccezione della password, tutti i valori vengono anche inviati in testo normale.

Per rendere più chiaro, le variabili i cui valori sono impostati dal client sono in minuscolo , mentre le variabili che il client recupera dal server sono in maiuscolo . (Questo rende la mia fallacia "regno e nonce" sopra, sottolineata da David Wachtfogel immediatamente ovvia, dato che un MITM può liberamente scegliere quei valori maiuscoli, assumendo che il regno non sia controllato dal cliente, il che, a giudicare dalla "sofisticazione" I visto nella maggior parte delle password di admin, sarebbe la norma, piuttosto che l'eccezione).

Btw, il valore di uri dovrebbe essere un assoluto uri , come http://servername/path?query , e quindi sarebbe globalmente unico, tuttavia, che dipende dall'implementazione del client e considerando Opera implementa in questo modo , le versioni di Chrome, IE, Firefox ho provato non , e piuttosto uso solo '/ path? query' (afaict questo è in violazione del link ).

Quindi, se una tabella precompilata sarebbe riutilizzabile tra i server dipende dall'implementazione del client, e se il MITM può scegliere, preferirà naturalmente i browser più deboli a Opera, se ha una tabella precalcolata.

    
posta Eugene Beresovsky 16.10.2012 - 09:49
fonte

2 risposte

6

Come descritto nella risposta di Thomas Pornin citata in questa domanda, l'obiettivo del nonce del client è prevenire un attacco in chiaro in chiaro in cui l'attaccante impersona il server e sceglie la sfida. In una situazione del genere, l'attaccante può anche scegliere il reame (poiché questo proviene dal server), quindi il fatto che il regno sia sottoposto a hash come parte della risposta non impedisce completamente questo attacco. Solo se l'utente è vigile e controlla che il regno sia come previsto, ciò impedirà l'attacco.

Il nome utente aiuta in quanto richiede che l'attaccante costruisca una tabella hash precalcolata, come una tabella arcobaleno, per nome utente. Il problema è che i nomi utente non sono globalmente unici: lo stesso nome utente esisterà su molti server diversi. In effetti alcuni nomi utente sono estremamente comuni e rischiano di apparire sulla maggior parte dei server: un esempio classico è "admin".

Quindi un utente malintenzionato può fare quanto segue:

  1. Una volta: crea una tabella hash precalcata per username="admin", realm = X e challenge = Y (utilizzando qualsiasi valore per X e Y)
  2. Collegamenti di intercettazione a qualsiasi server che l'utente malintenzionato vuole attaccare
  3. Se qualcuno si connette al server con nome utente "admin", invia real = X e sfida = Y
  4. Cerca la risposta nella tabella hash precalcolata per rivelare la password

Il client nonce impedisce questo tipo di attacco; poiché l'attaccante non controlla e non può prevedere questo nonce, l'attaccante non può costruire la tabella hash precalcolata.

    
risposta data 16.10.2012 - 13:10
fonte
2

the username and the realm (supposedly unique per server)

Questo non è corretto. Il realm è un valore specificato dal fornitore di servizi per descrivere l'area di protezione, quindi è solo un nome, non un identificatore globale.

Nella tua seconda citazione penso che si riferiscano alla "one-way-ness" di MD5 che non viene interrotta. Il modo più efficace per trovare un preimage (cioè passare dal valore Y = MD5 (x) per trovare x) richiede 2 123.4 operazioni.

the cnonce "è una stringa opaca fornita dal client e utilizzata dal client e dal server per evitare gli attacchi di testo in chiaro, per fornire l'autenticazione reciproca e per fornire una certa protezione dell'integrità dei messaggi." [RFC ] Insieme al nonce, facilita l'autenticazione reciproca sostenuta: l'autenticazione del client sul server e viceversa.

    
risposta data 16.10.2012 - 10:00
fonte

Leggi altre domande sui tag

Come può essere impersonificato un dominio con un certificato SSL fraudolento? Come funziona davvero ottenere una shell remota sfruttando una vulnerabilità?