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 di 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.

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):

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

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

${\displaystyle \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 è:

${\displaystyle \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 è:

${\displaystyle \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 è:

${\displaystyle \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 è:

${\displaystyle \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 è:

${\displaystyle \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 è:

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

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^[1].

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^[2]. Tuttavia affermazioni nel 2006^[3] hanno causato dubbi per alcune applicazioni di MD5. Finora, però, attacchi 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.

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^[4]) 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.

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^[5].
• 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^[6].

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 minacce 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.

Il seguente esempio è stato originalmente proposto nel RFC 2617, qui è stato esteso per mostrare le richieste e le risposte attese. Da tenere presente che qui si tratta del solo codice quality of protection "auth" (autenticazione) - dal aprile 2005, solo Opera e Konqueror sopportano "auth-int" (autenticazione con protezione dell'integrità). Sebbene l'esempio accenna la versione HTTP 1.1, lo schema può essere aggiunto a un server che utilizza la versione 1.0, come mostrato qui.

Questa tipica transazione consiste dei seguenti passi:

1. Il client chiede una pagina che richiede un'autenticazione, però non fornisce un username e una password. Tipicamente succede, perché l'utente ha inserito l'indirizzo oppure ha seguito un link alla pagina.
2. Il server risponde col codice 401 "Unauthorized", fornendo un realm di autenticazione e un valore mono uso, generato casualmente, cioè la nonce.
3. A questo punto, il browser presenta il realm di autenticazione (tipicamente una descrizione del computer oppure del sistema al quale si sta accedendo) all'utente e richiede un username e una password. Ora l'utente può decidere di cancellare la transazione.
4. Una volta forniti l'username e la password, il client rimanda la stessa richiesta aggiungendo il header d'autenticazione che include il codice di risposta.
5. In questo esempio, il server accetta l'autenticazione e risponde con la pagina richiesta. Se le credenziali fornite sono invalidi o sbagliati il server potrebbe rispondere con il codice "401"e si ritorna al punto 3.

Richiesta del client (senza autenticazione)

 GET /dir/index.html HTTP/1.0
 Host: localhost

Risposta del server

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>

Richiesta del client (username "Mufasa", password "Circle Of Life")

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

(followed by a blank line, as before).

Risposta del server

HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

Il valore della risposta è calcolato in tre passi (dove i valori vengono combinati essi sono delimitati da due punti).

1. La hash MD5 del realm, username e password viene calcolata. Il risultato è HA1.
2. La hash MD5 del metodo e digest Uniform Resource Identifier viene calcolata (ad esempio "GET" e "/dir/index.html"). Il risultato è HA2.
3. Viene calcolalta la hash MD5 di HA1, server nonce (nonce), request counter (nc), client nonce (cnonce), quality of protection code (qop) e HA2. Il risultato è il valore della risposta fornito dal client.

Siccome il server ha le stesse informazioni che ha il client, la risposta può essere verificata eseguendo gli stessi calcoli. Nell'esempio prima il risultato è formato nel ssguente modo, dove MD5() rappresenta una funzione usata per il calcolo della hash MD5, i backslash (\) rappresentano una continuazione e le citazioni mostrate non sono usate nei calcoli.

Ogni passaggio ha i seguenti risultati nell'esempio:

   HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
       = 939e7578ed9e3c518a452acee763bce9

   HA2 = MD5( "GET:/dir/index.html" )
       = 39aff3a2bab6126f332b942af96d3366

   Risposta = MD5( "939e7578ed9e3c518a452acee763bce9:\
                    dcd98b7102dd2f0e8b11d0f600bfb0c093:\
                    00000001:0a4f113b:auth:\
                    39aff3a2bab6126f332b942af96d3366" )
            = 6629fae49393a05397450978507c4ef1

A questo punto il client può mandare un'altra richiesta, riutilizzando il valore della nonce del server (il server fornisce una nonce nuova per ogni risposta 401), però fornendo una nuova client nonce (cnonce).Per le richieste successive, il valore contatore esadecimale di richieste (nc) deve essere maggiore dell'ultimo valore usato-altrimenti un attaccante potrebbe ripetere una vecchia richiesta con le stesse credenziali. Sta al server assicurarsi che il valore del contatore incrementa ogni volta che fornisce un valore nonce nuovo, rifiutando le richieste sbagliate. Ovviamente cambiando il metodo, URI oppure il valore del contatore risulterà in un valore di risposta diverso.

Il server deve memorizzare i valori nonce che ha recentemente generato. Potrebbe inoltre memorizzare quando ha fornito i valori nonce, faccendogli scadere dopo una quantità di tempo. Se viene usato un valore scaduto, il server dovrebbe rispondere con "401" ed aggiungere stale=TRUE al header di autenticazione, indicando che il client deve fare una nuova richiesta con la nuova nonce, senza richiedere l'username e password all'utente.

Il server non deve conservare i valori nonce-può semplicemente assumere che qualunque valore sconosciuto sia scaduto. Non sarà possibile far scadere il server nonce immediatamente, siccome il client non riuscirebbe ad usare la nonce.

.htdigest è un flat file usato per la memorizzazione degli username, realm e password per la digest authentication gli Apache HTTP Server. Il nome del file è passato alla configurazione htaccess, e può essere chiamato con altri nome, però ".htdigest" è il nome più comune. Il nome comincia con un punto, perché la maggior parte dei sistemi operativi Unix-like considerano ogni file che contiene un punto all'inizio del proprio nome come un file nascosto. Questo file è aggiornato con il commando "htdigest" della shell che può aggiungere e aggiornare gli utenti e codifica le password per l'utilizzo.

Il commando "htdigest" si trova nel package apache2-utils contenuto nei sistemi dpkg e in httpd-tools contenuto nei sistemi RPM Package Manager.

La sintassi del commando htdigest è la seguente:^[7]

htdigest [ -c ] passwdfile realm username

Il formato del file .htdigest è il seguente:^[7]

user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379

Session Initiation Protocol (SIP) usa praticamente lo stesso algoritmo di digest authentication. È specificato nel RFC 3261.

Digest access authentication è implementato dalla maggior parte dei browser, alcune implementazioni contengono delle caratteristiche, ad esempio il controllo auth-int o l'algoritmo MD5-sess. Se il server obbliga l'utilizzo di queste caratteristiche facoltative, alcuni client potrebbero non riuscire a connettersi.

• Amaya
• Basati su Gecko: (non includono auth-int^[8])
  • Mozilla Application Suite
  • Mozilla Firefox
  • Netscape 7+
• iCab 3.0.3+
• Basati su KHTML- e WebKit: (non includono auth-int^[9])
  • iCab 4
  • Konqueror
  • Google Chrome
  • Safari
• Basati su Tasman:
  • Internet Explorer Macintosh Edition
• Basati su Trident:
  • Internet Explorer 5+^[10] (non includono auth-int)
• Basati su Presto:
  • Opera
  • Opera Mobile
  • Opera Mini
  • Nintendo DS Browser
  • Nokia 770 Browser
  • Sony Mylo Browser
  • Wii Internet Channel Browser

Portale Sicurezza informatica: accedi alle voci di Teknopedia che trattano di sicurezza informatica