Cos'è l'autenticazione digest?

101

In che modo l'autenticazione del digest è diversa dall'autenticazione di base oltre all'invio di credenziali come testo normale?

digest-authentication

— SoftwareGeek
fonte

Grande spiegazione @Gumbo proprio qui: stackoverflow.com/a/5288679/591487

— inorganik

Qualcosa che non dovresti MAI MAI usare. Non protegge la password in transito e richiede al server di memorizzare le password in chiaro.

— CodesInChaos

Digest fornisce una migliore sicurezza in transito rispetto all'autenticazione di base per il traffico non crittografato , ma è debole. È MOLTO più sicuro utilizzare l'autenticazione di base in combinazione con SSL / TLS, perché in questo modo puoi anche mantenere crittografate le password sul server.

— rustyx

Risposte:

179

La differenza principale è che non richiede l'invio del nome utente e della password attraverso il cavo in testo normale. È anche immune agli attacchi replay, poiché utilizza un numero una tantum dal server.

Il server fornisce al client un numero di utilizzo una tantum (un nonce) che combina con il nome utente, l'ambito, la password e la richiesta URI. Il client esegue tutti questi campi tramite un metodo hash MD5 per produrre una chiave hash.

Invia questa chiave hash al server insieme al nome utente e all'area di autenticazione per tentare di autenticarsi.

Sul lato server viene utilizzato lo stesso metodo per generare un hashkey, solo che invece di utilizzare la password digitata nel browser il server cerca la password prevista per l'utente dal proprio DB utente. Cerca la password memorizzata per questo nome utente, viene eseguito attraverso lo stesso algoritmo e la confronta con ciò che il client ha inviato. Se corrispondono, l'accesso viene concesso, altrimenti può restituire un 401 Non autorizzato (nessun accesso o accesso non riuscito) o un 403 Proibito (accesso negato).

L'autenticazione del digest è standardizzata in RFC2617 . C'è una bella panoramica su Wikipedia :

Puoi pensarlo in questo modo:

Il cliente fa la richiesta
Il client riceve un nonce dal server e una richiesta di autenticazione 401
Il client restituisce il seguente array di risposta (username, realm, generate_md5_key (nonce, username, realm, URI, password_given_by_user_to_browser)) (sì, è molto semplificato)
Il server prende nome utente e dominio (in più conosce l'URI richiesto dal client) e cerca la password per quel nome utente. Quindi va e fa la propria versione di generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
Confronta l'output di generate_md5 () ottenuto con quello inviato dal client, se corrispondono al client che ha inviato la password corretta. Se non corrispondono la password inviata era sbagliata.

— Ian C.
fonte

Bella spiegazione. Il nome utente e il pwd sono per un utente Windows? Da dove vengono generati?

— SoftwareGeek

Sono tutto ciò che l'utente digita nel browser. La password deve corrispondere a ciò che il server ha memorizzato per la password per quell'utente. Molto probabilmente è qualcosa di specifico per quell'applicazione web e non la tua password di Windows. Dipende molto dal modo in cui viene assemblata l'applicazione web.

— Ian C.

Questa risposta è vecchia di 6 anni, ma immagino che tutti i sistemi sensibili alla sicurezza memorizzino le password in un formato hash salato ormai. Non esiste e non dovrebbe esserci alcun metodo per ottenere la password originale dal database rendendo impossibile l'autorizzazione del digest.

— Ramon de Klein

Se l'hash digest di nome utente e password è archiviato in db invece di semplici password, è comunque possibile utilizzare digest auth @RamondeKlein

— karakays

@BlueBockser Penso che karakays significasse che invece di usare una semplice password, un hash risultante dalla combinazione sia del nome utente che della sua password dovrebbe essere memorizzato nel server al momento della registrazione e calcolato sul lato client prima dell'autenticazione. Può anche essere fatto con un solo hash della password.

— logo_writer

Un hash delle credenziali viene inviato in rete.

HA1 = MD5(username:realm:password)

Wikipedia ha un eccellente articolo su questo argomento

— Philip Fourie
fonte

da client a server? Potresti fornire i passaggi per l'interazione? L'articolo di Wikipedia è buono ma ho bisogno di una spiegazione o di un esempio migliore.

— SoftwareGeek

Sì, il client genera il valore hash e lo invia al server. L'articolo di Wikipedia descrive il protocollo in dettaglio, ti suggerisco di fare riferimento a questo per maggiori informazioni.

— Philip Fourie

L'unico modo per ottenere l'hash HA1 delle credenziali è conoscere la password. Il server conosce HA1 ma non la password che lo ha generato. Se HA1 fosse noto a un utente malintenzionato, potrebbe entrare nel sistema. Quindi non viene inviato lungo il filo. Un ulteriore hash basato su nonce, ecc. Viene eseguito prima di fare ciò, e questo deve concordare con un calcolo simile fatto sul server. Pertanto, fintanto che il server mantiene HA1 privato, il sistema è sicuro.

— Chris Oakley
fonte

Questa è la spiegazione per l'autenticazione Digest, dove la password non viene inviata in testo normale (come nel caso

— dell'autenticazione di