Digest access authentication: differenze tra le versioni

Versione delle 19:55, 16 dic 2017

Versione delle 21:48, 16 dic 2017

Riga 39:

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|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">{{citeCita web|titolo= Hash Collision Q&A

| url = http://www.cryptography.com/cnews/hash.html

| title = Hash Collision Q&A

|data= 16 febbraio 2005

| url = http://www.cryptography.com/cnews/hash.html

| publisher editore= [https://en.wikipedia.org/wiki/Cryptography_Research Cryptography Research]

| date = 2005-02-16

| archiveurl urlarchivio= https://web.archive.org/web/20100306180648/http://www.cryptography.com/cnews/hash.html

| publisher = [https://en.wikipedia.org/wiki/Cryptography_Research Cryptography Research]

|dataarchivio= 6 marzo 2010

| archiveurl = https://web.archive.org/web/20100306180648/http://www.cryptography.com/cnews/hash.html

}}</ref>. Tuttavia affermazioni nel 2006<ref>{{citeCita web|url= https://eprint.iacr.org/2006/187.pdf

| archivedate = 2010-03-06

| title titolo= On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1

}}</ref>. Tuttavia affermazioni nel 2006<ref>{{cite web

|author1autore1=Jongsung Kim |author2autore2=Alex Biryukov |author3autore3=Bart Preneel |author4autore4=Seokhie Hong | publisher editore= [https://en.wikipedia.org/wiki/International_Association_for_Cryptologic_Research IACR]

| url = https://eprint.iacr.org/2006/187.pdf

| title = On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1

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

Line 61 ⟶ 59:

*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>{{citeCita web|url= https://community.jboss.org/wiki/DIGESTAuth

| title titolo= DIGEST Authentication (4.0.4+)

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

| author autore= Scott Stark

| title = DIGEST Authentication (4.0.4+)

|data= 8 ottobre 2005

| author = Scott Stark

| publisher editore= [[JBoss]]

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

Line 79 ⟶ 76:

*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>{{citeCita web|url= https://tools.ietf.org/html/rfc2617#section-4.13

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

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

| date data= June 1999

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

| publisher editore= [[IETF]]

| 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: {{citeCita web|url= http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

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

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

|data= 31 gennaio 2014

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

| publisher editore= National Institute of Standards and Technology

| date = January 31, 2014

| publisher = National Institute of Standards and Technology

}}</ref>.