Le password e i protocolli di autenticazione sono DAVVERO sicuri? Non sempre, in realtà.

Valutiamoli e riveliamo la loro vulnerabilità

L’autenticazione è il processo di verifica dell’identità di un utente che si connette al sistema. L’efficacia di questo processo è determinata dai protocolli e dai meccanismi di autenticazione utilizzati. In questo articolo esamineremo e valuteremo alcuni dei tipi di autenticazione per vedere quali di questi sono veramente sicuri.

Basic HTTP

La prima versione di SIP utilizzava l’autenticazione HTTP di base (Basic HTTP). Questo sistema è abbastanza facile da “bucare” usando attacchi man-in-the-middle. Questo tipo di autenticazione si è svalutata da un po ‘di tempo.

Nell’autenticazione HTTP, un utente malintenzionato può semplicemente catturare un pacchetto codificato Base64 contenente la password, che viene quindi utilizzato per decodificare ed eseguire attacchi.

→ Non sicuro!

Digest Authentication

La Digest Authentication, utilizzata sia da SIP che da HTTP, introduce la possibilità di salvare solo una versione crittografata della password sul server. Ciò impedisce al client di inviare la password in un formato facilmente decodificabile e consente al server di salvare un hash della password (che non può essere facilmente decodificata).

Esaminiamo in dettaglio i messaggi scambiati tra client e server:

Il server richiede l’autenticazione:

Il client aggiunge le informazioni di autentificazione:

Il valore di “risposta” viene calcolato nei tre passaggi seguenti (se i valori sono combinati, sono delimitati dai due punti):

1. 1. Viene calcolato l’hash MD5 del nome utente, del dominio di autenticazione e della password combinati. Il risultato è indicato come HA1.
   2. Viene calcolato l’hash MD5 del metodo combinato e dell’URI del digest (ad esempio, “GET” e “/dir/index.html”). Il risultato è indicato come HA2.
   3. L’hash MD5 del risultato HA1 combinato, il server nonce (nonce), il contatore delle richieste (nc), il client nonce (cnonce), il codice di protezione della qualità (qop) e il risultato HA2 sono calcolati. Il risultato è il valore di “risposta” fornito dal cliente.

Ecco quali sono i vantaggi di questo metodo:

• La password non viene utilizzata direttamente nel digest, ma piuttosto HA1 = MD5 (username: realm: password). Ciò consente ad alcune implementazioni di memorizzare HA1 anziché la password in chiaro.
• Il client nonce consente al client di impedire attacchi con testo in chiaro scelto che potrebbero altrimenti minacciare gli schemi di Digest authentication.
• È possibile che il server nonce contenga timestamp: significa che il server può ispezionare gli attributi nonce inviati dai client per impedire attacchi di tipo replay.
• Il server è inoltre autorizzato a mantenere un elenco di valori di nonce del server emessi di recente o utilizzati per impedire il riutilizzo.

→ Il Digest è un miglioramento, ma presenta ancora notevoli inconvenienti.

Il principale dei quali soffre è l’attacco man-in-the-middle. Per rendere Digest sicuro, la connessione tra client e server deve essere crittografata e la chiave di crittografia del server precaricata oppure deve essere utilizzata una Certificate Authority per consentire al client di verificare la chiave pubblica del server.
SCRAM
XMPP supporta il testo in chiaro, gli scambi di password Digest e anche SCRAM (Salted Challenge Response Authentication Mechanism). SCRAM introduce vantaggi rispetto a Digest, poiché consente al server di memorizzare gli hash delle password in un formato irreversibile. Questa funzione protegge dagli attacchi offline sulla password e sul database utente. Il client può anche salvare una versione della password di un hash, rendendo più difficile agli autori di attacchi (che potrebbero avere accesso al PC in cui è memorizzata la password) comprendere la password in formato testo in chiaro.

Inoltre, SCRAM protegge dagli attacchi man-in-the-middle quando vengono utilizzati i certificati. Ciò viene fatto consentendo al server di dimostrare al client che, non solo il certificato è firmato da una CA (Certification Authority), ma che conosce anche la password. Questa funzione è chiamata channel binding, poiché il canale di crittografia inferiore è “vincolato” al canale dell’applicazione più alto. Aggiunge inoltre ulteriore sicurezza su TLS, che manca di autenticazione in testo in chiaro e digest.

Nella crittografia, SCRAM (Salted Challenge Response Mechanism Mechanism) è una famiglia di moderni meccanismi di autenticazione challenge-response, basati su password che forniscono l’autenticazione dell’utente a un server. Come definito per Simple Authentication and Security Layer (SASL), può essere utilizzato per accessi basati su password a servizi come SMTP e IMAP (e-mail) o XMPP (chat). Per XMPP, il supporto SCRAM è obbligatorio.

I punti di forza con SCRAM:

• Memorizzazione sicura delle password: se implementato correttamente, il server può memorizzare le password in un formato salato hash e iterato, rendendo più difficili gli attacchi offline e riducendo l’impatto delle violazioni del database.
• Semplicità: l’implementazione di SCRAM è più semplice di DIGEST-MD5.
• Interoperabilità internazionale: la RFC richiede UTF-8 per essere utilizzato per nomi utente e password, diversamente da CRAM-MD5.
• Poiché solo la versione salata e hash di una password viene utilizzata nell’intero processo di accesso e il sale sul server non cambia, una password memorizzata dal client può utilizzare le versioni con hash e non esporre la password di testo in chiaro agli autori di attacchi. Tali versioni hash sono associate a un server, il che lo rende ideale per il riutilizzo della password.

Conclusioni
HTTP, XMPP e SIP che utilizzano l’autenticazione Digest offrono protezione di base e sono solo suscettibili a:

• Attacchi offline: significa che un utente malintenzionato ottiene un backup o una copia del database che memorizza gli accessi e le password.
• Attacchi man-in-the-middle: limitati a una sessione, poiché l’utilizzo di digest protegge dal riutilizzo di hash.

Gli attacchi offline vengono mitigati utilizzando potenti funzioni di hash come quelle della famiglia SHA2.

Per rendere sicura la comunicazione, non solo durante l’autenticazione ma anche per proteggere i dati scambiati, è necessario utilizzare un protocollo di segnalazione protetto (TLS). Sfortunatamente, molti sistemi UC disponibili non applicano questa funzionalità per impostazione predefinita.

XMPP offre un meccanismo di autenticazione migliorato tramite SCRAM. Questo offre una protezione notevolmente migliorata da attacchi offline, attacchi man-in-the-middle e forging del certificato TLS. SCRAM si basa su un livello di trasporto sicuro.

Ci sono proposte (RFC 7804) per supportare anche SCRAM su HTTP. Nel frattempo, lo stesso miglioramento introdotto da SCRAM può essere implementato separatamente dagli sviluppatori web che implementano la piattaforma UC.

Vuoi saperne di più? Sottoscrivi l’abbonamento gratuito al Wildix Magazine per riceverlo ogni tre mesi direttamente sulla tua scrivania Wildix magazine