Indietro

ⓘ Digest access authentication




                                     

ⓘ 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 dellutente. Può essere utilizzato per confermare lidentità 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 dellinvio 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 è unapplicazione della funzione crittografica di hash MD5 con utilizzo di un valore nonce per prevenire un replay attack.

                                     

1. 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 allautenticazione è formata così:

H A 1 = M D 5 A 1 = M D 5 u s e r n a m e: r e a l m: p a s w o r d {\displaystyle \mathrm {HA1} =\mathrm {MD5} {\Big }\mathrm {A1} {\Big}=\mathrm {MD5} {\Big }\mathrm {username}:\mathrm {realm}:\mathrm {password} {\Big}} H A 2 = M D 5 A 2 = M D 5 m e t h o d: d i g e s t U R I {\displaystyle \mathrm {HA2} =\mathrm {MD5} {\Big }\mathrm {A2} {\Big}=\mathrm {MD5} {\Big }\mathrm {method}:\mathrm {digestURI} {\Big}} r i s p o s t a = M D 5 H A 1: n o n c e: H A 2 {\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 allautenticazione digest; "quality of protection" qop, contatore nonce incrementato dal client e un nonce generato casualmente dal client.

Se lalgoritmo di hash è MD5 oppure non è specificato, allora HA1 è:

H A 1 = M D 5 A 1 = M D 5 u s e r n a m e: r e a l m: p a s w o r d {\displaystyle \mathrm {HA1} =\mathrm {MD5} {\Big }\mathrm {A1} {\Big}=\mathrm {MD5} {\Big }\mathrm {username}:\mathrm {realm}:\mathrm {password} {\Big}}

Se lalgorirmo di hash è "MD5-sess" allora HA1 è:

H A 1 = M D 5 A 1 = M D 5 M D 5 u s e r n a m e: r e a l m: p a s w o r d: n o n c e: c n o n c e) {\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 è:

H A 2 = M D 5 A 2 = M D 5 m e t h o d: d i g e s t U R I {\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 è:

H A 2 = M D 5 A 2 = M D 5 m e t h o d: d i g e s t U R I: M D 5 e n t i t y B o d y) {\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 è:

r i s p o s t a = M D 5 H A 1: n o n c e: n o n c e C o u n t: c l i e n t N o n c e: q o p: H A 2 {\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 è:

r i s p o s t a = M D 5 H A 1: n o n c e: H A 2 {\displaystyle \mathrm {risposta} =\mathrm {MD5} {\Big }\mathrm {HA1}:\mathrm {nonce}:\mathrm {HA2} {\Big}}
                                     

2. Limpatto della sicurezza di MD5 sul digest access authentication

I calcoli MD5 usati nel digest authentication HTTP sono usati a "una via", è difficile determinare linput originale conoscendo loutput. Se però la password è troppo semplice, è possibile provare tutti gli input possibili e trovare un output abbinato un brute-force attack-possibilmente con laiuto 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 dautenticazione, quali ad esempio lo sviluppo di keyed-hash message authentication codeHMAC. 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ò, 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.

                                     

3.1. Considerazioni sullautenticazione 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 lutente accede ad un sito web sbagliato.
  • La password non è usata direttamente nel digest, ma piuttosto la HA1=MD5username: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.
  • Il server può inoltre mantenere una lista di nonce recentemente usati per prevenirne il riuso.
  • 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.


                                     

3.2. Considerazioni sullautenticazione HTTP digest 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 lautenticazione a chiave pubblica o Kerberos.

In termini di sicurezza, ci sono parecchi svantaggi nellusare digest access authentication:

  • Alcuni server impongono che le password siano memorizzate usando criptazione reversibile. Però è possibile memorizzare il valore digested dellusername, realm e password.
  • Previene luso di hash delle password più robuste ad esempio bcrypt nel memorizzare le password.
  • Autenticazione Kerberos o, usato per esempio da Microsoft IIS per.
  • preferibilmente usato nel layer HTTPS/TLS. Seppure non usato nei browser convenzionali.
  • 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 lidentità del server.

Lapproccio più comune è nelluso del protocollo 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 lURL al quale sta accedendo per non mandare la password ad un server non affidabile, che potrebbe risultare in un attacco Phishing. Lutente, però, spesso non lo fa, perciò il phishing è diventato la falla nella sicurezza più comune.

                                     

4. Esempio

Il seguente esempio è stato originalmente proposto nel RFC 2617, qui è stato esteso per mostrare le richieste 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 dellintegrità. Sebbene lesempio 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:

  • In questo esempio, il server accetta lautenticazione 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.
  • A questo punto, il browser presenta il realm di autenticazione tipicamente una descrizione del computer oppure del sistema al quale si sta accedendo allutente e richiede un username e una password. Ora lutente può decidere di cancellare la transazione.
  • Il client chiede una pagina che richiede unautenticazione, però non fornisce un username e una password. Tipicamente succede, perché lutente ha inserito lindirizzo oppure ha seguito un link alla pagina.
  • Una volta forniti lusername e la password, il client rimanda la stessa richiesta aggiungendo il header dautenticazione che include il codice di risposta.
  • Il server risponde col codice 401 "Unauthorized", fornendo un realm di autenticazione e un valore mono uso, generato casualmente, cioè la nonce.
Richiesta del client senza autenticazione Risposta del server Richiesta del client username "Mufasa", password "Circle Of Life"

followed by a blank line, as before.

Risposta del server

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

  • 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.
  • La hash MD5 del metodo e digest Uniform Resource Identifier viene calcolata ad esempio "GET" e "/dir/index.html". Il risultato è HA2.
  • La hash MD5 del realm, username e password viene calcolata. Il risultato è HA1.

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

Ogni passaggio ha i seguenti risultati nellesempio:

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 unaltra 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 dellultimo 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 lusername e password allutente.

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.

                                     

5. Il file.htdigest

.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, 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 allinizio 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 lutilizzo.

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:

htdigest passwdfile realm username

Il formato del file.htdigest è il seguente:

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


                                     

6. Browser supportati

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

  • Mozilla Application Suite
  • Netscape 7+
  • Mozilla Firefox
  • Amaya
  • Basati su Gecko: non includono auth-int
  • Google Chrome
  • Konqueror
  • Safari
  • Basati su KHTML- e WebKit: non includono auth-int
  • iCab 4
  • iCab 3.0.3+
  • Basati su Tasman
  • Internet Explorer Macintosh Edition
  • Internet Explorer 5+ non includono auth-int
  • Basati su Trident
  • Opera Mobile
  • Basati su Presto
  • Nokia 770 Browser
  • Opera Mini
  • Browser
  • Opera
                                     
  • basic access authentication è un metodo per fornire credenziali di accesso tra client e server. L implementazione HTTP Basic authentication BA è la
  • In crittografia un message authentication code MAC è un piccolo blocco di dati utilizzato per garantire l autenticazione e integrità di un messaggio
  • Simple Authentication and Security Layer SASL è un framework software per autenticazione e sicurezza nei protocolli Internet. Disaccoppia i meccanismi
  • authentication code or protected checksum L espressione message integrity code è usata frequentemente come sinonimo di message authentication code
  • fallita o non può essere fornita. Vedi anche basic access authentication e digest access authentication 402 Payment Required L intendimento originale prevedeva
  • riservatezza del contenuto ed aggiunge al formato dei messaggi un campo digest per garantire l autenticazione tra due entità. Community - Based Simple Network

Anche gli utenti hanno cercato:

...
...
...