4. Considerazioni sulla sicurezza
Lo schema di autenticazione Basic non è un metodo sicuro di autenticazione dell'utente, né protegge in alcun modo l'entità, che viene trasmessa in chiaro sulla rete fisica utilizzata come supporto. HTTP non impedisce l'aggiunta di miglioramenti (come schemi per utilizzare password monouso) all'autenticazione Basic.
Il difetto più grave dell'autenticazione Basic è che risulta nella trasmissione in chiaro della password dell'utente sulla rete fisica. Molti altri schemi di autenticazione affrontano questo problema.
Poiché l'autenticazione Basic comporta la trasmissione in chiaro delle password, NON DOVREBBE essere utilizzata (senza miglioramenti come HTTPS [RFC2818]) per proteggere informazioni sensibili o preziose.
Un uso comune dell'autenticazione Basic è per scopi di identificazione -- richiedere all'utente di fornire uno user-id e una password come mezzo di identificazione, ad esempio, per scopi di raccolta di statistiche d'uso accurate su un server. Quando utilizzata 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 lo user-id che la password agli utenti e, in particolare, non consente all'utente di scegliere la propria password. Il pericolo sorge perché 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 essere anche le password degli utenti per altri siti. Il proprietario o l'amministratore di un 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 vengono mantenute in modo sicuro. Questo solleva sia preoccupazioni di sicurezza che di privacy ([RFC6973]). Se la stessa combinazione user-id/password è in uso per accedere ad altri account, come un account email o un portale sanitario, le informazioni personali potrebbero essere esposte.
L'autenticazione Basic è 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 Basic quando, in realtà, si sta connettendo a un server o gateway ostile, allora l'attaccante può richiedere una password, memorizzarla per uso successivo e simulare un errore. Gli implementatori di server dovrebbero proteggersi contro questo tipo di contraffazione; in particolare, i componenti software che possono assumere il controllo dell'inquadramento dei messaggi su una connessione esistente devono essere utilizzati con cautela o non utilizzati affatto (ad esempio: script NPH ("Non-Parsed Header") come descritto nella Sezione 5 di [RFC3875]).
I server e i proxy che implementano l'autenticazione Basic devono memorizzare le password degli utenti in qualche forma per autenticare una richiesta. Queste password dovrebbero essere memorizzate in modo tale che una fuga dei dati delle password non le renda banalmente recuperabili. Questo è particolarmente importante quando agli utenti è permesso impostare le proprie password, poiché è noto che gli utenti scelgono password deboli e le riutilizzano tra i realm di autenticazione. Sebbene una discussione completa delle buone tecniche di hashing delle password sia oltre lo scopo di questo documento, gli operatori dei server dovrebbero fare uno sforzo per minimizzare i rischi per i loro utenti in caso di fuga di dati delle password. Ad esempio, i server dovrebbero evitare di memorizzare le password degli utenti in chiaro o come digest non salati. Per ulteriori discussioni sulle tecniche moderne di hashing delle password, vedere il "Password Hashing Competition" (https://password-hashing.net).
L'uso dello schema di codifica dei caratteri UTF-8 e della normalizzazione introduce ulteriori considerazioni sulla sicurezza; vedere la Sezione 10 di [RFC3629] e la Sezione 6 di [RFC5198] per ulteriori informazioni.