Digest access authentication: differenze tra le versioni

Versione delle 16:35, 27 gen 2018

Versione delle 10:40, 17 mag 2018

Riga 1:

{{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 39 ⟶ 38:

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]], 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= [[:en: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 |autore1autore=Jongsung Kim |autore2=Alex Biryukov |autore3=Bart Preneel |autore4=Seokhie Hong |editore= [[:en: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]].

== Considerazioni sull'autenticazione HTTP digest ==

Line 69 ⟶ 68:

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

Line 85 ⟶ 84:

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

*Autenticazione [[Protocollo Kerberos|Kerberos]] o <ref>[[:en:SPNEGO]]</ref>, usato per esempio da [[Internet Information Services|Microsoft IIS]] per <ref>[[:en:Integrated Windows Authentication]]</ref>.

*<ref>[[:en:Secure Remote Password protocol]]</ref> (preferibilmente usato nel layer [[HTTPS]]/[[Transport Layer Security|TLS]]). Seppure non usato nei browser convenzionali.

L'approccio più comune è nell'uso del protocollo <ref>[[:en:HTTP+HTML form-based authentication]]</ref> o il meno comune [[Basic access authentication]].

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 183 ⟶ 182:

= 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 204 ⟶ 203:

== SIP digest authentication ==

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

== Browser supportati ==

Line 239 ⟶ 238:

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

|titolo= TechNet Digest Authentication

|data= August agosto 2013

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

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

Line 249 ⟶ 248:

** <ref>[[:en:Mylo (Sony)|Sony Mylo]]</ref> Browser

** <ref>[[:en:Internet Channel|Wii Internet Channel Browser]]</ref>

== Note ==

<references />

{{Reflist|group=note}}

{{Portale|informatica}}