4. Considerazioni sulla sicurezza (Security Considerations)
4.1 Autenticazione dei client utilizzando l'autenticazione di base (Authentication of Clients using Basic Authentication)
Lo schema di autenticazione di base (Basic Authentication Scheme) non è un metodo sicuro di autenticazione degli utenti, né protegge in alcun modo l'entità trasmessa in chiaro sulla rete fisica. HTTP non impedisce l'utilizzo di schemi di autenticazione aggiuntivi e meccanismi di crittografia per aumentare la sicurezza o l'aggiunta di miglioramenti (come schemi per utilizzare password monouso) all'autenticazione di base.
Il difetto più grave dell'autenticazione di base è che risulta essenzialmente nella trasmissione in chiaro della password dell'utente sulla rete fisica. È questo il problema che l'autenticazione digest (Digest Authentication) tenta di affrontare.
Poiché l'autenticazione di base comporta la trasmissione in chiaro delle password, non dovrebbe essere utilizzata (senza miglioramenti) per proteggere informazioni sensibili o preziose.
Un uso comune dell'autenticazione di base è per scopi di identificazione -- richiedere all'utente di fornire un nome utente e una password come mezzo di identificazione, ad esempio, per raccogliere statistiche di utilizzo accurate su un server. Quando usata in questo modo è allettante pensare che non ci sia pericolo nel suo utilizzo se l'accesso illecito ai documenti protetti non è una preoccupazione principale. Questo è corretto solo se il server emette sia il nome utente che la password agli utenti e, in particolare, non consente all'utente di scegliere la propria password. Il pericolo è che gli utenti ingenui riutilizzano frequentemente una singola password per evitare il compito di mantenere più password.
Se un server permette agli utenti di selezionare le proprie password, allora la minaccia non è solo l'accesso non autorizzato ai documenti sul server ma anche l'accesso non autorizzato a qualsiasi altra risorsa su altri sistemi che l'utente protegge con la stessa password. Inoltre, nel database delle password del server, molte delle password potrebbero anche essere le password degli utenti per altri siti. Il proprietario o l'amministratore di tale sistema potrebbe quindi esporre tutti gli utenti del sistema al rischio di accesso non autorizzato a tutti quegli altri siti se queste informazioni non sono mantenute in modo sicuro.
L'autenticazione di base è anche vulnerabile allo spoofing da parte di server contraffatti. Se un utente può essere indotto a credere di connettersi a un host contenente informazioni protette dall'autenticazione di base quando, in realtà, si sta connettendo a un server o gateway ostile, allora l'attaccante può richiedere una password, memorizzarla per un uso successivo e simulare un errore. Questo tipo di attacco non è possibile con l'autenticazione digest. Gli implementatori di server dovrebbero proteggersi contro la possibilità di questo tipo di contraffazione da parte di gateway o script CGI.
4.2 Autenticazione dei client utilizzando l'autenticazione digest (Authentication of Clients using Digest Authentication)
L'autenticazione digest (Digest Authentication) non fornisce un meccanismo di autenticazione forte, se confrontata con meccanismi basati su chiavi pubbliche.
Tuttavia, è significativamente più forte di (ad esempio) CRAM-MD5, che è stato proposto per l'uso con LDAP [10], POP e IMAP (vedere RFC 2195 [9]). È destinata a sostituire il meccanismo di base molto più debole e ancora più pericoloso.
L'autenticazione digest non offre alcuna protezione della riservatezza oltre a proteggere la password effettiva. Tutto il resto della richiesta e della risposta è disponibile per un intercettatore.
L'autenticazione digest offre solo una protezione dell'integrità limitata per il messaggio in entrambe le direzioni. Se viene utilizzato il meccanismo qop=auth-int, allora le parti del messaggio utilizzate per calcolare i valori della direttiva response dei campi header WWW-Authenticate e Authorization (vedere sezione 3.2 sopra) sono protette. La maggior parte dei campi header e dei loro valori possono essere modificati come parte di un attacco man-in-the-middle.
L'autenticazione digest non può soddisfare le esigenze di molte transazioni HTTP sicure. Per tali esigenze, TLS o SHTTP sono protocolli più appropriati. In particolare, l'autenticazione digest non può essere utilizzata per alcuna transazione per la quale è necessaria la protezione della riservatezza. Tuttavia, l'autenticazione digest è sia utile che appropriata per molte funzioni. Qualsiasi servizio che attualmente utilizza l'autenticazione di base dovrebbe passare all'autenticazione digest il prima possibile.
4.3 Valori nonce ad uso limitato (Limited Use Nonce Values)
Lo schema digest utilizza un nonce specificato dal server per seminare la generazione del valore request-digest (come specificato nella sezione 3.2.2.1 sopra). Come mostrato nell'esempio di nonce nella sezione 3.2.1, il server è libero di costruire il nonce in modo tale che possa essere utilizzato solo da un particolare client, per una particolare risorsa, per un periodo di tempo o numero di utilizzi limitato, o qualsiasi altra restrizione. Ciò rafforza la protezione fornita contro, ad esempio, attacchi replay (vedere 4.5). Tuttavia, va notato che il metodo scelto per generare e verificare il nonce ha anche implicazioni sulle prestazioni e sulle risorse.
4.4 Confronto tra digest e autenticazione di base (Comparison of Digest with Basic Authentication)
Sia l'autenticazione digest che quella di base sono deboli nel senso che potrebbero non impedire l'accesso non autorizzato da parte di un avversario determinato. Tuttavia, il confronto tra le due evidenzia l'utilità, e forse anche la necessità, di sostituire l'autenticazione di base con quella digest.
Per il tipo di transazioni per cui questo protocollo è probabile essere utilizzato, la minaccia maggiore è l'intercettazione della rete. Questo tipo di transazione potrebbe coinvolgere, ad esempio, l'accesso online a un database il cui uso è limitato agli abbonati paganti. Con l'autenticazione di base, un intercettatore può ottenere la password dell'utente. Questo non solo gli permette di accedere a qualsiasi cosa nel database, ma, ciò che spesso è peggio, permetterà l'accesso a qualsiasi altra cosa che l'utente protegge con la stessa password.
Al contrario, con l'autenticazione digest, l'intercettatore ottiene accesso solo alla transazione in questione, e non alla password dell'utente. Le informazioni ottenute dall'intercettatore permetterebbero un attacco replay, ma solo con la stessa richiesta di documento, e anche questo può essere limitato dalla scelta del nonce da parte del server.
4.5 Attacchi replay (Replay Attacks)
Gli attacchi replay con l'autenticazione digest sono tipicamente privi di significato per semplici richieste GET, poiché l'intercettatore ha già visto l'unico documento che potrebbe ottenere riproducendo. Questo perché l'URI del documento richiesto è digerito nella richiesta del client, e il server consegnerà solo quel documento. Al contrario, con l'autenticazione di base, una volta che l'intercettatore ha la password dell'utente, qualsiasi documento protetto da quella password è aperto a lui.
Pertanto, per alcuni scopi, è necessario proteggersi dagli attacchi replay. Le buone implementazioni digest possono farlo in vari modi. Il valore "nonce" creato dal server dipende dall'implementazione, ma se contiene un digest dell'IP del client, un timestamp, l'ETag della risorsa e una chiave privata del server (come raccomandato sopra), allora un attacco replay non è semplice.
Per le applicazioni che non possono tollerare nemmeno la possibilità di attacchi replay, il server può utilizzare valori nonce monouso che non vengono accettati una seconda volta. Questo richiede il sovraccarico del server di ricordare quali valori nonce sono stati utilizzati fino alla scadenza del timestamp del nonce.
4.6 Debolezza creata da più schemi di autenticazione (Weakness Created by Multiple Authentication Schemes)
Quando un server offre più schemi di autenticazione nell'header WWW-Authenticate, il client dovrebbe selezionare lo schema più forte che supporta. Tuttavia, se un attaccante può modificare la risposta per rimuovere lo schema più forte, il client può essere costretto a utilizzare uno schema più debole.
4.7 Attacchi dizionario online (Online dictionary attacks)
Se il server non limita il tasso di tentativi di autenticazione, un attaccante può provare un gran numero di password per indovinare quella corretta. I server dovrebbero limitare il tasso di tentativi di autenticazione falliti da un singolo indirizzo IP.
4.8 Man in the middle
L'autenticazione digest è vulnerabile agli attacchi man-in-the-middle. Un attaccante può intercettare le comunicazioni tra il client e il server e modificare o sostituire i messaggi. L'utilizzo di TLS o altri meccanismi di sicurezza a livello di trasporto può prevenire tali attacchi.
4.9 Attacchi con testo in chiaro scelto (Chosen plaintext attacks)
L'autenticazione digest è vulnerabile agli attacchi con testo in chiaro scelto. Un attaccante può scegliere URI specifici e osservare i digest risultanti, ottenendo potenzialmente informazioni sulla password.
4.10 Attacchi dizionario precalcolati (Precomputed dictionary attacks)
Se un attaccante può accedere al file delle password del server, può precalcolare digest di password comuni e quindi confrontare questi digest con quelli nel file. L'utilizzo di valori salt può rendere questo attacco più difficile.
4.11 Attacchi brute force in batch (Batch brute force attacks)
Se un attaccante può catturare più scambi di autenticazione, può tentare di forzare la password offline con forza bruta. L'utilizzo di password forti e la limitazione del periodo di validità dei nonce possono mitigare questo rischio.
4.12 Spoofing da parte di server contraffatti (Spoofing by Counterfeit Servers)
I client dovrebbero verificare l'identità del server per prevenire la connessione a server contraffatti. L'utilizzo di TLS con convalida del certificato del server può prevenire tali attacchi.
4.13 Memorizzazione delle password (Storing passwords)
I server non dovrebbero memorizzare le password in chiaro. Invece, dovrebbe essere memorizzato l'hash della password. Per l'autenticazione digest, il server può memorizzare H(username:realm:password), che consente la verifica del client senza memorizzare password in chiaro.
4.14 Riepilogo (Summary)
L'autenticazione digest fornisce una migliore sicurezza rispetto all'autenticazione di base, ma non è una soluzione di sicurezza completa. Per le applicazioni che richiedono una sicurezza forte, dovrebbero essere utilizzati TLS o altri meccanismi di sicurezza più forti. Tuttavia, l'autenticazione digest è un miglioramento pratico e utile per molte applicazioni.