Social SSO: un problema nascosto

In generale, si parla di sistema basato su "Single Sign On" (SSO) quando le ri- chieste di autenticazione non vengono direttamente gestite dal sistema stesso ma vengono redirette verso un altro sistema di autenticazione che ha precedentemen- te certificato le credenziali dell’utente connesso, senza quindi avere la necessità di richiedere nuovamente le credenziali per l’accesso. Negli ultimi anni, dato il proliferare di servizi e startup sempre più orientate al sociale, sta diffondendosi sempre di più una forma particolare di SSO detta comunemente "Social Login" o "Social Sign-in" che utilizza l’identità di un servizio di social networking co- me Facebook, Twitter o Google per accedere ad un altro servizio (o sito web) di terze parti (invece di creare un nuovo account di accesso particolare e riservato esclusivamente per quel servizio). Questa forma di login è stata sia progettata per semplificare l’accesso agli utenti finali, sia per fornire sempre più affidabili informazioni personali e demografiche per gli sviluppatori di applicazioni di terze parti.

Di solito il social SSO viene adottato dai provider dei social network mediante l’implementazione di server conformi allo standard OAuth (trattato nelle sezione 2.3) o protocolli simili. Nel caso di OAuth l’utente si autentica direttamente con il social provider mediante le proprie credenziali (Facebook, Google, Twitter, ecc..) e successivamente grazie al framework riesce ad ottenere un access_token che permette all’applicazione di terze parti di effettuare chiamate ad API sociali offerte dal social provider per conto dell’utente. Questo consente all’applicazione

di terze parti di ottenere informazioni circa l’identità dell’utente (informazioni appunto necessarie per il login). Un’astrazione di tale flusso è riportata in figura 3.7.

Figura 3.7: Social SSO: flusso astratto

Mentre è del tutto lecito ed utile sfruttare informazioni pubbliche presenti sui social network per la creazione di utenti nei servizi di terze parti o per fare in modo che queste ultime utilizzino API e servizi offerti dai provider dei social network che interessino la piattaforma social (come possibilità di commenti, condivisione di stati, condivisione di informazioni, ecc), in generale, possono sorgere critiche (soprattutto dai puristi nel settore sicurezza e privacy) quando il Social SSO viene usato in generale per particolari operazioni verso l’applicazione di terze parti che necessitano di autenticazione e/o autorizzazione. Le critiche sorgono dal fatto che l’utente e il servizio di terze parti si fidano implicitamente del provider di autenticazione (social SSO provider). Dal punto di vista tecnico tuttavia, nulla vieta al social provider di generare un access_token all’insaputa dell’utente e di usare il servizio di terze parti per suo conto (come mostrato in figura 3.8).

Figura 3.8: Social SSO: impersonation

Questo caso viene comunemente definito come impersonation, ovvero un par- ticolare tipo di attacco dove l’avversario riesce ad ottenere l’identità dell’utente (in questo caso mediante l’access_token). Sebbene sia (di norma) escluso questo comportamento proprio dalle politiche di privacy e di uso dei dati personali che i social service provider fanno accettare agli utenti, è anche vero che i maggio- ri provider debbano anche rispettare le leggi vigenti nello stato di appartenenza (Stati Uniti principalmente), il che non esclude in definitiva degli scenari in cui un simile sfruttamento del social SSO porti ad un uso inaspettato di alcuni servizi dell’utente finale (principalmente per raccolta di informazioni e controllo). Mol- te soluzioni sono state proposte per evitare questo particolare tipo di problemi ma in definitiva la maggior parte si concentra sulla messa in sicurezza del canale di comunicazione tra client e server. Questo impone un maggior lavoro (e una maggiore attenzione) da parte di chi implementa il servizio SaaS di terze parti senza però portare ad una soluzione definitiva del problema, e spesso introducen- do un’altra complessità soprattutto nell’esperienza d’uso finale che si stava però cercando di limitare introducendo appunto il SSO. Queste soluzioni non sono og- getto di questa dissertazione, ma un lettore interessato può approfondire in [14]. Piuttosto nel capitolo 4 l’attenzione sarà rivolta verso lo studio e lo sviluppo di una nuova proposta (e protocollo) in grado di rendere il caso dell’impersonation

del tutto irrilevante. Si cercherà quindi di sfruttare tutti i vantaggi del social SSO dal punto di vista dell’accesso al servizio e dal punto di vista informativo, aggiungendo però la possibilità di adottare un ulteriore livello di sicurezza del tut- to dipendente dall’utente finale per operazioni critiche su dati sensibili e soggetti ad elevata privacy.

SaaS

S

: Secure Software as a Service

I capitoli 2 e 3 hanno esplorato l’odierno stato di maturità del Cloud Computing (principalmente dei servizi di tipo SaaS), le tecnologie emergenti e i principali problemi di sicurezza legati alla natura dei dati e alla privacy dell’utente finale. Quello che è emerso è una notevole adozione di filosofie e tecnologie di sviluppo agile e veloce, che privilegiano il disaccoppiamento delle componenti e l’imple- mentazione di servizi tanto semplici e leggeri quanto potenti e adattabili ad ogni tipo di situazione grazie alle astrazioni offerte da REST. La facilità e l’economi- cità con cui è possibile creare e usufruire di un variegato parco di servizi di Cloud Computing tuttavia ha fatto emergere anche importanti consapevolezze e proble- matiche relative a violazioni di privacy e perdita o furto di informazioni sensibili. Del resto, la storia insegna che ogni grande innovazione e scoperta ha un oscuro lato della medaglia, che non sempre è facile da identificare e da arginare.

Questo capitolo vuole proporre alcune possibili soluzioni per risolvere il pro- blema della privacy e della sicurezza dei dati (dal punto di vista dell’utente finale) direttamente alla radice utilizzando la crittografia lato client. Questa dissertazio- ne non vuole analizzare e soffermarsi su principi e protocolli crittografici standard, ma un lettore a digiuno di tali nozioni può fare riferimento a [21] e [46]. Si farà uso quindi, in modo intelligente ed innovativo, di principi, soluzioni e protocolli crittografici per la creazione di una struttura dati crittografica (riferita d’ora in poi come framework) in grado di garantire all’utente finale l’assoluta confiden- zialità dei propri dati nonostante questi risiedano effettivamente in servizi Cloud non curanti dei dati dell’utente o con scarsi livelli di sicurezza. Il framework verrà costruito in modo graduale, partendo da approcci semplici (non adatti a grandi

moli di dati) fino ad arrivare a soddisfare i vincoli e le condizioni di scalabilità imposti dal Cloud Computing (analizzati nella sezione 3.1) più adatti quindi ad ogni tipo di situazione e requisito di scalabilità. La letteratura offre alcuni inte- ressanti spunti e punti di partenza sia prettamente teorici (ad esempio in [3]) ma specialmente pratici (un valido esempio in [33]) che saranno oggetto di ulteriori studi, approfondimenti e relative verifiche per coprire a pieno i vincoli del Cloud Computing e della nuova frontiera dello sviluppo di servizi SaaS agili, scalabili e altamente collaborativi e sociali.

4.1 L’idea: crittografia lato client

L’intero framework che si andrà gradualmente a presentare si basa su un’idea molto semplice. Tutti i dati devono essere in qualche modo protetti prima di essere immessi nella rete. Questo significa che il device dell’utente (che sia un pc, un tablet o un cellulare o un altro dispositivo) se ne dovrà occupare prima che una qualsiasi informazione lasci l’interfaccia di rete con cui comunica con il resto del mondo (in questo caso con il servizio Cloud in questione). É chiaro che per implementare una tale politica servono delle soluzioni e degli algoritmi crittogra- fici adatti allo scopo (introdotti nella sezione 4.2) oltre che una sorta di segreto (comunemente una password o una passphrase o una masterkey o una chiave crit- tografica) conosciuto solo dall’utente in grado di permettere sia la cifratura che la decifratura dei dati. La figura 4.1 schematizza proprio questo principio.

Figura 4.1: Idea: crittografia lato client

É evidente ora che i vari problemi di privacy e di sicurezza analizzati nella sezione 3.3 non sono più rilevanti. Secondo questo semplice principio, l’utente

finale è l’unico in grado di recuperare (decifrare) i propri dati. Altre entità, come un Cloud Provider curioso, un attaccante o un ente governativo saranno solo in grado di ottenere dei dati incomprensibili (cifrati) senza la possibilità di ottenere il segreto necessario alla loro decodifica (decifratura). Ovviamente poi, nella pratica, questo principio si può ritenere valido se vengono usati tutti gli accorgimenti per lo sfruttamento di algoritmi e protocolli crittografici con elevati standard e pattern di sicurezza, e cosa ancora più importante, se si assume che il device dell’utente non sia compromesso o già sotto osservazione.