Digest access authentication: differenze tra le versioni

Versione delle 02:27, 16 dic 2017

Versione delle 16:09, 16 dic 2017

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

Line 52 ⟶ 51:

|author1=Jongsung Kim |author2=Alex Biryukov |author3=Bart Preneel |author4=Seokhie Hong | publisher = [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 ==

=== 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>{{cite web

| url = https://community.jboss.org/wiki/DIGESTAuth

| title = DIGEST Authentication (4.0.4+)

| author = Scott Stark

| date = 2005-10-08

| publisher = [[JBoss]]

}}</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:

*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>{{cite web

| url = https://tools.ietf.org/html/rfc2617#section-4.13

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

| date = June 1999

| publisher = [[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: {{cite web

| url = http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

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

| date = January 31, 2014

| publisher = 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]]/[[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.

== Note ==

{{Reflist|group=note}}

{{Portale|informatica}}