Dall’inizio del 2023 tutto il personale docente, tecnico e amministrativo dell'Università Ca' Foscari di Venezia utilizza l'autenticazione a più fattori per accedere alla maggior parte dei servizi informatici di Ateneo.

Alvise Rabitti è il responsabile per la sicurezza IT dell'Università Ca' Foscari - Venezia.

Questo è il racconto di come siamo riusciti a fare in modo che 4.000 persone accettassero una piccola complicazione in più per ottenere un concreto miglioramento nella sicurezza dei loro account.

# MFA ?

L'autenticazione a più fattori (Multi Factor Authentication, o MFA) è il meccanismo di autenticazione "forte" più diffuso al giorno d'oggi: per provare la sua identità, l’utente deve fornire delle credenziali che coprano almeno due di queste tre tipologie: qualcosa che l'utente è (es. un'impronta digitale), qualcosa che l'utente possiede (es. un token USB), qualcosa che l'utente sa (es. una password).
La semplice autenticazione tramite password spesso non basta per proteggere davvero gli account: da un lato la sempre maggiore potenza di calcolo disponibile, e diversi accorgimenti maturati negli anni, permettono il cracking di password anche molto complesse, dall’altro l'onnipresenza di campagne di phishing anche molto ben congegnate, rendono le password un segreto troppo semplice da ottenere.
Ovviamente neppure la MFA non è a prova di proiettile, ma può complicare le cose per un malintenzionato al punto da fargli preferire bersagli più semplici.
Per contro: rischia di complicare le cose anche per gli utenti, che tenteranno di aggirarla (diminuendo la sicurezza) o si spenderanno per farla eliminare del tutto.

# Ca' Foscari

L'Università Ca' Foscari di Venezia conta un po' più di 20.000 studenti e 4.000 unità di staff tra professori, ricercatori, tecnici e personale amministrativo.
A questi utenti l’Ateneo fornisce, attraverso un sistema di autenticazione centralizzata, servizi informatici di un po' tutti i tipi: dall'accesso al WiFi tramite eduroam alla posta elettronica, dalla gestione della carriera degli studenti tramite procedure informatizzate, all'uso di VPN, all'acceso ai sistemi windows.
Prevedendo l'impatto di un cambiamento come l'introduzione della MFA abbiamo preferito iniziare con una sperimentazione ristretta ad un piccolo gruppo, per poi estenderla rapidamente all’intero staff, anche perché è quello che ha accesso alle risorse più delicate.
Pur se di numero “contenuto”, lo staff è anche il gruppo più variegato in quanto a ruoli, formazione, e competenze tecnologiche: la soluzione che stavamo cercando avrebbe dovuto soddisfare tanto il giovane docente di sicurezza informatica quanto l'anziano luddista che non vuole intromissioni tecnologiche nella sua vita. Senza contare il temibile e trasversale partito del "si è sempre fatto così, quindi perché cambiare?".

# Fattori di Autenticazione

Diventava quindi essenziale individuare un secondo fattore di autenticazione "leggero".
Abbiamo considerato:

* codici via SMS (troppo debole);
* impronte digitali (servono hardware/software dedicati);
* token USB (complicato da distribuire e da gestire quando, inevitabilmente, viene perso);
* HMAC-based One Time Password;
* Time-based One Time Password.

Tra questi ultimi due il Time-based OTP (TOTP) ci è sembrato il più flessibile, e le diverse implementazioni disponibili ci hanno consentito di venire incontro alle esigenze degli utenti senza diminuire troppo la sicurezza del sistema.

# TOTP

Il Time-based One Time Password è un algoritmo che calcola una One Time Password (OTP) a partire da:

* un segreto condiviso tra ciascun utente e il server;
* il momento in cui viene eseguito il calcolo;
variandola ogni 30 secondi.

Siccolme il calcolo non è banale: l’utente ha bisogno di un dispositivo elettronico per ottenere la OTP corretta. Il conoscere la OTP corretta è quindi una prova accettabile del possesso di un dispositivo autorizzato preventivamente tramite il segreto condiviso.

# Deployment

L'aspetto tecnico della messa in produzione è stato piuttosto semplice: il sistema usato per il Single Sign On di Ateneo (Shibboleth) aveva a disposizione un plugin dedicato al TOTP, e l'integrazione con i sistemi di Ateneo è stata progettata e implementata da sistemisti e sviluppatori senza grosse difficoltà.
Applicazioni per calcolare il codice OTP ce ne sono molte di gratuite, opensource, e per tutti i dispositivi più comuni. Pur avendone individuato, verificato e consigliato alcune, abbiamo preferito lasciare sostanzialmente liberi gli utenti nella scelta.
L'aspetto tecnico, comunque, non ha rappresentato un problema se confrontato con l'aspetto umano. Per curare quest'ultimo: come prima cosa abbiamo coinvolto tutti i colleghi che si occupano del supporto informatico nei dipartimenti, attraverso presentazioni dedicate, ascoltando le loro perplessità e rispondendo alle loro domande. Questo confronto e il loro supporto è sicuramente stato essenziale nel primissimo livello di gestione delle attivazioni, ed ha contribuito a creare la documentazione per gli utenti.
La documentazione era parte di una strategia di comunicazione appositamente pianificata: attraverso avvisi, guide, FAQ e interfacce “user-friendly” ha permesso a ciascun utente di attivare l’applicazione per il codice OTP senza troppe difficoltà.
Oltre a questo ci siamo preoccupati di non dover affrontare i problemi e le eventuali rimostranze di 4.000 utenti tutti contemporaneamente: abbiamo approfittato del cambio password richiesto periodicamente a ciascuno per attivare il sistema di OTP. In quell'occasione abbiamo imposto all'utente di inizializzare un dispositivo con il suo segreto comune, e da quel momento in poi l'autenticazione ha richiesto anche il secondo fattore.
In questo modo abbiamo diluito i problemi su circa sei mesi, la seconda metà del 2022, dandoci modo anche di fare correzioni in corso d'opera: adattando per esempio le FAQ in base alle reali domande dell'utenza.

# Problemi

Tra i problemi più diffusi c'è stato quello di chi non voleva o poteva installare un'applicazione sullo smartphone per calcolare l'OTP (l'opzione più comoda e consigliata, ma non tutti hanno uno smartphone).
La disponibilità di applicazioni desktop e di estensioni per i browser più diffusi ci ha permesso di spostare la prova di possesso da "possiedo uno smartphone autorizzato" a "possiedo un pc autorizzato", cosa che ha risolto la totalità di questo tipo di obiezioni.
Altra fonte di preoccupazione per gli utenti ha riguardato gli account di posta non nominali, ad esempio quelli "di ufficio", per i quali talvolta gli utenti condividevano la password di accesso (non esattamente una buona pratica, ma tant'è...). L'adozione del secondo fattore ha finalmente convinto gli utenti ad utilizzare il sistema di delega degli account, con un impatto positivo anche sotto questo aspetto. Dove la delega non era disponibile siamo dovuti scendere a un compromesso, lasciando inizializzare più dispositivi con il medesimo segreto condiviso: ci è sembrato comunque un miglioramento.
In generale tutti gli altri problemi sono state variazioni sul tema "ho perso il segreto condiviso": sicuramente impegnative per il supporto utenti, ma per le quali avevamo previsto procedure ben definite e strumenti in backend. Una piacevole sorpresa: le prese di posizione ideologiche si sono contate sulle dita di una mano, e grazie alla visione condivisa con il management, e il coinvolgimento tra il gruppo degli sperimentatori dello stesso Direttore Generale, sono rimaste lettera morta.

# Risultati

Nel giro di sei mesi tutto il personale tecnico/amministrativo e docente dell’Ateneo è passato ad utilizzare il sistema di autenticazione a più fattori per la maggior parte dei servizi di Ateneo (qualcuno ne resta ancora fuori, per motivi tecnici, ma sono sempre di più quelli coperti), e i ticket che chiedono aiuto a riguardo sono sempre meno. Oltre alla sicurezza degli account sembra esserci stato un miglioramento generale della consapevolezza degli utenti rispetto alla sicurezza informatica: i report sono diventati più significativi e altre buone pratiche hanno avuto accoglienza positiva.
Non siamo al corrente di accessi non autorizzati ai servizi protetti da MFA dopo l’attivazione, ma possiamo confermare che il sistema sta funzionando: a volte, esaminando i log, capita di trovare tentativi di accesso sospetti (ad esempio perché contemporanei a login legittimi, ma da IP differenti) che azzeccano la password, ma non superano la richiesta di OTP.

# Take-away

* MFA è implementabile facilmente e totalmente attraverso soluzioni opensource: lo scoglio da superare non è tecnologico.
* Una comunicazione chiara e una documentazione in linguaggio non tecnico sono di grande aiuto.
* Un supporto utenti coordinato e paziente è essenziale.
* Il gioco vale la candela!

# Short bio

Alvise Rabitti è il responsabile per la sicurezza IT dell'Università Ca' Foscari - Venezia.
Stupefatto che un Commodore 64 obbedisse ai suoi comandi, ha cominciato da bambino a cercare di capire come far funzionare i computer, passando rapidamente a cercare di farli funzionare diversamente dalle aspettative. Capire come ingannare i sistemi gli sembra ancora uno dei modi migliori per curarne la protezione.
In veste di ricercatore di sicurezza informatica ha contribuito a molte responsible disclosure con destinatari nazionali e internazionali, e pubblicato lavori in diverse conferenze quali USENIX, IEEE Security & Privacy, e su riviste peer-reviewed.