Autenticazione: debolezze e vulnerabilità
Indipendentemente dal paradigma utilizzato, la password o le chiavi, sono informazioni che devono essere concordate preliminarmente tra le parti.
La robustezza del meccanismo risiede nella riservatezza di queste informazioni, che devono essere mantenute segrete tramite uno sforzo comune che coinvolge i partecipanti.
Per questo motivo, è consigliabile che l’utente ricordi mentalmente le proprie credenziali, senza dover scrivere le proprie chiavi o la propria password in un supporto dove potrebbero essere lette da un hacker.
La segretezza dell’username viene invece ritenuta non determinante ai fini della sicurezza.
Nonostante le debolezze nei confronti di eventuali replay attack, molte procedure di autenticazione oggi continuano a essere fondate sul paradigma username/password.
Un simile paradigma viene in genere utilizzato solo per autenticare il client. Un hacker che intende sostituirsi al client e accedere a un servizio Internet, deve semplicemente procurarsi la coppia username/password.
La tecnica più semplice per ricavare la password consiste nell’intercettare le informazioni trasmesse sulla rete utilizzando un analizzatore di protocollo software (packet sniffer).
Se invece della password in chiaro, viene trasmesso sulla rete un hash prodotto dal richiedente, usando come input una sequenza binaria non variabile, lo schema di autenticazione risulta ugualmente attaccabile.
Una seconda opportunità per l’hacker è cercare di ottenere direttamente la lista di credenziali memorizzata su server.
Per complicare questa forma di attacco ogni server dovrebbe memorizzare la password in forma crittografica piuttosto che in chiaro.
Questa soluzione non elimina completamente le vulnerabilità legate alla memorizzazione delle password su supporti non protetti, in quanto un attaccante entrato in possesso del digest può tentare comunque di risalire alla password che lo ha generato procedendo con un attacco per forza bruta o basato su un predefinito vocabolario.
Recentemente si sono diffuse anche altre tecniche, più efficaci, per forzare database contenenti gli hash delle password.
La tecnica più nota si basa sull’uso di Rainbow Tables e sul principio generale dello scambio “tempo per memoria”.
Tale principio prevede di precomputare ogni possibile input di una funzione di hash e di memorizzarne il risultato in memoria.
Una volta che l’attaccante dispone degli hash delle password può facilmente ricavare una password (se queste sono tra gli input usati per la precomputazione) semplicemente attraverso una ricerca nella tabella memorizzata.
Le Rainbow Tables sono tabelle particolari che consentono di ridurre lo spazio di memoria, prevedendo solo la memorizzazione di output ottenuti al termine di una catena di operazioni di hash (partendo da un determinato input).
Per ricavare una password usando una Rainbow Table non è sufficiente estrarre dalla tabella l’input associato al digest recuperato; è invece necessario ricostruirsi l’intera sequenza di passaggi della catena di operazioni hash che interessa, per poter poi arrivare a determinare la password cercata.
In pratica si tratta di un accettabile compromesso in cui si riduce lo spazio necessario per la memorizzazione delle tabelle di precomputazione sapendo che, per l’individuazione puntuale di una password, sarà poi necessario effettuare nuovamente alcuni dei calcoli effettuati per la costruzione delle tabelle stesse (ricostruzione della catena).
Nella sua ricerca di credenziali un hacker può infine cercare di accedere alle eventuali credenziali memorizzate sul client, dove le informazioni possono risultare protette in maniera più blanda di quanto avviene su server.
Le informazioni memorizzate sul client sono infatti molto spesso conservate in chiaro piuttosto che codificate attraverso una funzione crittografica (l’uso di una funzione di digest lato client è ovviamente non praticabile in quanto non invertibile).
Per scongiurare la possibilità che le informazioni memorizzate sul client cadano in mano a un hacker, la soluzione ideale è non memorizzare affatto tali informazioni sui supporti fisici collegati al client.
In questa ottica, molte applicazioni prevedono che la password venga inserita manualmente dall’utente come risposta di una sollecitazione (prompt) del server.
Per semplificare questo compito, l’utente sceglie di solito password facili da ricordare, digitabili senza commettere errori.
Se da una parte ciò rende possibile ricordare la password mentalmente, evitando che l’utente la annoti su un supporto fisico che potrebbe essere acquisito in maniera non legittima da un attaccante, dall’altra l’uso di password prevedibili (per esempio parole di uso comune o molto brevi) semplifica il tentativo di un hacker di estrapolare la password, suggerendo un insieme limitato di termini maggiormente probabili (come i termini presenti in un vocabolario standard).
Una soluzione alternativa per evitare la scelta di password troppo banali è lasciare che a produrle sia una smartcard o un token piuttosto che la fantasia dell’utente.
In tal caso il dispositivo hardware preposto a generare e conservare le credenziali per l’accesso al servizio deve risultare disponibile all’utente nel momento in cui si effettua la procedura di autenticazione.
Poiché in caso di smarrimento del supporto fisico in cui sono conservate le credenziali, chiunque ne entri in possesso potrebbe cercare di sostituirsi all’utente legittimo, molti schemi di autenticazione basati su smartcard o token prevedono una procedura ibrida.
Questa soluzione prevede che, al risultato mostrato sul visore del dispositivo hardware deve essere concatenata una componente segreta P che l’utente deve digitare manualmente alla ricezione del prompt del server.
Per minimizzare le probabilità di successo degli hacker, è comunque consigliabile modificare su base regolare le credenziali utilizzate per accedere al servizio.
L’uso di una password di limitata validità temporale introduce un tempo massimo, entro il quale un hacker deve intercettare/estrapolare la password e utilizzarla.
Scaduta questa finestra temporale, la password non è più accettata come credenziale per l’accesso al servizio.
Per ottimizzare questo principio generale, è possibile implementare uno schema entro il quale la validità di ogni password scambiata tra i partecipanti è limitata alla sola sessione corrente.
Un hacker in grado di intercettare username e password non può utilizzare tale coppia in alcun modo.
La fase di autenticazione, appena conclusa con successo dall’utente legittimo, rende di fatto non più valida la password usata.
Un simile schema inibisce ogni possibile replay attack.
Uno schema in cui le password valgono per una e una sla procedura di autenticazione è generalmente noto come schema One Time Password.
Uno schema One Time Password può essere considerato un caso particolare di paradigma challenge/response e può essere implementato, se necessario, senza usare algoritmi di crittografia simmetrici o asimmetrici, con un uso iterato di funzioni di digest.
Nonostante numerosi servizi Internet prevedono solo l’autenticazione del client, si stanno sempre più diffondendo applicazioni per cui è richiesto che il client possa verificare le credenziali del server prima di utilizzare il servizio (un esempio del genere è rappresentato dal commercio elettronico dove è bene sapere con chi si ha a che fare, lato server, prima di inviare dati riservati per completare un acquisto online).
Per autenticare entrambi i partecipanti è necessario che anche il server, terminata l’autenticazione del client, provveda a inviare le proprie credenziali.
Se si usa un algoritmo di crittografia simmetrica e un paradigma come quello challenge/response, lo schema generale diviene il seguente:
- il client invia il proprio username;
- il server risponde con una prima sfida R;
- il client restituisce una copia codificata di R1 (usando una chiave condivisa KAB);
- il client invia un secondo challenge R2;
- il server restituisce una copia codificata di R2 (usando una chiave condivisa KAB).
Il precedente schema di autenticazione non è ottimizzato. Il numero di passi necessari per risolvere la procedura di autenticazione può essere ridotto a 3 se si prevede che è il client il primo a inviare un challenge.
In tal caso è possibile riorganizzare le cose trasformando la procedura come segue:
- il client invia il proprio username e un primo challenge R1;
- il server restituisce una copia codificata di R1 (usando una chiave condivisa KAB) e il secondo challenge R2;
- il client restituisce una copia codificata di R2 (usando una chiave condivisa KAB).
Questo schema “ridotto” è soggetto a una peculiare forma di attacco, nota come “attacco per riflessione dei dati”.
Un hacker intenzionato a sostituire il client invia al server una prima richiesta di accesso al servizio con un challenge R1.
In accordo con lo schema precedente, riceve dal server una risposta contenente la versione codificata di R1 e la seconda sfida R2.
L’attaccante non conoscendo la chiave KAB condivisa tra client e server, non può al momento rispondere alla sfida.
Può però inviare al server una seconda richiesta di accesso al servizio, specificando stavolta come propria sfida R2.
Il server risponde alla sfida e restituisce all’hacker proprio il dato che gli serviva per completare la prima procedura di autenticazione.
A questo punto, è semplice per un hacker trasmettere quanto ricevuto precedentemente dal server, ottenendo illegittimamente l’accesso al servizio.
Questa forma di attacco non è praticabile se la prima sfida da risolvere è a carico del client.
Per inibire ogni attacco per riflessione dei dati, non occorre comunque tornare a usare lo schema più complesso.
Previa introduzione di opportune modifiche, la procedura di mutua autenticazione può essere mantenuta in soli 3 passi.
Una prima possibile soluzione è utilizzare chiavi diverse per le operazioni di codifica effettuate dal client e dal server.
Mantenendo algoritmi simmetrici è sufficiente infatti che i partecipanti condividano due distinte chiavi comuni:
- una chiave di scrittura del server;
- una chiave di scrittura del client.
La chiave di scrittura di un partecipante viene utilizzata per la decodifica del messaggio da parte dell’altro partecipante.
Un’altra soluzione per risolvere l’attacco è usare la crittografia asimmetrica.
Ciascun partecipante è chiamato in tal caso a codificare con la propria chiave privata il challenge ricevuto.
La verifica della risposta viene effettuata decodificando il messaggio con la corrispondente chiave pubblica.
Utilizzando questo approccio un hacker non può ottenere gratuitamente dal server la risposta alla sfida proposta.
Riproponendo infatti la sfida del server, allo stesso server, questo la codifica con la propria chiave privata producendo un risultato completamente diverso da quanto farebbe un client legittimo (utilizzando la chiave privata del client).
Se tale risultato viene inviato dall’hacker al server la fase di autenticazione viene considerata non superata e l’accaduto può essere segnalato a un sistema automatico per la rilevazione dei tentativi di intrusione.
L’uso di algoritmi asimmetrici o di più chiavi comuni, nell’ambito di un algoritmo simmetrico, può essere talvolta ritenuto una soluzione non sostenibile.
In tal caso è ancora possibile evitare un attacco per riflessione dati effettuando un attendo controllo delle sfide proposte.
La codifica di un challenge deve essere effettuata dal server se e solo se questo challenge non è stato già precedentemente prodotto dal server stesso.
Un server che mantiene informazioni storiche, riguardo i precedenti challenge emessi, è in grado di accorgersi quando il proprio generatore interno di numeri casuali produce nuovi challenge identici a challenge già circolati.
Nonché quando i challenge sottoposti dai client sono identici a challenge già prodotti dal server.
Poiché l’eventualità che due generatori di numeri casuali generino due stessi challenge è molto bassa, utilizzando sfide sufficientemente lunghe, il server deve rifiutare ogni challenge inviato dal cliente che non rappresenta una assoluta novità.
In questo modo, un hacker non può concludere il proprio attacco di riflessione dati anche se i partecipanti usano una sola chiave comune condivisa.
