Blog

In un post precedente, Zix | AppRiver ha discusso di come i responsabili dell’attacco SolarWinds avessero abusato di token e certificati come parte della loro catena di infezione. Gli attori malintenzionati hanno continuato ad abusare di quegli stessi tipi di risorse in campagne aggiuntive rivolte ad altre entità. Ciò ha provocato un incidente di sicurezza certificato confermato a un provider di sicurezza e-mail.

Riconoscendo queste attività dannose, Zix | AppRiver ha ritenuto necessario fornire ai propri clienti una serie di articoli che discutono i tipi di metodi di autenticazione interessati e il loro funzionamento. Inizieremo con l’autenticazione basata su token.

Autenticazione basata su token: una panoramica

Autenticazione basata su token risolve alcune delle limitazioni dell’autenticazione basata su sessione. In quest’ultimo caso, un server crea una sessione per un utente quando accede. Memorizza l’ID di sessione in un cookie, che accompagna tutte le richieste successive se l’utente rimane connesso. Il server verifica quindi l’identità di un utente confrontando il cookie con i dati di sessione memorizzati in memoria.

Il problema qui è che l’autenticazione basata sulla sessione soffre di alcuni inconvenienti. Innanzitutto, richiede che il server memorizzi le sessioni nella sua memoria. C’è anche il problema dei cookie che funzionano su più dispositivi di diversi mezzi (come web e mobile).

Ecco dove entra in gioco l’autenticazione basata su token. Questa forma di autenticazione comporta un’applicazione che fornisce un token firmato al client dopo la convalida di un set di credenziali utente. Il client memorizza quel token e lo invia con ogni richiesta,a quel punto il server verifica il token e invia le informazioni.

In questo senso, l’autenticazione basata su token differisce dall’autenticazione basata sulla sessione in quanto è stateless. Non comporta la memorizzazione di informazioni su un utente su un server o in una sessione. Memorizza quei dati nel token sul lato client.

Vantaggi e sfide dell’autenticazione basata su token

L’autenticazione basata su token offre molti vantaggi. Chop-Chop nota che i token funzionano anche su diversi siti Web e mezzi, il che crea un’opportunità per una maggiore diversità di utenti, in particolare quelli che utilizzano dispositivi mobili. Oltre a tutto ciò, i token sostituiscono le credenziali di un utente nel processo di concessione dell’accesso ai dati; qualcuno che ha compromesso un token non otterrebbe automaticamente l’accesso alle credenziali dell’account dell’utente interessato.

Detto questo, l’autenticazione basata su token non è priva di sfide. Devbridge Group nota che alcuni token di sessione non vengono generati in modo sicuro, ad esempio. Ciò rende possibile per un utente malintenzionato con un campione abbastanza grande di ID di sessione per capire un modello e indovinare i token per un pool più ampio di utenti. C’è anche il problema degli aggressori che sfruttano depositi di token insicuri, accessi multipli e/o lunghi tempi di convalida dei token per rubare segreti di autenticazione.

Come utilizzare in modo sicuro l’autenticazione basata su token

Riconoscendo i rischi discussi sopra, ecco alcune best practice per utilizzare in modo sicuro l’autenticazione basata su token:

1. Genera token forti. In particolare, Devbridge raccomanda che i token presentino un ampio set di valori possibili, incorporino un grado di pseudorandomness e siano composti da almeno 16 byte di lunghezza.
2. Dare token una scadenza. È importante impostare le condizioni per quanto tempo un token rimane valido, note Auth0. Ovviamente, se un utente è ancora attivo, il token può rinnovarsi automaticamente. Ma c’è anche saggezza nel consentire a un token di scadere quando l’utente si disconnette e termina il token indipendentemente da ciò che è trascorso dopo un certo periodo di tempo.
3. Non consentire più accessi. Come notato da Devbridge, è possibile utilizzare gli attributi chiave per impedire autenticazioni parallele in cui più di una persona interagisce contemporaneamente con lo stesso account utente.
4. Memorizza in modo sicuro i token. L’archiviazione locale non è la strada da percorrere qui. DEV Community consiglia l’uso di una politica sui cookie chiamata SameSite per specificare le condizioni in cui un cookie può essere passato in una richiesta cross-domain. Una rigorosa politica di SameSite insieme al requisito che le persone debbano avere una versione del browser che supporti questa funzionalità contribuirà a mantenere sicuri i token di sessione.