Digest access authentication

Digest access authentication è un metodo concordato che un web server può utilizzare per negoziare le credenziali, quali nome utente o password, del web browser dell'utente. Può essere utilizzato per confermare l'identità di un utente prima di mandare informazioni sensibili, ad esempio la cronologia delle transazioni bancarie. Applica una funzione hash al nome utente e password prima di inviarli sulla rete. Questo meccanismo è più sicuro dell'invio mediante basic access authentication, che utilizza la codifica Base64, anziché usare un algoritmo di crittografia, che lo rende insicuro a meno che non venga usato insieme al Transport Layer Security. Digest access authentication utilizza il protocollo HTTP ed è un'applicazione della funzione crittografica di hash MD5 con utilizzo di un valore nonce per prevenire un replay attack.

Descrizione

Digest access authentication è stata specificata originariamente nel RFC 2069 (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifica sommariamente uno schema di autenticazione tradizionale in cui la sicurezza è garantita da un nonce generato dal server. La risposta all'autenticazione è formata così (HA1, HA2, A1, A2 sono variabili di tipo stringa):

$\mathrm {HA1} =\mathrm {MD5} {\Big (}\mathrm {A1} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {username} :\mathrm {realm} :\mathrm {password} {\Big )}$

$\mathrm {HA2} =\mathrm {MD5} {\Big (}\mathrm {A2} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {method} :\mathrm {digestURI} {\Big )}$

$\mathrm {risposta} =\mathrm {MD5} {\Big (}\mathrm {HA1} :\mathrm {nonce} :\mathrm {HA2} {\Big )}$

RFC 2069 è stato sostituito in seguito da RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 introduce una serie di miglioramenti opzionali di sicurezza all'autenticazione digest; "quality of protection" (qop), contatore nonce incrementato dal client e un nonce generato casualmente dal client.

Se l'algoritmo di hash è MD5 oppure non è specificato, allora HA1 è:

$\mathrm {HA1} =\mathrm {MD5} {\Big (}\mathrm {A1} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {username} :\mathrm {realm} :\mathrm {password} {\Big )}$

Se l'algorirmo di hash è "MD5-sess" allora HA1 è:

$\mathrm {HA1} =\mathrm {MD5} {\Big (}\mathrm {A1} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {MD5} {\Big (}\mathrm {username} :\mathrm {realm} :\mathrm {password} {\Big )}:\mathrm {nonce} :\mathrm {cnonce} {\Big )}$

Se il valore del qop è "auth" oppure non è specificato, allora HA2 è:

$\mathrm {HA2} =\mathrm {MD5} {\Big (}\mathrm {A2} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {method} :\mathrm {digestURI} {\Big )}$

Se il valore del qop è "auth-int", allora HA2 è:

$\mathrm {HA2} =\mathrm {MD5} {\Big (}\mathrm {A2} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {method} :\mathrm {digestURI} :\mathrm {MD5} (entityBody){\Big )}$

Se il valore di qop è "auth" o "auth-int", allora il calcolo della risposta è:

$\mathrm {risposta} =\mathrm {MD5} {\Big (}\mathrm {HA1} :\mathrm {nonce} :\mathrm {nonceCount} :\mathrm {clientNonce} :\mathrm {qop} :\mathrm {HA2} {\Big )}$

Se qop non è specificato, allora il calcolo della risposta è:

$\mathrm {risposta} =\mathrm {MD5} {\Big (}\mathrm {HA1} :\mathrm {nonce} :\mathrm {HA2} {\Big )}$

L'impatto della sicurezza di MD5 sul digest access authentication

I calcoli MD5 usati nel digest authentication HTTP sono usati a "una via", è difficile determinare l'input originale conoscendo l'output. Se però la password è troppo semplice, è possibile provare tutti gli input possibili e trovare un output abbinato (un brute-force attack)-possibilmente con l'aiuto di un dizionario o una tabella arcobaleno, che sono disponibili per MD5.

Lo schema HTTP è stato ideato da Phillip Hallam-Baker al CERN nel 1993 e non include miglioramenti successivi nei sistemi d'autenticazione, quali ad esempio lo sviluppo di keyed-hash message authentication code(HMAC). Sebbene il costrutto crittografico usato si basa sulla funzione hash MD5, nel 2004 si pensava che le collisioni hash non influenzassero le applicazioni dove il plaintext (es. password) non era conosciuto. Tuttavia affermazioni nel 2006 hanno causato dubbi per alcune applicazioni di MD5. Finora, peró, attachi di collisione alla MD5 non si sono dimostrati di essere una minaccia per digest authentication e RFC 2617 permette ai server di implementare meccanismi mirati a individuare alcuni attacchi di collisione e replay attack.

Considerazioni sull'autenticazione HTTP digest

Vantaggi

Http digest authentication è stata progettata per essere piú sicura degli schemi tradizionali per digest authentication, ad esempio "significativamente più potente di ad esempio CRAM-MD5..."(RFC 2617).

Alcuni lati forti in termini di sicurezza di HTTP digest authentication sono:

• La password non è mandato al server in chiaro, prevenendo attacchi di Phishing se l'utente accede ad un sito web sbagliato.
• La password non è usata direttamente nel digest, ma piuttosto la HA1=MD5(username:realm:password). Questo permette ad alcune implementazioni (ad esempio JBoss) di memorizzare la HA1 anzichè la password stessa.
• I nonce dal lato client sono state introdotte nel RFC 2617, che permettono al client di prevenire gli attacchi con testo in chiaro scelto, quali ad esempio le tabelle arcobaleno che altrimenti potrebbero minacciare gli schemi di digest authentication.
• I nonce dal lato server possono contenere timestamp. Perciò il server può ispezionare gli attributi del nonce inviato dai client, per prevenire i replay attack.
• Il server può inoltre mantenere una lista di nonce recentemente usati per prevenirne il riuso.

Svantaggi

Digest access authentication è un compromesso di sicurezza. Sostituisce il HTTP basic access authentication non cifrato. Però non dovrebbe sostituire protocolli di autenticazione robusti, quali l'autenticazione a chiave pubblica o Kerberos.

In termini di sicurezza, ci sono parecchi svantaggi nell'usare digest access authentication:

• Molte delle opzioni di sicurezza nel RFC 2617 sono facoltativi. Se quality-of-protection non è specificato dal server, il client opererà nella modalità meno sicura, RFC 2069.
• Digest access authentication è vulnerabile agli attacchi man-in-the-middle (MITM). Per esempio, un attaccante MITM può dire ai client di usare basic access authentication oppure la modalità RFC 2069 digest access authentication. Inoltre digest access authentication non offre dei meccanismi ai client per verificare l'identità del server.
• Alcuni server impongono che le password siano memorizzate usando criptazione reversibile. Però è possibile memorizzare il valore digested dell'username, realm e password.
• Previene l'uso di hash delle password più robuste (ad esempio bcrypt) nel memorizzare le password (siccome la password o il digested username, realm e password devono essere ricoverabili.

Inoltre, siccome l'algoritmo MD5 non è utilizzabile in FIPS, HTTP digest authentication non funzionerà con moduli di crittografria certificati in FIPS.

Protocolli di autenticazione alternativi

Alcuni protocolli di autenticazione robusti per applicazioni web-based:

• Autenticazione Public key usando un certificato client (solitamente usato con HTTPS/SSL client certificate).
• Autenticazione Kerberos o SPNEGO, usato per esempio da Microsoft IIS per Integrated Windows Authentication.
• Secure Remote Password protocol (preferibilmente usato nel layer HTTPS/TLS). Seppure non usato nei browser convenzionali.

L'approccio più comune è nell'uso del protocollo HTTP+HTML form-based authentication o il meno comune Basic access authentication.

Questi protocolli cleartext meno robusti usati insieme alla criptazione di rete HTTPS sono una soluzione per molte minaccie per cui digest access authentication è stato progettato. Però questo uso di HTTPS conta sul fatto che il client validi l'URL al quale sta accedendo per non mandare la password ad un server non affidabile, che potrebbe risultare in un attacco Phishing. L'utente, però, spesso non lo fa, perciò il phishing è diventato la falla nella sicurezza più comune.