Digest access authentication: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
mNessun oggetto della modifica |
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti. |
||
| (35 versioni intermedie di 20 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 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]].
== Descrizione ==
Line 11 ⟶ 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 36 ⟶ 34:
:<math>\mathrm{risposta} = \mathrm{MD5}\Big( \mathrm{HA1} : \mathrm{nonce} : \mathrm{HA2} \Big) </math>
== 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]], 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]].
== Considerazioni sull'autenticazione 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 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
|dataarchivio= 18 ottobre 2015
|urlarchivio= https://web.archive.org/web/20151018155102/https://community.jboss.org/wiki/DIGESTAuth
|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 [[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 [[Attacco man in the middle|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<ref>{{Cita web|url= https://tools.ietf.org/html/rfc2617#section-4.13
|titolo= HTTP Authentication: Basic and Digest Access Authentication: Storing passwords
|data= 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">{{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
|editore= National Institute of Standards and Technology
}}</ref>.
=== Protocolli di autenticazione alternativi ===
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 [[Kerberos]] o [[SPNEGO]], usato per esempio da [[Internet Information Services|Microsoft IIS]] per Integrated Windows Authentication.
*[[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 ''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.
== Esempio ==
Il seguente esempio è stato originalmente proposto nel RFC 2617, qui è stato esteso per mostrare le [[Hypertext Transfer Protocol#Messaggio di richiesta|richieste]] e le [[Hypertext Transfer Protocol#Messaggio 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 HTTP#401 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.
# 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):
<syntaxhighlight lang="http">
GET /dir/index.html HTTP/1.0
Host: localhost
</syntaxhighlight>
; Risposta del server:
<syntaxhighlight lang="http">
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>
</syntaxhighlight>
; Richiesta del client (username "Mufasa", password "Circle Of Life"):
<syntaxhighlight lang="http">
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"
</syntaxhighlight>
(followed by a blank line, as before).
; Risposta del server:
<syntaxhighlight lang="http">
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
</syntaxhighlight>
----
Il valore della risposta è calcolato in tre passi (dove i valori vengono combinati essi sono delimitati da due punti).
# La hash MD5 del realm, username e password viene calcolata. Il risultato è HA1.
# La hash MD5 del metodo e digest [[Uniform Resource Identifier]] viene calcolata (ad esempio "GET" e "/dir/index.html"). Il risultato è HA2.
# 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 <code>MD5()</code> 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 [[Codici di stato HTTP#401 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 HTTP#401 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.
== 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 [[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">{{Cita web|url=https://httpd.apache.org/docs/2.2/programs/htdigest.html|titolo=htdigest - manage user files for digest authentication|opera=apache.org}}</ref>
htdigest [ -c ] ''passwdfile realm username''
Il formato del file .htdigest è il seguente:<ref name="htdigest"/>
user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379
== SIP digest authentication ==
[[Session Initiation Protocol]] (SIP) usa praticamente lo stesso algoritmo di digest authentication. È specificato nel RFC 3261.
== Browser supportati ==
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]]: (non includono auth-int<ref>{{Cita web
|url= https://bugzilla.mozilla.org/show_bug.cgi?id=168942
|titolo= Bug 168942 - Digest authentication with integrity protection
|data= 16 settembre 2002
|autore= Emanuel Corthay
|opera= [[Mozilla]]
|accesso= 16 dicembre 2017
|urlarchivio= https://web.archive.org/web/20110609155831/https://bugzilla.mozilla.org/show_bug.cgi?id=168942
|dataarchivio= 9 giugno 2011
|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>{{Cita web|url=https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf
|titolo=HTTP Digest Integrity: Another look, in light of recent attacks
|autore=Timothy D. Morgan
|data=5 gennaio 2010
|editore=vsecurity.com
|urlmorto=sì
|urlarchivio=https://web.archive.org/web/20140714192236/https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf
|dataarchivio=14 luglio 2014
}}</ref>)
** [[iCab]] 4
** [[Konqueror]]
** [[Google Chrome]]
** [[Safari (browser)|Safari]]
* Basati su [[Tasman (motore di rendering)|Tasman]]:
** [[Internet Explorer Macintosh Edition]]
* Basati su [[Trident (motore di rendering)|Trident]]:
** [[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= agosto 2013
}}</ref> (non includono auth-int)
* Basati su [[Presto (motore di rendering)|Presto]]:
** [[Opera (web browser)|Opera]]
** [[Opera Mobile]]
** [[Opera Mini]]
** [[Nintendo DS & DSi Browser|Nintendo DS Browser]]
** [[Nokia 770]] Browser
** [[Sony Mylo]] Browser
** [[Canali Wii|Wii Internet Channel Browser]]
== Note ==
<references />
{{Portale|sicurezza informatica}}
[[Categoria:Sicurezza
| |||