Autenticazione: Metodi per verificare l’identità in informatica

Autenticazione: Metodi per verificare l’identità in informatica

Introduzione all’Autenticazione

Autenticare significa verificare l’identità di un soggetto (non necessariamente umano) per garantirne l’accesso sicuro ad una infrastruttura o servizio. Le procedure di autenticazione vengono normalmente classificate sulla base del numero di partecipanti di cui, al termine del processo, risultano verificate le credenziali:

  • autenticazione unilaterale, in cui si verifica l’identità di un solo partecipante;
  • mutua autenticazione, in cui si stabilisce l’identità di entrambi i partecipanti.

Per verificare le credenziali dei diversi partecipanti sono disponibili varie tecniche. Indipendentemente dai particolari della procedura implementata, uno schema di autenticazione si svolge secondo uno dei seguenti paradigmi:

  • paradigma username/password;
  • paradigma challenge/response;
  • paradigma timestamp.

Il paradigma username/password viene generalmente utilizzato nel caso di autenticazione unilaterale, ma i rischi ad esso associati sono notevoli, in quanto la password  potrebbe essere smarrita, scoperta o addirittura indovinata ed utilizzata da un soggetto diverso rispetto al legittimo proprietario. La differenza principale tra l’autenticazione debole basata solo su password (weak authentication o one factor authentication) e l’autenticazione forte (strong authentication o multi-factor authentication) consiste nel fatto che, nel secondo caso, si usa una combinazione di più fattori per autenticarsi:

  • qualcosa che si conosce;
  • qualcosa di cui si è in possesso;
  • qualcosa che caratterizza la propria persona.

Un servizio di autenticazione che usa solo un fattore di autenticazione può essere vulnerabile, combinando due o più fattori si ha una maggior sicurezza. In pratica, per aumentare la sicurezza di accesso ad un sistema, oltre ad un’informazione di cui l’utente è a conoscenza (password o PIN), è richiesto un elemento di cui egli è esclusivo possessore (token, smart card). Quando si utilizzano due fattori in combinazione, il sistema di autenticazione viene chiamato autenticazione a due fattori (two factor authentication). Per incrementare ulteriormente il livello di sicurezza, qualora l’elemento di proprietà esclusiva dell’utente venisse rubato, è possibile combinare con i due fattori precedenti un identificatore biometrico personale (impronte digitali, struttura dell’iride, geometria della mano, voce).

Una delle tecnologie di strong authentication di più largo e semplice utilizzo è rappresentata oggi dalla One Time Password (OTP), ovvero da un codice univoco, dinamico e valido per una sola transazione, generato da un apposito dispositivo crittografico (token) sulla base del tempo o di un contatore interno al dispositivo stesso o in risposta ad una sfida.

Paradigma Username/Password

Il metodo tradizionale di autenticazione, caratterizzato dall’uso di password statiche, che non vengono modificate in tempo reale durante il processo di autenticazione, è il più diffuso e semplice da implementare. L’idea  di  base  è  la  seguente:  una password, tipicamente una stringa lunga 6-10 o più caratteri, viene associata ad ogni utente ed è condivisa tra il sistema e l’utente per autorizzarne l’accesso. Per ottenere accesso alla risorsa voluta, l’utente inserisce quindi la coppia <userid, password>, in cui l’identificativo utente è un’affermazione di identità e la password è una  prova a supporto dell’identificazione. Il sistema è responsabile di verificare quanto ricevuto sulla base delle informazioni in suo possesso. Il paradigma username/password viene generalmente utilizzato nel caso di autenticazione unilaterale e rientra nella categoria di tecniche a chiave simmetrica, in cui l’utente ed il sistema condividono la chiave privata che è la password.

Gli schemi a paradigma username/password si distinguono in base all’immagazzinamento nel sistema dell’informazione necessaria all’autenticazione e al metodo di verifica.

File di password in chiaro

L’approccio più semplice per il sistema è quello di memorizzare in un file di sistema non cifrato, protetto sia in lettura che in scrittura, la coppia <userid, password> relativa ad ogni utente.  Il sistema confronta la stringa digitata con la password salvata nel file relativa al nome utente specificato, se c’è corrispondenza l’utente  accede  al sistema, altrimenti  viene respinto. Questo approccio, non facendo uso di alcuna primitiva crittografica, viene denominato non  crittografico.  Un inconveniente di tale metodo è  che non fornisce alcuna protezione contro gli utenti privilegiati o superuser (utenti speciali che godono di accessi privilegiati ai file di sistema e allerisorse).

Memorizzazione delle password in chiaro
Memorizzazione delle password in chiaro

File di password criptate

Piuttosto che memorizzare le password degli utenti in chiaro, si memorizza una lista di password criptate secondo una particolare funzione unidirezionale (one-way), in un file protetto in sola scrittura. Con questo metodo il sistema memorizza nel file di password una coppia <userid, h(password)>, dove h(password) è una funzione hash della password. L’utente che vuole accedere al sistema inserisce la sua coppia <userid, password>. Il sistema ricerca l’userid nel file, calcola una funzione hash della password inserita  e  la  confronta  con  quella  memorizzata;  se  sono  uguali  l’identificazione  ha successo, altrimenti viene rifiutata.

Funzione one-way per password criptate
Funzione one-way per password criptate

Paradigma Challenge/Response

Il paradigma challenge/response prevede che il client si autentichi presso il server seguendo una procedura articolata in tre passi distinti:

  1. il primo passo prevede che il client invii l’identificativo personale dell’utente al server;
  2. il secondo passo prevede la generazione e la trasmissione di un numero casuale R (challenge) da parte del server, dove il numero R rappresenta la sfida da superare per completare l’autenticazione;
  3. il terzo passo, infine, prevede che il client risponda al challenge inviando al server una trasformata del challenge ricevuto. La risposta alla sfida può essere il risultato di un’operazione di cifratura del challenge R, utilizzando una chiave comune K, oppure prodotto dalla concatenazione di R con una password P ed una successiva  applicazione di una  funzione di digest. In entrambi i casi è indispensabile che il processo compiuto dal client risulti ripetibile sul server. Poiché solo client e server sono a conoscenza  del segreto (K o P) utilizzato per trasformare il numero R, il server è in grado di stabilire  l’identità dell’utente che risponde al challenge in maniera univoca, applicando la trasformazione inversa in caso di codifica o confrontando il digest ricevuto dall’utente con quello prodotto localmente.

Questo sistema è più sicuro del paradigma username/password, essendo infatti immune da attacchi di replicazione, proponendo al client sfide sempre diverse, ma non ideale per via dei tre passaggi, che possono risultare eccessivi per una buona fruibilità di alcune applicazioni Internet, soprattutto se l’autenticazione va ripetuta per ogni pacchetto trasmesso.

La soluzione ideale è ricorrere ad un paradigma che preveda l’invio di un solo messaggio per l’autenticazione, riuscendo al tempo stesso a garantire il livello di sicurezza associato al  paradigma  challenge/response. In tale paradigma ogni possibilità di attacco per la replicazione dei dati è scongiurata tramite la trasformazione di numeri casuali R, che non vengono mai riproposti dal  server. Aspetto fondamentale della robustezza dell’intero schema di autenticazione challenge/response è che non vengano mai codificati due numeri R uguali;  di  secondaria  importanza il fatto che il challenge sia generato in maniera veramente casuale.

Paradigma challenge/response
Paradigma challenge/response, con Ek algoritmo di crittografia simmetrica con chiave K condivisa da A e B

Paradigma Timestamp

Il  paradigma timestamp si propone di trarre vantaggio dalla precedente considerazione, inviando  al server la versione codificata di un numero T, sempre diverso, stabilito implicitamente dalle due entità. Per poter concordare implicitamente un numero comune T, client e server devono avere orologi interni perfettamente sincroni. Il numero T in tal caso rappresenta il valore riportato dall’orologio interno del client al momento della richiesta di accesso al servizio (timestamp), come mostrato nella fugura seguente.

Paradigma timestamp
Paradigma timestamp

Il server accetta richieste di servizio solo se contengono un timestamp compatibile con il valore del proprio orologio interno. Per semplificare la validazione del timestamp, lo si considera generalmente una quantità discreta, incrementata ad intervalli regolari. Richieste di servizio datate vengono generalmente scartate, interpretandole come messaggi trattenuti troppo a lungo dai sistemi coinvolti e/o ritrasmessi da un hacker per tentare una forma di attacco nota come attacco per trasmissione ritardata dei dati per l’autenticazione.

Per riuscire in un attacco che prevede la trasmissione ritardata dei dati per l’autenticazione, è sufficiente che un hacker trattenga il primo messaggio inviato dal client al server. Non giungendo il messaggio al server, il client provvederà, dopo aver eventualmente ricevuto una sollecitazione esplicita dal server (o dallo stesso hacker), all’invio di un secondo messaggio codificando un timestamp aggiornato.

Il secondo messaggio viene lasciato passare dall’hacker consentendo regolare accesso al servizio. A questo punto, l’attaccante dispone di un messaggio contenente dati per l’autenticazione, emesso regolarmente dal client, che può inviare al server nel tentativo di accedere al servizio.

Per scongiurare questa forma di attacco, il server deve accettare solo messaggi contenenti timestamp recenti(generalmente non eccedenti il ritardo medio di andata e ritorno introdotto dalla rete nella trasmissione dati tra client e server).

Indipendentemente dal paradigma utilizzato, la password, la chiave privata o la chiave comune, sono tutte 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 entrambi i partecipanti.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *