Digest access authentication: differenze tra le versioni

Versione delle 11:34, 15 apr 2023

Versione attuale delle 15:17, 7 gen 2025

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

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

Riga 61:

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