68
In che modo l'autenticazione del digest è diversa dall'autenticazione di base oltre che l'invio di credenziali come testo normale?Cos'è l'autenticazione digest?
A
risposta
112
La differenza principale è che non richiede l'invio di username e password attraverso il filo in chiaro. È anche immune agli attacchi di replay, poiché utilizza un numero di una sola volta dal server.
Il server fornisce al client un numero di utilizzo monouso (un nonce) che combina con nome utente, area di autenticazione, password e richiesta URI. Il client esegue tutti questi campi attraverso un metodo di hashing MD5 per produrre una chiave hash.
Invia questa chiave di hash al server insieme al nome utente e al dominio per tentare di autenticarsi.
Lato server lo stesso metodo viene utilizzato per generare una hashkey, solo invece di utilizzare la password immessa nel browser, il server cerca la password prevista per l'utente dal suo DB utente. Cerca la password memorizzata per questo nome utente, esegue lo stesso algoritmo e lo confronta con ciò che il client ha inviato. Se corrispondono, l'accesso è concesso, altrimenti può inviare un 401 non autorizzato (nessun login o login fallito) o 403 Proibito (accesso negato).
L'autenticazione del digest è standardized in RFC2617. C'è un nice overview of it on Wikipedia:
Si può pensare a come questo:
- client effettua richiesta
- client torna un nonce dal server e una richiesta di autenticazione 401
- client invia di nuovo la seguente risposta array (nome utente, realm, generate_md5_key (nonce, username, realm, URI, password_given_by_user_to_browser)) (sì, molto semplificato)
- Il server accetta nome utente e ambito (più conosce l'URI richiesto dal client) e lo stesso ks up 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() che ha ottenuto con quello inviato dal client, se corrispondono al client inviato correttamente parola d'ordine. Se non corrispondono, la password inviata è sbagliata.
+0
Bella spiegazione. Il nome utente e la password sono per un utente di Windows? Da dove vengono generati? – SoftwareGeek
+0
Sono qualsiasi cosa l'utente digiti nel browser. La password deve corrispondere a ciò che il server ha memorizzato per la password per quell'utente. Più probabile che non sia qualcosa di specifico per quell'applicazione web e non la tua password di Windows. Dipende molto dal modo in cui l'applicazione web è messa insieme. –
+7
Questa risposta ha 6 anni, ma immagino che tutti i sistemi che si occupano di sicurezza memorizzino le password in un formato hash salato. Non esiste e non dovrebbe esserci alcun metodo per ottenere la password originale dal database rendendo impossibile l'autorizzazione del digest. –
10
Un hash delle credenziali viene inviato sul filo.
HA1 = MD5(username:realm:password)
+0
dal client al server?Potresti fornire i passaggi per l'interazione? L'articolo di Wikipedia è buono ma ho bisogno di una spiegazione o di un esempio migliori. – SoftwareGeek
+0
Sì, il client genera il valore di hash e lo invia al server. L'articolo di Wikipedia descrive il protocollo in dettaglio, ti suggerisco di fare riferimento a questo per ulteriori informazioni. –
1
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 spedito via cavo. Un ulteriore hash basato su nonce, ecc. È fatto prima di fare questo, e questo deve essere d'accordo con un calcolo simile fatto sul server. Pertanto, finché il server mantiene privato HA1, il sistema è sicuro.
+0
Questa è la spiegazione per l'autenticazione del digest, in cui la password non viene inviata in formato testo (come nel caso di Basic Auth) –
Problemi correlati
- 1. Rails 4 asset digest digest
- 2. PHP Digest auth, logout
- 3. Javascript digest autenticazione manuale
- 4. auth digest dropwizard
- 5. Xcode iPhone "digest missing"
- 6. Digest :: CRC32 with Zlib
- 7. AngularJS digest postDigestQueue
- 8. Autenticazione Digest HTTP
- 9. Digest :: MD5 in Ruby 1.9.3
- 10. Autenticazione digest HTTP con HttpUrlConnection
- 11. Git tramite autenticazione proxy digest
- 12. WSContext.getUserPrincipal() restituisce null per autenticazione password digest
- 13. Come posso eseguire l'autenticazione digest con HttpWebRequest?
- 14. AngularJs - Errore: 10 $ digest() iterazioni raggiunte. Abortire
- 15. OpenSSL Firma RSA con digest SHA256
- 16. Diversi Digest Asset seconda css.sass o css
- 17. Pipeline di asset Rails e valori digest
- 18. Utilizzo dell'autenticazione HTTP Digest su iPhone
- 19. Autenticazione del digest in Android utilizzando HttpURLConnection
- 20. Concept of Digest authentication - funziona davvero?
- 21. come implementare l'autenticazione digest usando volley?
- 22. Angolare - Errore: 10 $ digest() iterazioni raggiunte. Interruzione
- 23. NodeJS problema digest hmac con accenti
- 24. Compute MD5 digest di file in Haskell
- 25. solving $ rootScope: infdig Infinite $ digest Loop
- 26. Firma XML: come calcolare il valore digest?
- 27. non valida file di firma SHA1 digest
- 28. Come richiedere l'autenticazione HTTP Digest con Node.JS?
- 29. ng-bind-html restituisce un errore di digest infinito ($ rootScope.infdig)
- 30. Chiama con successo history.pushState() da Angular Without Inifinite Digest?
Grande spiegazione da @Gumbo proprio qui: http://stackoverflow.com/a/5288679/591487 – inorganik
Qualcosa che non dovresti MAI MAI usare. Non protegge la password in transito e richiede che il server memorizzi le password in chiaro. – CodesInChaos
Il digest fornisce una protezione in transito migliore rispetto all'autenticazione di base per il traffico _unencrypted_, ma è debole. È MOLTO più sicuro utilizzare l'autenticazione di base in combinazione con SSL/TLS, perché in questo modo è anche possibile mantenere le password sul server crittografate. – rustyx