Digest access authentication: differenze tra le versioni

Versione delle 12:13, 10 lug 2019

Versione attuale delle 15:17, 7 gen 2025

(12 versioni intermedie di 10 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]].

Riga 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 |autore=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ò, attachiattacchi 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 ==

Riga 48:

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/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 [[Protocollo Kerberos|Kerberos]].

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

Line 82 ⟶ 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 <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 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.

Line 105 ⟶ 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 132 ⟶ 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 146 ⟶ 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 156 ⟶ 161:

Content-Type: text/html

Content-Length: 7984

</syntaxhighlight>

</source>

----

Line 190 ⟶ 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 <ref>[[:en:.htaccess]]</ref>, 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]].

Line 210 ⟶ 215:

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

}}</ref>)

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

Line 225 ⟶ 235:

|data=5 gennaio 2010

|editore=vsecurity.com

|urlmorto=yessì

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

|dataarchivio=14 luglio 2014

Line 244 ⟶ 254:

** [[Opera Mobile]]

** [[Opera Mini]]

** <ref>[[:en:Nintendo DS & DSi Browser|Nintendo DS Browser]]</ref>

** [[Nokia 770]] Browser

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

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

== Note ==

<references />

{{Portale|sicurezza informatica}}

[[Categoria:Sicurezza informaticadi rete]]