Difetto nell'autenticazione del digest HTTP

2

Sto lavorando al mio libro di testo e mi sono imbattuto in questa domanda:

Di seguito è riportato il formato del messaggio per una risposta del browser per accedere a una pagina Web protetta da password utilizzando l'autenticazione del digest HTTP.

GET URI HTTP/1.1
Host: URL
...
Authorization: Digest username="UserName", realm="Realm", nonce="Nonce",
uri="URI", algorithm=MD5, response="Response", qop=QoP, nc=NonceCount,
cnonce="ClientNonce"

In che modo il server convaliderà questa risposta?

Mi sono inventato questo schema:

    1. Use UserName and Realm to retrieve D1 =
       md5sum(Username:Realm:Password) from the password file.

    2. Compute D2 = md5sum(GET:URI).

    3. Compute r = md5sum(D1 : Nonce:NonceCount:ClientNonce:QoP:D2).

    4. If r == Response, authentication succeeds and return the content of
       URI; otherwise authentication fails and return an error code.

È corretto o ci sono dei difetti nel mio metodo?

L'unica cosa che posso pensare è che un utente malintenzionato di Man in the Middle potrebbe dire ai client di utilizzare l'autenticazione di accesso di base perché l'autenticazione digest non fornisce alcun meccanismo ai client per verificare l'identità del server. Potrebbe anche essere vulnerabile agli attacchi di riproduzione, ad esempio se il client può riprodurre il digest dei messaggi creato dalla crittografia, il server consentirà l'accesso al client.

    
posta fartsunknown 15.10.2015 - 21:08
fonte

1 risposta

2

I came up with this scheme:

L'autenticazione del digest è definita in RFC 2617 quindi fai riferimento a questa documentazione invece di venire con il tuo schema .

It may also be vulnerable to replay attacks...

Il nonce impostato dal server viene utilizzato per difendersi dagli attacchi di replay, ovvero vengono accettate solo le risposte che corrispondono al nonce imprevedibile.

What could the flaws be then? I am not confident that the scheme that I used is flawless.

Mentre Digest risolve il problema di autenticare il client su un canale non sicuro, rende necessario archiviare le password sul server in modo semplice o in forma equivalente per verificare i dati inviati dal client. Questo sposta il problema della vulnerabilità dal trasporto dei dati al server. E in effetti consente a un utente malintenzionato di non compromettere un singolo account ma zillions contemporaneamente .

Il che significa che dovresti utilizzare meglio TLS per proteggere il canale e mantenere la password memorizzata in un protetto in forma irreversibile , in modo che un aggressore non possa compromettere gli account facilmente e in massa. Inoltre questo risolve il problema della mancanza di identificazione del server.

    
risposta data 15.10.2015 - 22:21
fonte

Leggi altre domande sui tag