Digest access authentication: differenze tra le versioni

Versione delle 23:07, 19 dic 2017

Versione attuale delle 15:17, 7 gen 2025

(23 versioni intermedie di 17 utenti non mostrate)

Riga 1:

'''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 [[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]].

{{S|sicurezza informatica}}

'''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]].

Line 10 ⟶ 9:

:<math>\mathrm{risposta} = \mathrm{MD5}\Big( \mathrm{HA1} : \mathrm{nonce} : \mathrm{HA2} \Big) </math>

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

Line 37 ⟶ 36:

== L'impatto della sicurezza di MD5 sul digest access authentication ==

I calcoli [[MD5]] usati nel digest authentication HTTP sono usati a "[[Funzione unidirezionale|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 [[Metodo forza bruta|brute-force attack]])-possibilmente con l'aiuto di un [[Attacco a dizionario|dizionario]] o una [[Tabella arcobaleno|tabella arcobaleno]], che sono disponibili per MD5<ref>[http://project-rainbowcrack.com/table.htm Lista di tabelle arcobaleno, Project Rainbowcrack]. Include molteplici tabelle arcobaleno per MD5.</ref>.

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 [[Collisione hash|collisioni hash]] non influenzassero le applicazioni dove il plaintext (es. password) non era conosciuto<ref name="CryptoRes-2004">{{Cita web |titolo= Hash Collision Q&A |url= http://www.cryptography.com/cnews/hash.html |data= 16 febbraio 2005 |editore= Cryptography Research |urlarchivio= https://web.archive.org/web/20100306180648/http://www.cryptography.com/cnews/hash.html |dataarchivio= 6 marzo 2010}}</ref>. Tuttavia affermazioni nel 2006<ref>{{Cita web|url= https://eprint.iacr.org/2006/187.pdf |titolo= On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1 |autore=Jongsung Kim |autore2=Alex Biryukov |autore3=Bart Preneel |autore4=Seokhie Hong |editore= [[International Association for Cryptologic Research|IACR]]}}</ref> 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]].

|url= http://www.cryptography.com/cnews/hash.html

|data= 16 febbraio 2005

|editore= [https://en.wikipedia.org/wiki/Cryptography_Research Cryptography Research]

|urlarchivio= https://web.archive.org/web/20100306180648/http://www.cryptography.com/cnews/hash.html

|dataarchivio= 6 marzo 2010

}}</ref>. Tuttavia affermazioni nel 2006<ref>{{Cita web|url= https://eprint.iacr.org/2006/187.pdf

|titolo= On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1

|autore1=Jongsung Kim |autore2=Alex Biryukov |autore3=Bart Preneel |autore4=Seokhie Hong |editore= [https://en.wikipedia.org/wiki/International_Association_for_Cryptologic_Research IACR]

}}</ref> 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|replay attack]].

== Considerazioni sull'autenticazione HTTP digest ==

Line 54 ⟶ 44:

=== Vantaggi ===

Http digest authentication è stata progettata per essere piú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 [[WildFly|JBoss]]<ref>{{Cita web
|url= https://community.jboss.org/wiki/DIGESTAuth

|titolo= DIGEST Authentication (4.0.4+)

|autore= Scott Stark

|data= 8 ottobre 2005

|editore= [[JBoss]]

|accesso= 16 dicembre 2017

}}</ref>) di memorizzare la HA1 anziché la password stessa.

|dataarchivio= 18 ottobre 2015

|urlarchivio= https://web.archive.org/web/2010030618064820151018155102/httphttps://wwwcommunity.cryptographyjboss.comorg/cnewswiki/hash.htmlDIGESTAuth

|urlmorto= sì

}}</ref>) 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 [[attacco con testo in chiaro scelto|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 [[Protocollo Kerberos|Kerberos]].

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

Line 78 ⟶ 73:

*Alcuni server impongono che le password siano memorizzate usando criptazione reversibile. Però è possibile memorizzare il valore digested dell'username, realm e password<ref>{{Cita web|url= https://tools.ietf.org/html/rfc2617#section-4.13

|titolo= HTTP Authentication: Basic and Digest Access Authentication: Storing passwords

|data= June giugno 1999

|editore= [[IETF]]

}}</ref>.

*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 [[Federal Information Processing Standard|FIPS]], HTTP digest authentication non funzionerà con moduli di crittografria certificati in FIPS<ref name="FIPS approved functions" reference group="note">The following is a list of FIPS approved algorithms: {{Cita web|url= http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

|titolo= Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules

|data= 31 gennaio 2014

Line 92 ⟶ 87:

Alcuni protocolli di autenticazione robusti per applicazioni web-based:

*Autenticazione [[chiave pubblica|Public key]] usando un certificato client (solitamente usato con [[HTTPS]]/[[Secure Sockets Layer|SSL]] [[Certificato digitale|client certificate]]).

*Autenticazione [[Protocollo Kerberos|Kerberos]] o [https://en.wikipedia.org/wiki/SPNEGO [SPNEGO]], usato per esempio da [[Internet Information Services|Microsoft IIS]] per [https://en.wikipedia.org/wiki/Integrated_Windows_Authentication Integrated Windows Authentication].

*[https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol [Secure Remote Password protocol]] (preferibilmente usato nel layer [[HTTPS]]/[[Transport Layer Security|TLS]]). Seppure non usato nei browser convenzionali.

L'approccio più comune è nell'uso del protocollo [https://en.wikipedia.org/wiki/HTTP%2BHTML_form-based_authentication ''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.

Questi protocolli cleartext meno robusti usati insieme alla criptazione di rete HTTPS sono una soluzione per molte minaccieminacce 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.

== Esempio ==

Il seguente esempio è stato originalmente proposto nel RFC 2617, qui è stato esteso per mostrare le [[Hypertext_Transfer_ProtocolHypertext Transfer Protocol#Messaggio_di_richiestaMessaggio di richiesta|richieste]] e le [[Hypertext_Transfer_ProtocolHypertext Transfer Protocol#Messaggio_di_rispostaMessaggio di risposta|risposte]] attese. Da tenere presente che qui si tratta del solo codice quality of protection "auth" (autenticazione) - dal aprile 2005, solo [[Opera (browser)|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:

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

# Il server risponde col codice [[Codici_di_stato_HTTPCodici di stato HTTP#401_Unauthorized401 Unauthorized|401 "Unauthorized"]], fornendo un realm di autenticazione e un valore mono uso, generato casualmente, cioè la [[nonce]].

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

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

Line 116 ⟶ 110:

; Richiesta del client (senza autenticazione):

<sourcesyntaxhighlight lang="http">

GET /dir/index.html HTTP/1.0

Host: localhost

</syntaxhighlight>

</source>

; Risposta del server:

<sourcesyntaxhighlight lang="http">

HTTP/1.0 401 Unauthorized

Server: HTTPd/0.9

Line 143 ⟶ 137:

</body>

</html>

</syntaxhighlight>

</source>

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

<sourcesyntaxhighlight lang="http">

GET /dir/index.html HTTP/1.0

Host: localhost

Line 157 ⟶ 151:

response="6629fae49393a05397450978507c4ef1",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

</syntaxhighlight>

</source>

(followed by a blank line, as before).

; Risposta del server:

<sourcesyntaxhighlight lang="http">

HTTP/1.0 200 OK

Server: HTTPd/0.9

Line 167 ⟶ 161:

Content-Type: text/html

Content-Length: 7984

</syntaxhighlight>

</source>

----

Line 193 ⟶ 187:

= 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 [[Codici_di_stato_HTTPCodici di stato HTTP#401_Unauthorized401 Unauthorized|risposta 401]]), però fornendo una nuova client nonce (cnonce).Per le richieste successive, il valore [[contatore]] [[Sistema numerico esadecimale|esadecimale]] di richieste (nc) deve essere maggiore dell'ultimo valore usato-altrimenti un attaccante potrebbe [[replay attack|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 [[Codici_di_stato_HTTPCodici di stato HTTP#401_Unauthorized401 Unauthorized|"401"]] ed aggiungere <code>stale=TRUE</code> 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.

Line 201 ⟶ 195:

== 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 [https://en.wikipedia.org/wiki/.htaccess .[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 (informatica)|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:<ref name="htdigest">{{citeCita web|url=httphttps://httpd.apache.org/docs/2.2/programs/htdigest.html|titletitolo=htdigest - manage user files for digest authentication|workopera=apache.org}}</ref>

htdigest [ -c ] ''passwdfile realm username''

Il formato del file .htdigest è il seguente:<ref name="htdigest">{{cite web|url=http://httpd.apache.org/docs/2.2/programs/htdigest.html|title=htdigest - manage user files for digest authentication|work=apache.org}}</ref>

user1:Realm:5ea41921c65387d904834f8403185412

user2:Realm:734418f1e487083dc153890208b79379

Line 214 ⟶ 208:

== SIP digest authentication ==

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

== Browser supportati ==

Line 220 ⟶ 214:

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 (browser)|Amaya]]

* Basati su [[Gecko (layout engine)|Gecko]]: (non includono auth-int<ref>{{citeCita web

| url = https://bugzilla.mozilla.org/show_bug.cgi?id=168942

| title titolo= Bug 168942 - Digest authentication with integrity protection

|data= date16 =settembre 2002-09-16

| author autore= Emanuel Corthay

| work opera= [[Mozilla]]

|accesso= 16 dicembre 2017

}}</ref>)

|urlarchivio= https://web.archive.org/web/20110609155831/https://bugzilla.mozilla.org/show_bug.cgi?id=168942

|dataarchivio= 69 marzogiugno 20102011

|urlmorto= sì

}}</ref>)

** [[Mozilla Application Suite]]

** [[Mozilla Firefox]]

** [[Netscape Navigator|Netscape 7+]]

* [[ICab|iCab 3.0.3+]]

* Basati su [[KHTML]]- e [[WebKit]]: (non includono auth-int<ref>{{citeCita web|url=https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf

|titletitolo=HTTP Digest Integrity: Another look, in light of recent attacks

|url=https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf

|authorautore=Timothy D. Morgan

|title=HTTP Digest Integrity: Another look, in light of recent attacks

|data=5 gennaio 2010

|author=Timothy D. Morgan

|publishereditore=vsecurity.com

|date=2010-01-05

|urlmorto=sì

|publisher=vsecurity.com

|urlurlarchivio=https://web.archive.org/web/20140714192236/https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf

|deadurl=yes

|dataarchivio=14 luglio 2014

|archiveurl=https://web.archive.org/web/20140714192236/https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf

}}</ref>)

|archivedate=2014-07-14

|df=

}}</ref>)

** [[iCab]] 4

** [[Konqueror]]

Line 250 ⟶ 246:

** [[Internet Explorer Macintosh Edition]]

* Basati su [[Trident (motore di rendering)|Trident]]:

** [[Internet Explorer 5|Internet Explorer 5+]]<ref>{{citeCita web|url= https://technet.microsoft.com/en-us/library/cc738318(v=ws.10).aspx

| title titolo= TechNet Digest Authentication

| url = https://technet.microsoft.com/en-us/library/cc738318(v=ws.10).aspx

|data= 16 febbraioagosto 20052013

| title = TechNet Digest Authentication

| date = August 2013

}}</ref> (non includono auth-int)

* Basati su [[Presto (motore di rendering)|Presto]]:

Line 259 ⟶ 254:

** [[Opera Mobile]]

** [[Opera Mini]]

** [https://en.wikipedia.org/wiki/Nintendo_DS_%26_DSi_Browser[Nintendo DS & DSi Browser|Nintendo DS Browser]]

** [[Nokia 770]] Browser

** [https://en.wikipedia.org/wiki/Mylo_(Sony) [Sony Mylo]] Browser

** [https://en.wikipedia.org/wiki/Internet_Channel[Canali Wii|Wii Internet Channel Browser]]

== Note ==

<references />

{{Reflist|group=note}}

{{Portale|sicurezza informatica}}

[[Categoria:Sicurezza informaticadi rete]]