Digest access authentication: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti. |
|||
| (25 versioni intermedie di 19 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
▲'''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 [[
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=
|data= 16 febbraio 2005▼
|urlarchivio= https://web.archive.org/web/20100306180648/http://www.cryptography.com/cnews/hash.html▼
|dataarchivio= 6 marzo 2010▼
== Considerazioni sull'autenticazione HTTP digest ==
Line 54 ⟶ 44:
=== Vantaggi ===
Http digest authentication è stata progettata per essere
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/
|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 [[
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=
|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
|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 [[
*[
L'approccio più comune è nell'uso del protocollo
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
== Esempio ==
Il seguente esempio è stato originalmente proposto nel RFC 2617, qui è stato esteso per mostrare le [[
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,
# Il server risponde col codice [[
# 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):
<
GET /dir/index.html HTTP/1.0
Host: localhost
</syntaxhighlight>
; Risposta del server:
<
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Line 143 ⟶ 137:
</body>
</html>
</syntaxhighlight>
; Richiesta del client (username "Mufasa", password "Circle Of Life"):
<
GET /dir/index.html HTTP/1.0
Host: localhost
Line 157 ⟶ 151:
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
</syntaxhighlight>
(followed by a blank line, as before).
; Risposta del server:
<
HTTP/1.0 200 OK
Server: HTTPd/0.9
Line 167 ⟶ 161:
Content-Type: text/html
Content-Length: 7984
</syntaxhighlight>
----
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 [[
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 [[
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 [
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">{{
htdigest [ -c ] ''passwdfile realm username''
Il formato del file .htdigest è il seguente:<ref name="htdigest"
user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379
Line 214 ⟶ 208:
== SIP digest authentication ==
[[Session Initiation Protocol]] (SIP) usa praticamente lo stesso algoritmo di digest authentication.
== 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 [[
|
|
|data=
|
|
|accesso= 16 dicembre 2017
}}</ref>)▼
|urlarchivio= https://web.archive.org/web/20110609155831/https://bugzilla.mozilla.org/show_bug.cgi?id=168942
|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>{{
|url=https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf ▼
▲ |title=HTTP Digest Integrity: Another look, in light of recent attacks
|data=5 gennaio 2010
▲ |author=Timothy D. Morgan
|urlmorto=sì
▲ |publisher=vsecurity.com
▲ |
|dataarchivio=14 luglio 2014
▲ }}</ref>)
▲}}</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>{{
▲ | title = TechNet Digest Authentication
}}</ref> (non includono auth-int)
* Basati su [[Presto (motore di rendering)|Presto]]:
Line 259 ⟶ 254:
** [[Opera Mobile]]
** [[Opera Mini]]
** [
** [[Nokia 770]] Browser
** [
** [
== Note ==
<references />
{{Portale|sicurezza informatica}}
[[Categoria:Sicurezza
| |||