Autenticazione dell'accesso al digest - Digest access authentication

L'autenticazione dell'accesso al digest è uno dei metodi concordati che un server Web può utilizzare per negoziare credenziali, come nome utente o password, con il browser Web di un utente . Questo può essere utilizzato per confermare l'identità di un utente prima di inviare informazioni sensibili, come la cronologia delle transazioni bancarie online. Applica una funzione di hash al nome utente e alla password prima di inviarli in rete. Al contrario, l'autenticazione dell'accesso di base utilizza la codifica Base64 facilmente reversibile anziché l'hashing, rendendola non sicura a meno che non venga utilizzata insieme a TLS .

Tecnicamente, l'autenticazione digest è un'applicazione di hashing crittografico MD5 con l'utilizzo di valori nonce per prevenire attacchi di replay . Utilizza il protocollo HTTP .

Panoramica

L'autenticazione dell'accesso al digest è stata originariamente specificata da RFC 2069 ( An Extension to HTTP: Digest Access Authentication ). La RFC 2069 specifica approssimativamente uno schema di autenticazione digest tradizionale con sicurezza mantenuta da un valore nonce generato dal server . La risposta di autenticazione è formata come segue (dove HA1 e HA2 sono nomi di variabili stringa):

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)

Un hash MD5 è un valore a 16 byte. I valori HA1 e HA2 utilizzati nel calcolo della risposta sono la rappresentazione esadecimale (in minuscolo) degli hash MD5 rispettivamente.

RFC 2069 è stato successivamente sostituito da RFC 2617 ( autenticazione HTTP: autenticazione di accesso di base e digest ). RFC 2617 ha introdotto una serie di miglioramenti di sicurezza facoltativi per assimilare l'autenticazione; "qualità della protezione" (qop) , contatore nonce incrementato dal client e nonce casuale generato dal client. Questi miglioramenti sono progettati per proteggere, ad esempio, dalla crittoanalisi degli attacchi con testo in chiaro scelto .

Se il valore della direttiva dell'algoritmo è "MD5" o non specificato, allora HA1 è

HA1 = MD5(username:realm:password)

Se il valore della direttiva dell'algoritmo è "MD5-sess", allora HA1 è

HA1 = MD5(MD5(username:realm:password):nonce:cnonce)

Se il valore della direttiva qop è "auth" o non è specificato, allora HA2 è

HA2 = MD5(method:digestURI)

Se il valore della direttiva qop è "auth-int", allora HA2 è

HA2 = MD5(method:digestURI:MD5(entityBody))

Se il valore della direttiva qop è "auth" o "auth-int", calcola la risposta come segue:

response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

Se la direttiva qop non è specificata, calcola la risposta come segue:

response = MD5(HA1:nonce:HA2)

Quanto sopra mostra che quando qop non è specificato, viene seguito lo standard RFC 2069 più semplice.

A settembre 2015, RFC 7616 ha sostituito RFC 2617 aggiungendo 4 nuovi algoritmi: "SHA-256", "SHA-256-sess", "SHA-512-256" e "SHA-512-256-sess". La codifica è equivalente agli algoritmi "MD5" e "MD5-sess", con la funzione di hashing MD5 sostituita con SHA-256 e SHA-512-256 . Tuttavia, a partire da luglio 2021, nessuno dei browser più diffusi, inclusi Firefox e Chrome, supporta SHA-256 come funzione di hash. A partire da ottobre 2021, Firefox 93 supporta ufficialmente gli algoritmi "SHA-256" e "SHA-256-sess" per l'autenticazione digest. Tuttavia, manca ancora il supporto per gli algoritmi "SHA-512-256", "SHA-512-256-sess" e l'hashing del nome utente.

Impatto della sicurezza MD5 sull'autenticazione digest

I calcoli MD5 utilizzati nell'autenticazione digest HTTP sono pensati per essere "a senso unico ", il che significa che dovrebbe essere difficile determinare l'input originale quando è noto solo l'output. Se la password stessa è troppo semplice, tuttavia, potrebbe essere possibile testare tutti gli input possibili e trovare un output corrispondente (un attacco di forza bruta ) – magari aiutato da un dizionario o da un elenco di ricerca adatto , che per MD5 è prontamente a disposizione.

Lo schema HTTP è stato progettato da Phillip Hallam-Baker al CERN nel 1993 e non incorpora miglioramenti successivi nei sistemi di autenticazione, come lo sviluppo del codice di autenticazione del messaggio hash con chiave ( HMAC ). Sebbene la struttura crittografica utilizzata sia basata sulla funzione hash MD5, nel 2004 si riteneva generalmente che gli attacchi di collisione non colpissero le applicazioni in cui il testo in chiaro (ovvero la password) non è noto. Tuttavia, le affermazioni nel 2006 causano alcuni dubbi anche su altre applicazioni MD5. Finora, tuttavia, non è stato dimostrato che gli attacchi di collisione MD5 rappresentino una minaccia per l'autenticazione e l'RFC 2617 consente ai server di implementare meccanismi per rilevare alcuni attacchi di collisione e replay .

Considerazioni sull'autenticazione digest HTTP

Vantaggi

L'autenticazione digest HTTP è progettata per essere più sicura rispetto ai tradizionali schemi di autenticazione digest, ad esempio "significativamente più forte di (ad es.) CRAM-MD5 ..." (RFC 2617).

Alcuni dei punti di forza della sicurezza dell'autenticazione digest HTTP sono:

  • La password non viene inviata in chiaro al server.
  • La password non viene utilizzata direttamente nel digest, ma piuttosto HA1 = MD5(username:realm:password). Ciò consente ad alcune implementazioni (ad esempio JBoss ) di memorizzare HA1 anziché la password in chiaro (tuttavia, vedere gli svantaggi di questo approccio)
  • Il client nonce è stato introdotto nella RFC 2617, che consente al client di prevenire attacchi di testo in chiaro scelto , come le tabelle arcobaleno che potrebbero altrimenti minacciare gli schemi di autenticazione digest
  • Il server nonce può contenere timestamp. Pertanto, il server può ispezionare gli attributi nonce inviati dai client, per prevenire attacchi di replay
  • Il server può anche mantenere un elenco di valori nonce del server emessi o utilizzati di recente per impedire il riutilizzo
  • Impedisce il phishing perché la semplice password non viene mai inviata a nessun server, sia esso il server corretto o meno. (I sistemi a chiave pubblica fanno affidamento sulla capacità dell'utente di verificare che l'URL sia corretto.)

Svantaggi

Ci sono diversi inconvenienti con l'autenticazione dell'accesso digest:

  • Il sito Web non ha alcun controllo sull'interfaccia utente presentata all'utente finale.
  • Molte delle opzioni di sicurezza in RFC 2617 sono facoltative. Se la qualità della protezione (qop) non è specificata dal server, il client funzionerà in modalità RFC 2069 legacy con sicurezza ridotta
  • L'autenticazione dell'accesso digest è vulnerabile a un attacco man-in-the-middle (MITM) . Ad esempio, un utente malintenzionato MITM potrebbe indicare ai client di utilizzare l'autenticazione dell'accesso di base o la modalità di autenticazione dell'accesso digest RFC2069 legacy. Per estendere ulteriormente, l'autenticazione dell'accesso digest non fornisce alcun meccanismo per i client per verificare l'identità del server
  • Un server può memorizzare HA1 = MD5(username:realm:password) invece della password stessa. Tuttavia, se l'HA1 memorizzato viene trapelato, un utente malintenzionato può generare risposte valide e accedere ai documenti nel regno con la stessa facilità con cui avrebbe avuto accesso alla password stessa. La tabella dei valori HA1 deve quindi essere protetta con la stessa sicurezza di un file contenente password in chiaro.
  • L'autenticazione dell'accesso al digest impedisce l'uso di un hash della password forte (come bcrypt ) durante la memorizzazione delle password (poiché la password o il nome utente, il dominio e la password digeriti devono essere recuperabili)

Inoltre, poiché l' algoritmo MD5 non è consentito in FIPS , l'autenticazione HTTP Digest non funzionerà con i moduli crittografici certificati FIPS.

Protocolli di autenticazione alternativi

L'approccio di gran lunga più comune consiste nell'utilizzare un protocollo di autenticazione in chiaro basato su modulo HTTP+HTML o, più raramente, l'autenticazione di accesso di base . Questi deboli protocolli in chiaro utilizzati insieme alla crittografia di rete HTTPS risolvono molte delle minacce che l'autenticazione dell'accesso digerisce è progettata per prevenire. Tuttavia, questo utilizzo di HTTPS si affida all'utente finale per verificare con precisione che stanno accedendo all'URL corretto ogni volta per impedire l'invio della propria password a un server non attendibile, il che si traduce in attacchi di phishing . Gli utenti spesso non riescono a farlo, motivo per cui il phishing è diventato la forma più comune di violazione della sicurezza.

Alcuni protocolli di autenticazione forte per le applicazioni basate sul Web che vengono utilizzati occasionalmente includono:

Esempio con spiegazione

L'esempio seguente è stato originariamente fornito nella RFC 2617 e viene qui ampliato per mostrare il testo completo previsto per ogni richiesta e risposta . Si noti che è coperta solo la qualità "auth" (autenticazione) del codice di protezione: a partire da aprile 2005, solo i browser Web Opera e Konqueror sono noti per supportare "auth-int" (autenticazione con protezione dell'integrità). Sebbene la specifica menzioni la versione HTTP 1.1, lo schema può essere aggiunto con successo a un server versione 1.0, come mostrato qui.

Questa transazione tipica consiste nei seguenti passaggi:

  1. Il client richiede una pagina che richiede l'autenticazione ma non fornisce un nome utente e una password. In genere questo è dovuto al fatto che l'utente ha semplicemente inserito l'indirizzo o ha seguito un collegamento alla pagina.
  2. Il server risponde con il codice di risposta 401 "Unauthorized" , fornendo l'area di autenticazione e un valore monouso generato casualmente chiamato nonce .
  3. A questo punto, il browser presenterà all'utente l'area di autenticazione (in genere una descrizione del computer o del sistema a cui si accede) e richiederà un nome utente e una password. L'utente può decidere di annullare a questo punto.
  4. Una volta forniti nome utente e password, il client invia nuovamente la stessa richiesta ma aggiunge un'intestazione di autenticazione che include il codice di risposta.
  5. In questo esempio, il server accetta l'autenticazione e la pagina viene restituita. Se il nome utente non è valido e/o la password non è corretta, il server potrebbe restituire il codice di risposta "401" e il client richiederà nuovamente all'utente.

Richiesta del cliente (nessuna autenticazione)
GET /dir/index.html HTTP/1.0
Host: localhost

(seguito da una nuova riga , sotto forma di un ritorno a capo seguito da un avanzamento riga ).

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 cliente (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"

(seguito da una riga vuota, come prima).

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

(seguito da una riga vuota e dal testo HTML della pagina riservata).


Il valore "risposta" viene calcolato in tre fasi, come segue. Quando i valori sono combinati, sono delimitati da due punti.

  1. Viene calcolato l'hash MD5 del nome utente combinato, dell'area di autenticazione e della password. Il risultato è indicato come HA1.
  2. Viene calcolato l' hash MD5 del metodo combinato e dell'URI digest , ad esempio di "GET"e "/dir/index.html". Il risultato è indicato come HA2.
  3. Viene calcolato l'hash MD5 del risultato combinato HA1, nonce server (nonce), contatore richieste (nc), nonce client (cnonce), codice qualità di protezione (qop) e HA2. Il risultato è il valore di "risposta" fornito dal cliente.

Poiché il server ha le stesse informazioni del client, la risposta può essere verificata eseguendo lo stesso calcolo. Nell'esempio sopra riportato il risultato è formato come segue, dove MD5()rappresenta una funzione utilizzata per calcolare un hash MD5 , le barre rovesciate rappresentano una continuazione e le virgolette mostrate non vengono utilizzate nel calcolo.

Il completamento dell'esempio fornito nella RFC 2617 fornisce i seguenti risultati per ogni passaggio.

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

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

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

A questo punto il client può effettuare un'altra richiesta, riutilizzando il valore nonce del server (il server emette solo un nuovo nonce per ogni risposta "401" ) ma fornendo un nuovo nonce client (cnonce). Per le richieste successive, il contatore di richieste esadecimale (nc) deve essere maggiore dell'ultimo valore utilizzato, altrimenti un utente malintenzionato potrebbe semplicemente " riprodurre " una vecchia richiesta con le stesse credenziali. Spetta al server garantire che il contatore aumenti per ciascuno dei valori nonce che ha emesso, rifiutando in modo appropriato eventuali richieste errate. Ovviamente la modifica del metodo, dell'URI e/o del valore del contatore risulterà in un diverso valore di risposta.

Il server dovrebbe ricordare i valori nonce che ha generato di recente. Può anche ricordare quando è stato emesso ciascun valore nonce, scadendo dopo un certo periodo di tempo. Se viene utilizzato un valore scaduto, il server dovrebbe rispondere con il codice di stato "401" e aggiungerlo stale=TRUEall'intestazione di autenticazione, indicando che il client deve inviare nuovamente con il nuovo nonce fornito, senza richiedere all'utente un altro nome utente e password.

Il server non ha bisogno di conservare alcun valore nonce scaduto: può semplicemente presumere che tutti i valori non riconosciuti siano scaduti. È anche possibile che il server consenta la restituzione di ogni valore nonce solo una volta, sebbene ciò forzi il client a ripetere ogni richiesta. Nota che la scadenza immediata di un server nonce non funzionerà, poiché il client non avrebbe mai la possibilità di usarlo.

Il file .htdigest

.htdigest è un file flat utilizzato per memorizzare nomi utente, realm e password per l'autenticazione digest di Apache HTTP Server . Il nome del file è dato nella configurazione .htaccess e può essere qualsiasi cosa, ma ".htdigest" è il nome canonico. Il nome del file inizia con un punto, perché la maggior parte dei sistemi operativi simili a Unix considera nascosto qualsiasi file che inizia con punto. Questo file viene spesso mantenuto con il comando shell "htdigest" che può aggiungere e aggiornare gli utenti e codificherà correttamente la password per l'uso.

Il comando "htdigest" si trova nel pacchetto apache2-utils sui sistemi di gestione dei pacchetti dpkg e nel pacchetto httpd-tools sui sistemi di gestione dei pacchetti RPM .

La sintassi del comando htdigest:

htdigest [ -c ] passwdfile realm username

Il formato del file .htdigest:

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

Autenticazione digest SIP

Il protocollo SIP ( Session Initiation Protocol ) utilizza sostanzialmente lo stesso algoritmo di autenticazione digest. È specificato dalla RFC 3261.

Implementazione del browser

La maggior parte dei browser ha sostanzialmente implementato le specifiche, alcune escludendo alcune funzionalità come il controllo auth-int o l'algoritmo MD5-sess. Se il server richiede la gestione di queste funzionalità opzionali, i client potrebbero non essere in grado di eseguire l'autenticazione (sebbene mod_auth_digest per Apache non implementi completamente nemmeno RFC 2617).

deprecazioni

A causa degli svantaggi dell'autenticazione Digest rispetto all'autenticazione di base su HTTPS è stata deprecata da molti software, ad esempio:

Guarda anche

Appunti

Riferimenti

link esterno