Schema One Time Password
Quando la procedura di autenticazione è basata esclusivamente sulla riservatezza di un unico segreto (password) il paradigma challenge/response può essere oggetto di attacchi tramite forza bruta.
Per limitare l’efficacia di tali attacchi, che mirano a ricavare la credenziale utilizzata per generare la client response , è opportuno adottare password di limitata validità temporale.
La soluzione ottimale consiste nell’utilizzare password valide per una singola autenticazione (one time password, OTP).
Una volta verificate le credenziali il server scarta la password utilizzata rendendone impossibile il riutilizzo, sia da parte dell’utente legittimo sia da parte di un hacker.
Una simile soluzione può essere implementata ricorrendo allo schema CRAM-MD5, a patto che i partecipanti provvedano autonomamente a gestirsi password sempre diverse per ogni diversa richiesta di accesso al servizio.
La difficoltà pratica sta nel trovare password non banali sempre diverse e soprattutto nel mantenere il server sempre allineato sulle nuove password mantenendo al tempo stesso l’efficacia derivante dall’usare ciascun “segreto” una e una sola volta.
Lo schema OTP, attualmente definito come standard per l’impiego in ambiente Internet, è la naturale evoluzione dello schema proprietario S-KEY, proposto originariamente dalla Bellcore (descritto da RFC 1760).
La robustezza di questo schema OTP si basa sull’impiego reiterato di una generica funzione di digest, non invertibile.
Lo schema non prevede uso di altre funzioni crittografiche e non vincola all’uso di una particolare funzione di digest, definendo l’interfaccia per le funzioni di digest più diffuse nell’Internet (MD5, SHA1 ecc.).
Lo schema OTP si articola nelle seguenti fasi:
- il client richiede al server di iniziare la procedura di autenticazione, inviando lo username;
- il server, riconosciuto lo username, invia al client un challenge per consentire la generazione della one time password;
- il client genera la one time password e la invia al server per completare l’autenticazione;
- il server verifica la validità della one time password, autorizzando o negando l’accesso al servizio.
Durante la prima fase, si invia al server l’identità del richiedente (username), per consentire la generazione di “challenge personali” per ogni utente.
Il server infatti, ricevuto lo username, lo utilizza per recuperare le seguenti informazioni (indispensabili per produrre il messaggio di sfida per il client):
- l’identificatore della funzione di digest stabilita tra client e server;
- il valore raggiunto dal contatore N (N maggiore di 1), che stabilisce il numero di iterazioni necessarie per generare la one time password;
- il seme S, di lunghezza variabile, generato originariamente dal server in maniera random.
La concatenazione del numero N e del seme S rappresenta la componente challenge.
Poiché il seme S non può cambiare a ogni sfida, la sola componente tempo variante del challenge è rappresentata dal contatore N.
Alla ricezione del messaggio di sfida, il client concatena la sequenza di caratteri digitata dall’utente (generalmente indicata come passphrase) al seme S ricevuto, ottenendo in questo modo una stringa di lunghezza variabile che rappresenta l’ingresso della funzione di digest prestabilita.
La funzione di digest viene applicata ricorsivamente per N volte, usando ogni volta l’output al passo precedente come nuovo input.
Il risultato finale della funzione di digest, viene ridotto a un numero binario a 64 bit, usando una diversa funzione di riduzione standard, legata alla scelta dell’algoritmo di digest.
La versione compressa a 64 bit, dell’uscita finale della funzione di digest, rappresenta la notazione binaria della one time password.
Nell’eventualità che il risultato debba essere digitato manualmente dall’utente, la OTP viene frammentata in sei blocchi da 11 bit (2 bit di padding sono aggiunti per ottenere i 66 bit necessari) e ciascun blocco viene convertito in una singola parola, estratta da un vocabolario prestabilito di 2048 parole.
Per evitare una facile estrapolazione della OTP da parte di un hacker, lo schema prevede l’inserimento di password utente non inferiori a dieci caratteri (max 63).
Il challenge inviato dal server consente all’utente di utilizzare una stessa password locale per più autenticazioni successive.
Il seme S inviato dal server deve essere generato nuovamente ogni volta in cui il numero N scende a 1 (re-inizializzazione della sequenza).
Basta scegliete S sempre diversi a ogni re-inizializzazione per evitare che vengano inviati due challenge uguali.
Dovendo applicare la funzione di digest almeno una volta (N maggiore di 1), la password digitata dall’utente non viene mai trasmessa in chiaro al server.
Alla ricezione della one time password, il server effettua la verifica delle credenziali dell’utente.
A tale scopo, il server usa la one time password appena ricevuta come ingresso di un blocco di digest.
Il risultato finale viene confrontato con quanto contenuto nel file delle credenziali memorizzato dal server.
Se il risultato del confronto è negativo, l’accesso al servizio è negato; se è positivo, l’accesso al servizio viene consentito.
Il lavoro del server si completa modificando il file delle credenziali, predisponendolo per accettare le nuove richieste.
L’operazione prevede di decrementare di una unità il numero N associato all’username e di memorizzare la one time password appena trasmessa.
Se durante questa operazione il numero N scende sotto una soglia preimpostata (normalmente uguale a 2), vengono generati casualmente un nuovo seme S* e un nuovo numero N*.
La differenza sostanziale tra lo schema appena descritto e un generico schema challenge/response basato su funzioni di digest è che con lo schema OTP il server riesce a svolgere il suo ruolo senza entrare mai a conoscenza della password locale (che rimane un esclusivo segreto dell’utente).
In questo modo, anche se la lista locale contenente le credenziali degli utenti, finisse nelle mani di un hacker, la non invertibilità della funzione di digest rende impossibile ricavare dalle informazioni in essa contenute le password locali utilizzate dagli utenti.
L’operazione di estrapolazione della password locale, a partire dalle credenziali memorizzate sul server, è complicata dal fatto che per generare la one time password la funzione non invertibile è stata applicata dal client N volte.
Lo schema appena descritto funziona solo a regime.
Per una corretta implementazione è necessario prevedere un opportuno meccanismo di inizializzazione e reinizializzazione.
Il processo di reinizializzazione è necessario ogni qualvolta che:
- N scende sotto la soglia impostata;
- l’utente decicide di modificare la propria password locale.
Un meccanismo di inizializzazione che può essere adottato è il seguente:
- un flag memorizzato nel file delle credenziali permette di riconoscere il corrente stato della procedura OTP (se l’utente è alla sua prima autenticazione il flag vale 0, altrimenti risulta 1);
- se il flag vale 0, la fase di autenticazione viene superata in maniera implicita (il numero N, il seme S e la one time password vengono registrati per le successive autenticazioni) e il valore del flag modificato;
- se il flag vale uno e N > 1, si procede applicando le regole generali dello schema OTP;
- se il flag vale 1 e N = 1, il messaggio di sfida prodotto dal server deve racchiudere <S1, S2, N1, N2>, dove: S1 è il seme utilizzato per la sequenza corrente, S2 il seme da utilizzare per la prossima sequenza, N1 = 1 il numero di cicli per produrre la one time password corrente, N2 > 1 il numero di cicli per produrre la prossima one time password.
S1 e N1 vengono utilizzati dal client per produrre la one time password corrente (OTP1); S2 e N2 vengono invece utilizzati per generare una seconda one time password (OTP2), che verrà usata solo nelle autenticazioni successive.
Per stabilire le credenziali del client, il server verifica la OTP1. In caso di procedura di autenticazione completata con successo, S2, N2-1 e OTP2 vengono memorizzati dal server nel file delle credenziali, per le successive autenticazioni.
La principale debolezza dello schema proposto è legata al fatto che, alla prima autenticazione, le credenziali inviate dal client vengono accettate senza essere di fatto verificate dal server.
Per evitare che un hacker possa trarre vantaggio da questa vulnerabilità, sostituendosi fin dall’inizio al client, è necessario procedere alla fase di inizializzazione utilizzando un canale intrinsecamente sicuro (per esempio accettando una autenticazione con flag a zero solo da un client attivo sulla stessa macchina che ospita il server).
Dopo l’inizializzazione un hacker non può più sostituirsi al client, non disponendo della password locale.
Anche risolvendo le problematiche relative all’inizializzazione della sequenza, lo schema OTP presenta una seconda, per molti aspetti più grave, limitazione.
Per ridurre il numero di informazioni che è necessario memorizzare, lo schema OTP proposto viene implementato in modo da non rendere necessaria la memorizzazione da parte del client del numero di cicli N che sono serviti per produrre l’ultima one time password.
Un hacker può sfruttare questa vulnerabilità, operando in condizione man-in-the-middle:
- intercetta il messaggio di sfida inviato dal server;
- modifica la componente N del challenge sottraendovi un numero K<N;
- invia il messaggio di sfida modificato al client (alla ricezione del messaggio, il client produce la one time password applicando ricorsivamente la funzione di digest (N-K) volte, in base al contenuto del messaggio di sfida, dopo di che la invia al server);
- intercetta la one time password prodotta dal client;
- modifica la one time password applicando ricorsivamente la funzione di digest altre K volte;
- invia la one time password prodotta al passo precedente al server.
In questo modo, un hacker che intercetta la one time password entra in possesso delle credenziali per accedere (K – 1) volte al servizio.
L’attaccante infatti, conoscendo la OTP al passo (N-K), è in grado di generare le OTP ai passi (N-1, …, N-K+1, N-K), indispensabili per superare la verifica del server al momento della richiesta di accesso al servizio.
Per scongiurare questa forma di attacco, tramite invio di messaggi di sfida con N alterato, è indispensabile che il generatore di OTP tenga traccia dei valori N inseriti nei precedenti messaggi di sfida inviati al server.
Per aiutare l’utente a ricordarsi a quale valore di N si è giunti, esistono dispositivi hardware personali che seguono l’utente, predisposti al calcolo off-line della one time password.
L’utente è responsabile solo di passare (digitare) il seme S, trasmesso dal server, al dispositivo personale e di inserire nel client la one time password che appare sul display del dispositivo, a calcolo effettuato.
Questi dispositivi personali permettono all’utente di connettersi da qualsiasi terminale, senza richiedere ad altre componenti (PC utente, programma client) il mantenimento di informazioni relative alle autenticazioni precedentemente concluse.
Il dispositivo decrementa autonomamente il numero di cicli N, rendendo più difficile la conduzione di eventuali attacchi da parte di un hacker.
Gli schemi OTP sono generalmente utilizzati per autenticare il client.
Diviene complesso adattarli a servizi in cui è necessaria una mutua autenticazione.
Se ritenuto opportuno, lo schema può essere adattato per sostituire, alla reiterazione di una stessa funzione di hash, l’utilizzo di uno schema HMAC.
L’uso di one time password all’interno di uno schema HMAC è descritto nella RFC 4226.
