Sicurezza dei dati: l’autenticazione degli utenti ai servizi digitali

In questo articolo, Sicurezza dei dati: l’autenticazione degli utenti ai servizi digitali, seguiamo un percorso per cercare di capire in che modo possiamo sia possibile autenticarsi e provare la propria identità in fase di accesso ai servizi digitali

Indice dei contenuti

Introduzione

Viviamo in un’epoca in cui quasi ogni attività passa attraverso sistemi digitali: home banking, posta elettronica, piattaforme scolastiche, servizi della Pubblica Amministrazione, cloud e reti aziendali.

In questo scenario, l’identità digitale diventa un elemento centrale.

Quando accediamo a un servizio online, il sistema deve rispondere a tre domande fondamentali:

1. Chi sei?
2. Puoi fare questa operazione?
3. Cosa hai effettivamente fatto?

Da queste tre domande nasce l’intera architettura della sicurezza informatica moderna.

L’obiettivo principale è garantire:

• Confidentiality (Riservatezza) → solo chi è autorizzato può accedere ai dati
• Integrity (Integrità) → i dati non devono essere alterati
• Availability (Disponibilità) → i servizi devono essere sempre accessibili

Questo modello è noto come triade CIA ed è alla base di ogni sistema sicuro.

Il problema dell’identità digitale

È importante distinguere tre concetti spesso confusi:

• Identificazione → dichiarare chi si è (es. inserire uno username)
• Autenticazione → dimostrare di essere davvero quella persona
• Autorizzazione → stabilire cosa è consentito fare

“Il metodo più semplice per dimostrare la propria identità è la password.”

Esempio concreto:
In un registro elettronico scolastico:

• Inserisco il mio username → identificazione
• Digito la password → autenticazione
• Il sistema mi permette di inserire voti ma non di modificare gli account → autorizzazione

La Password – modello tradizionale

Il sistema più diffuso di autenticazione è basato sulla coppia:

UserID + Password

Si tratta del modello tradizionale “qualcosa che sai”.

Una password sicura dovrebbe:

• essere lunga (almeno 12-14 caratteri)
• includere lettere maiuscole, minuscole, numeri e simboli
• non essere riutilizzata su più servizi

Esempio

Password debole:
mario123

Password robusta:
M@r10!2026_ITIS#

La differenza in termini di tempo necessario per un attacco brute force può passare da pochi secondi a diversi anni.

Tecniche di furto delle credenziali

Le password possono essere compromesse con diverse tecniche:

• Attacco a dizionario → prova parole comuni
• Brute force → prova tutte le combinazioni possibili
• Credential stuffing → usa credenziali rubate da altri servizi
• Phishing → inganna l’utente con email o siti falsi

Esempio:
Ricevo una mail apparentemente proveniente dalla banca che mi chiede di “verificare l’account”. Clicco, inserisco la password, ma il sito è falso. Ho appena consegnato le mie credenziali.

“Se la password da sola non è sufficiente, la soluzione più intuitiva è richiedere una seconda prova di identità. Nasce così l’autenticazione a più fattori.”

Autenticazione debole e autenticazione forte

il livello di sicurezza aumenta se si utilizzano diverse tecniche di autenticazione che appartengono a tre categorie:

Ciascuna di queste categorie rappresenta una forma di autenticazione. Per ottenere un’autenticazione forte si devono utilizzare almeno due di questi fattori e si parla di:

• 2FA / 3FA / MFA: combinazione di fattori
  • Qualcosa che sai (password, PIN)
  • Qualcosa che hai (token, smartphone)
  • Qualcosa che sei (impronta digitale, riconoscimento facciale)

Esempio:
Inserisco password + codice OTP ricevuto via app. Anche se qualcuno conosce la mia password, non può accedere senza il mio telefono.

“Se la password è così fragile, come può un server conservarla in modo sicuro?”

Le funzioni di HASH: proteggere le password

Quando si parla di sicurezza informatica, uno degli strumenti più importanti – e spesso meno compresi – è la funzione di hash crittografica.

Si tratta di un algoritmo matematico che trasforma un’informazione di lunghezza arbitraria (una password, un documento, un file, un messaggio) in una stringa di lunghezza fissa chiamata digest o impronta digitale (fingerprint).

Cosa fa una funzione di hash?

Dal punto di vista operativo, una funzione di hash:

• riceve in ingresso un dato di qualsiasi dimensione
• lo elabora attraverso trasformazioni matematiche
• restituisce in uscita una stringa di lunghezza costante

Questa stringa rappresenta una sorta di “riassunto matematico” dell’informazione iniziale.

Esempio concettuale:

Input:

Copied!Autenticazione2026
Autenticazione2026

Output (SHA-256) (64 caratteri esadecimali):

Copied!9f1c2a3e4b7c...
9f1c2a3e4b7c... 

Indipendentemente dal fatto che l’input sia lungo 5 caratteri o 5 milioni di caratteri, l’output di SHA-256 sarà sempre lungo 256 bit (64 caratteri esadecimali).

Il digest: l’impronta digitale del dato

Il risultato della funzione di hash si chiama digest.

Il digest possiede alcune proprietà fondamentali:

• è di lunghezza fissa
• rappresenta univocamente (dal punto di vista pratico) l’input
• cambia completamente anche per una minima variazione del dato

Questa ultima proprietà prende il nome di effetto valanga (avalanche effect).

Esempio:

Input 1:

Copied!Password123
Password123

Digest SHA-256:

Copied!ef92b778bafe771e89245b89ecbc...
ef92b778bafe771e89245b89ecbc...

Input 2:

Copied!password123
password123

Digest SHA-256:

Copied!a8b64babd0e7e3f3a6b2c7e9c2...
a8b64babd0e7e3f3a6b2c7e9c2...

Una sola lettera maiuscola/minuscola produce un digest completamente diverso.

Proprietà fondamentali delle funzioni di hash crittografiche

Per essere utilizzabile in ambito di sicurezza, una funzione di hash deve possedere tre caratteristiche essenziali.

1️. Non invertibilità (one-way function)

Non è computazionalmente possibile risalire all’input originale conoscendo solo il digest.

Questo significa che, se un database memorizza solo gli hash delle password, un attaccante che lo compromette non può ricostruire direttamente le password originali.

Attenzione:
Non è “matematicamente impossibile”, ma è computazionalmente impraticabile con le tecnologie attuali.

2. Resistenza alle collisioni

È estremamente improbabile che due input diversi producano lo stesso digest.

Formalmente, una collisione è una coppia:

Copied!Input A ≠ Input BmaHash(A) = Hash(B)
Input A ≠ Input B
ma
Hash(A) = Hash(B)

Una buona funzione di hash rende la ricerca di collisioni praticamente irrealizzabile.

3. Determinismo

Lo stesso input produce sempre lo stesso output.

Questo consente al server, ad esempio, di verificare una password:

• l’utente inserisce la password
• il sistema calcola l’hash
• confronta il digest con quello memorizzato

Se coincidono → autenticazione valida.

Perché le funzioni di hash sono fondamentali?

Le funzioni di hash sono utilizzate per:

• protezione delle password nei database
• firma digitale (prima si calcola l’hash del documento)
• verifica di integrità dei file
• blockchain
• HMAC (Message Authentication Code)

Senza hash, gran parte dell’architettura della sicurezza moderna non sarebbe possibile.

Algoritmi principali: MD5 e SHA

Nel tempo sono stati sviluppati diversi algoritmi per implementare funzioni di hash.

MD5 (Message Digest Algorithm 5)

MD5 produce un digest di 128 bit (32 caratteri esadecimali).

Esempio:

Input:

Copied!ITIS2026
ITIS2026

Output MD5:

Copied!6f5902ac237024bdd0c176cb93063dc4
6f5902ac237024bdd0c176cb93063dc4

Per molti anni è stato ampiamente utilizzato.

Tuttavia oggi è considerato insicuro, perché sono state trovate collisioni pratiche. Non è più raccomandato per applicazioni crittografiche.

SHA (Secure Hash Algorithm)

La famiglia SHA è oggi lo standard di riferimento.

Principali versioni:

• SHA-1 → 160 bit (40 caratteri esadecimali, oggi considerato vulnerabile)
• SHA-256 → 256 bit (64 caratteri esadecimali, molto utilizzato)
• SHA-512 → 512 bit (128 caratteri esadecimali, molto utilizzato)

La lunghezza maggiore del digest aumenta la resistenza alle collisioni.

Funzionamento dell’algoritmo:

• Un messaggio in chiaro (come una password) T viene inizialmente “preparato” aggiungendo un padding per avere una lunghezza L multipla di 1024
• T viene suddiviso in blocchi da 1024 bit
• ogni blocco subisce una trasformazione Op che consiste nella ripetizione di 80 round di una elaborazione che prende in input il valore di hash ottenuto dal blocco precedente.
• La produzione dell’output consiste del valore di Hash risultante dall’ultima elaborazione

La Op al blocco i-esimo consiste nell’espansione del blocco i-esimo in 80 blocchi da 64 bit (chiamate word).

Ad ogni step la word i-esima viene trasformata con una costante additiva, genera l’SHA- n.i e viene utilizzata per il passo successivo fino all’ultimo degli 80 step. L’ultimo risultato va in input per la Op del blocco successivo

Esempio pratico: memorizzazione sicura di una password

Quando un utente si registra:

1. Inserisce la password
2. Il server calcola SHA-256(password)
3. Memorizza solo il digest

Durante il login:

1. L’utente inserisce la password
2. Il server ricalcola l’hash
3. Confronta i digest

Se coincidono → accesso consentito.

Il server non ha mai salvato la password in chiaro.

Le funzioni di hash rappresentano il primo vero strato matematico della sicurezza digitale.

Comprenderne il funzionamento significa comprendere il cuore crittografico di quasi tutti i sistemi di autenticazione moderni.

“Le funzioni di hash non servono solo a proteggere password. Sono alla base di un meccanismo ancora più potente: la firma digitale.”

La firma digitale: autenticità e integrità

La firma digitale garantisce:

• autenticazione del documento
• integrità del documento
• non ripudiabilità del documento

Funzionamento

Si basa sul presupposto che se è vero che con l’RSA decodificando con la mia chiave privata riesco a decifrare un messaggio crittografato con la chiave pubblica del mittente è vero anche l’inverso: il messaggio originario posso ottenerlo decrittografando con la mia chiave pubblica un messaggio crittografato con la chiave privata del mittente.

Vediamo come funziona la firma digitale

1. Calcolo del digest (hash) del documento (una stringa di caratteri di dimensione ridotta) e crittografia del digest con chiave privata del mittente
2. Il mittente invia il digest criptato (firma) e il documento in chiaro
3. Il destinatario applica al documento la stessa funzione di hash ed ottiene il digest
4. decripta il digest ricevuto con la chiave pubblica del mittente
5. confronta i due digest

Se i digest sono uguali si ha conferma della provenienza (autenticazione e non ripudio) e anche dell’integrità (altrimenti il digest sarebbe diverso)

Nel caso in cui fosse necessaria anche la segretezza:

• il mittente dovrebbe criptare il digest prima con la propria chiave privata (autenticità) e poi con la chiave pubblica del destinatario (segretezza)
• il destinatario dovrebbe decriptare il digest con la propria chiave privata e poi con quella pubblica del mittente

Utilizzi

• Dematerializzazione: sostituisce la firma cartacea
• Locale: firma su PC o dispositivo personale
• Da remoto: tramite piattaforme online sicure

“Ma come faccio a sapere che quella chiave pubblica appartiene davvero a quella persona?”

Certificati digitali: il problema della fiducia

La crittografia asimmetrica, da sola, non risolve il problema dell’identità.
Per questo motivo esistono i certificati digitali.

Un certificato digitale è un documento informatico che associa in modo verificabile una chiave pubblica a un soggetto (persona fisica, azienda, server web).

È, in sostanza, una carta d’identità crittografica.

A cosa servono i certificati digitali

I certificati digitali servono a:

• garantire l’identità di un soggetto in rete
• consentire comunicazioni sicure (HTTPS, email firmate, VPN)
• permettere la verifica di firme digitali
• creare fiducia tra soggetti che non si conoscono direttamente

Senza certificati, la crittografia a chiave pubblica sarebbe vulnerabile ad attacchi di tipo man-in-the-middle, nei quali un attaccante sostituisce la chiave pubblica legittima con la propria.

Chi rilascia i certificati digitali

I certificati digitali vengono rilasciati da enti chiamati Certification Authority (CA).

Una CA è un’organizzazione fidata che:

1. verifica l’identità del richiedente
2. emette il certificato
3. lo firma digitalmente

Le CA possono essere:

• pubbliche (es. quelle riconosciute dai browser)
• aziendali (infrastrutture PKI interne)
• governative

I browser e i sistemi operativi contengono un elenco preinstallato di CA considerate affidabili. Questo elenco costituisce la radice della fiducia.

Lo standard X.509

I certificati digitali utilizzati in Internet seguono lo standard internazionale X.509.

Lo standard X.509 definisce:

• la struttura del certificato
• i campi obbligatori
• il formato di codifica
• il meccanismo di firma

Un certificato X.509 è un documento strutturato che contiene informazioni ben precise, organizzate secondo regole standardizzate.

Quali informazioni contiene un certificato digitale

Un certificato conforme a X.509 include tipicamente:

• Versione del certificato
• Numero di serie univoco
• Algoritmo di firma utilizzato dalla CA
• Nome della CA emittente
• Periodo di validità (data inizio / data fine)
• Identità del titolare (Subject)
• Chiave pubblica del titolare
• Eventuali estensioni (uso previsto del certificato)
• Firma digitale della CA

La parte fondamentale è la firma digitale della Certification Authority, che garantisce che il contenuto non sia stato alterato.

Dove vengono conservati i certificati

I certificati possono essere conservati:

• nei browser (per i server HTTPS)
• nei sistemi operativi
• in smart card o token USB
• in dispositivi hardware sicuri (HSM)
• su server aziendali

La chiave privata associata al certificato deve essere custodita in modo sicuro e non deve mai essere divulgata.

Come viene firmato un certificato

Il processo è il seguente:

1. Il soggetto genera una coppia di chiavi (pubblica e privata).
2. Invia alla CA la propria chiave pubblica insieme ai dati identificativi.
3. La CA verifica l’identità.
4. La CA crea il certificato inserendo:
   • dati del soggetto
   • chiave pubblica
   • periodo di validità
5. La CA calcola l’hash del certificato.
6. Firma l’hash con la propria chiave privata.
7. Il certificato firmato viene rilasciato al richiedente.

La firma della CA garantisce:

• autenticità
• integrità
• affidabilità

Esempio pratico

Immaginiamo questo scenario.

Bob vuole fornire ad Alice la prova della propria identità digitale per comunicare in modo sicuro per cui richiede, dopo aver generato la coppia di chiavi (pubblica e privata) prepara una richiesta di certificato contenente la chiave pubblica (CSR = Certificate Signing Request).

La CA dopo aver verificato l’identità di Bob crea il certificato X.509, inserisce la chiave pubblica di Bob, inserisce i dati identificativi di Bob, calcola l’hash del certificato, firma l’hash con la propria chiave privata e rilascia a Bob il certificato

Bob invia il certificato ad Alice che verifica l’autenticità della chiave pubblica di Bob applicando la chiave pubbblica della CA al certificato digitale ricevuto

“Ora che abbiamo strumenti matematici affidabili, possiamo costruire sistemi complessi di autenticazione distribuita”

Protocolli di autenticazione e autorizzazione: SAML e OAuth

Nei moderni ecosistemi digitali — piattaforme cloud, servizi della Pubblica Amministrazione, applicazioni enterprise, API REST — l’accesso non è più un semplice “login con username e password”. Esistono architetture distribuite in cui più sistemi cooperano tra loro, spesso appartenenti a domini differenti.

Per rendere possibile questa cooperazione in modo sicuro e standardizzato, si utilizzano protocolli formali che definiscono come devono essere scambiate le informazioni di identità e di accesso.

Tra i più importanti troviamo:

• SAML, orientato principalmente all’autenticazione
• OAuth 2.0, orientato principalmente all’autorizzazione

È essenziale comprendere questa distinzione concettuale.

• Autenticazione significa rispondere alla domanda: “Chi sei?”
• Autorizzazione significa rispondere alla domanda: “Cosa puoi fare?”

Molto spesso, nei sistemi reali, entrambi gli aspetti convivono, ma la loro logica è distinta.

SAML (Security Assertion Markup Language)

Security Assertion Markup Language è uno standard aperto basato su XML progettato per consentire lo scambio sicuro di informazioni di autenticazione e autorizzazione tra domini differenti.

È ampiamente utilizzato in:

• ambienti enterprise
• federazioni di identità
• sistemi della Pubblica Amministrazione
• architetture di Single Sign-On

SAML è particolarmente adatto quando organizzazioni diverse devono fidarsi reciprocamente delle informazioni di identità rilasciate da un’autorità riconosciuta.

Architettura logica di SAML

Nel modello SAML intervengono tre attori fondamentali:

1. Utente (Principal). È il soggetto che desidera accedere a un servizio.

2. Identity Provider (IdP). È il sistema che:

• autentica l’utente
• certifica la sua identità
• genera una dichiarazione firmata digitalmente

3. Service Provider (SP). È il sistema che offre il servizio e che si fida delle dichiarazioni dell’IdP. Il principio fondamentale è la fiducia federata: il Service Provider accetta l’identità dell’utente perché si fida dell’Identity Provider.

La SAML Assertion

Il cuore tecnico del protocollo è la SAML Assertion.

Si tratta di un documento XML firmato digitalmente che contiene: l’identità dell’utente, il metodo di autenticazione utilizzato, l’istante temporale dell’autenticazione, eventuali attributi (ruolo, email, identificativo univoco)

L’asserzione è firmata digitalmente, verificabile tramite certificato X.509, temporalmente valida per un periodo limitato

Flusso logico di funzionamento di SAML

1. L’utente tenta di accedere al Service Provider.
2. Il Service Provider rileva che l’utente non è autenticato.
3. L’utente viene reindirizzato verso l’Identity Provider.
4. L’utente si autentica presso l’IdP.
5. L’IdP genera una SAML Assertion firmata digitalmente.
6. L’asserzione viene inviata al Service Provider.
7. Il Service Provider verifica la firma.
8. Se la verifica è valida, concede l’accesso.

L’utente ha effettuato un’unica autenticazione, ma può accedere a più servizi: questo è il principio del Single Sign-On.

Vantaggi

• Autenticazione centralizzata
• Riduzione della proliferazione di credenziali
• Standard maturo e ampiamente adottato
• Elevata interoperabilità tra sistemi enterprise

Limiti

• Verbosità dovuta all’uso di XML
• Complessità di implementazione
• Meno adatto ad ambienti mobile o API leggere

OAuth 2.0

OAuth 2.0 è un framework di autorizzazione progettato per consentire a un’applicazione di accedere a risorse protette per conto di un utente, senza conoscere le sue credenziali.

È alla base di meccanismi come:

• “Accedi con Google”
• “Accedi con Facebook”
• accesso a API REST
• integrazione tra servizi cloud

Il punto chiave è questo: OAuth non trasmette password.

Distinzione concettuale

OAuth non nasce per autenticare l’identità dell’utente verso il client, ma per permettere al client di accedere a risorse protette in modo controllato.

In altre parole:

• SAML certifica chi sei.
• OAuth stabilisce a cosa puoi accedere.

I quattro ruoli di OAuth

1. Resource Owner
   L’utente che possiede i dati.
2. Client
   L’applicazione che richiede accesso.
3. Authorization Server
   Autentica l’utente e rilascia token.
4. Resource Server
   Ospita le risorse protette (API).

Il concetto di Token

OAuth introduce il concetto di access token.

Il token rappresenta un’autorizzazione:

• temporanea
• limitata nello scope
• revocabile
• priva della password dell’utente

Il token è una credenziale delegata.

Authorization Code Flow (flusso più comune)

1. L’utente avvia l’accesso tramite un client.
2. Il client reindirizza l’utente all’Authorization Server.
3. L’utente si autentica e concede consenso.
4. L’Authorization Server rilascia un authorization code.
5. Il client scambia il codice con un access token.
6. Il client utilizza il token per accedere alle risorse.

In questo modello:

• il client non vede mai la password
• l’utente mantiene il controllo sul consenso
• l’accesso è limitato nello scope e nel tempo

Caratteristiche di OAuth

• Basato su HTTP
• Utilizza JSON
• Adatto a web, mobile e API
• Elevata flessibilità
• Architettura modulare

Vantaggi

• Nessuna condivisione di password
• Accesso limitato e revocabile
• Ideale per microservizi e API REST
• Ampio supporto nei servizi cloud

Limiti

• Non garantisce autenticazione dell’identità verso il client
• Implementazione sicura non banale
• Necessita estensione per gestione identità

OAuth e OpenID Connect

Per integrare l’autenticazione dell’identità, OAuth viene esteso tramite:

OpenID Connect

OpenID Connect aggiunge un ID Token, che contiene informazioni sull’identità dell’utente firmate digitalmente.

In sintesi:

• OAuth → autorizzazione
• OpenID Connect → autenticazione
• SAML → autenticazione federata strutturata

Confronto concettuale finale

Pit stop: Visione logica d’insieme

Possiamo quindi collocare i protocolli in un quadro coerente:

1. Le funzioni di hash garantiscono integrità.
2. Le firme digitali garantiscono autenticità.
3. I certificati digitali garantiscono fiducia.
4. SAML e OAuth utilizzano questi meccanismi crittografici per costruire architetture di autenticazione e autorizzazione federata.
5. OpenID Connect integra identità e autorizzazione in ambienti web moderni.

In questo modo si passa dalla semplice autenticazione locale a un ecosistema distribuito di identità digitale federata e sicura.

“Questi protocolli rendono possibile un modello molto diffuso nei sistemi moderni: il Single Sign-On.”

Single Sign-On

Il Single Sign-On (SSO) è un meccanismo di autenticazione che consente a un utente di accedere a più servizi o applicazioni con una sola autenticazione iniziale.
Una volta autenticato, l’utente può spostarsi tra servizi diversi senza dover reinserire le credenziali.

Attori coinvolti nel SSO

• Utente

• Service Provider (SP): applicazioni o servizi a cui l’utente vuole accedere

• Identity Provider (IdP): sistema che gestisce l’autenticazione (es. Google, Microsoft, SPID)

Funzionamento del SSO

• L’utente tenta di accedere a un servizio
• Il servizio reindirizza l’utente all’Identity Provider
• L’utente si autentica presso l’IdP
• L’IdP rilascia un token di autenticazione
• Il servizio verifica il token e concede l’accesso

Vantaggi del SSO

• Riduzione del numero di password
• Migliore usabilità
• Gestione centralizzata delle identità
• Riduzione degli errori umani

Criticità

L’IdP diventa un single point of failure. Se l’account centrale viene compromesso, l’accesso a tutti i servizi è a rischio

SPID: sistema pubblico italiano per identità digitale

SPID (Sistema Pubblico di Identità Digitale) è l’infrastruttura nazionale che consente a cittadini e imprese di accedere ai servizi online della Pubblica Amministrazione e di soggetti privati aderenti con un’unica identità digitale.

Dal punto di vista tecnico, SPID è un sistema di federazione delle identità basato principalmente sul protocollo SAML.

Attori coinvolti nello SPID

Nel modello SPID intervengono tre attori principali:

• Utente (Cittadino o Impresa). È il soggetto che vuole accedere a un servizio online.
• Identity Provider (IdP). È il soggetto che verifica l’identità del cittadino, rilascia le credenziali SPID, autentica l’utente durante l’accesso. Esempi di Identity Provider accreditati sono PosteID, Aruba ID, Namirial, Lepida.
• Service Provider (SP). È l’ente che eroga il servizio. Esempi: INPS, Agenzia delle Entrate, Comuni

Il Service Provider non autentica direttamente l’utente, ma si fida dell’Identity Provider.

Funzionamento dello SPID

FASE 1: Registrazione (Enrollment)

Prima di poter usare SPID, il cittadino deve registrarsi presso un Identity Provider.

Durante questa fase:

• viene verificata l’identità tramite documento di riconoscimento
• si associa un numero di telefono e un’email
• vengono rilasciate le credenziali

A seconda del livello richiesto, possono essere utilizzati:

• riconoscimento di persona
• riconoscimento via webcam
• CIE o CNS
• firma digitale

Questa fase è fondamentale perché stabilisce il legame tra persona fisica e identità digitale.

Fase 2 – Accesso a un servizio (Flusso di autenticazione)

Vediamo ora cosa accade tecnicamente quando l’utente clicca “Accedi con SPID”.

• Richiesta di accesso: l’utente entra, ad esempio, nel sito INPS e seleziona “Accedi con SPID”.

Il Service Provider:

• genera una richiesta di autenticazione SAML

• reindirizza il browser verso l’Identity Provider scelto

L’utente viene trasferito sul sito dell’IdP. Qui avviene l’autenticazione secondo il livello di sicurezza richiesto (livello 1, livello 2, livello 3)

Fase 3 – Generazione della SAML Assertion

Una volta autenticato l’utente, l’Identity Provider:

• crea un documento XML chiamato SAML Assertion
• inserisce:
  • identificativo dell’utente
  • metodo di autenticazione
  • timestamp
  • eventuali attributi (nome, cognome, codice fiscale)
• firma digitalmente il documento

La firma garantisce:

• autenticità
• integrità
• non ripudio

Fase 4 – Invio dell’asserzione al Service Provider

La SAML Assertion viene inviata al Service Provider tramite il browser dell’utente.

Il Service Provider:

• verifica la firma digitale dell’IdP
• controlla la validità temporale
• verifica che la richiesta corrisponda a quella iniziale

Se tutto è corretto → accesso consentito.

Perché SPID è sicuro?

La sicurezza si basa su diversi elementi:

✔ Separazione dei ruoli. Il Service Provider non conserva password.

✔ Firme digitali. Ogni asserzione è firmata digitalmente.

✔ Autenticazione a più fattori. Dal livello 2 in poi è richiesta autenticazione forte.

✔ Challenge anti-replay. Ogni richiesta contiene identificativi unici per evitare riutilizzo.

Esempio pratico completo

Immaginiamo uno studente che deve scaricare un certificato universitario.

1. Accede al portale universitario.
2. Seleziona “Accedi con SPID”.
3. Sceglie il proprio Identity Provider.
4. Inserisce username e password.
5. Conferma con OTP tramite app.
6. L’IdP genera la SAML Assertion firmata.
7. L’università verifica la firma.
8. Accesso consentito.

L’università non ha mai conosciuto la password dello studente.

Aspetto critico: Single Point of Failure

Il sistema è molto sicuro, ma presenta una criticità:

Se l’account SPID viene compromesso, l’attaccante può accedere a tutti i servizi collegati.

Per questo motivo:

• è fondamentale proteggere lo smartphone
• non condividere OTP
• attivare notifiche di accesso

SPID come sistema federato

SPID è un esempio di:

• identità digitale federata
• autenticazione centralizzata
• standardizzazione nazionale

Rappresenta un modello di infrastruttura crittografica distribuita in cui la fiducia è garantita da:

• certificati digitali
• firme elettroniche
• protocolli standardizzati

Conclusione tecnica

Dal punto di vista informatico, SPID è un’applicazione concreta dei concetti studiati:

• autenticazione forte
• firma digitale
• certificati
• protocollo SAML
• federazione delle identità

Non è solo un servizio amministrativo, ma un sistema crittografico complesso che integra sicurezza, interoperabilità e validità legale per l’accesso ai servizi pubblici

“Se SPID rappresenta un modello federato basato anche su password e OTP, esistono sistemi che eliminano completamente la password?”

Autenticazione passwordless

Negli ultimi anni i sistemi di autenticazione tradizionali basati esclusivamente su username e password si sono dimostrati insufficienti a garantire un adeguato livello di sicurezza. Attacchi come phishing, brute force e furto di credenziali hanno reso necessario l’adozione di meccanismi di autenticazione più robusti e user-friendly.

In questo contesto si collocano soluzioni come Fast Identity Online (FIDO2), Single Sign-On (SSO) e SPID, che riducono la dipendenza dalle password e migliorano sia la sicurezza sia l’esperienza dell’utente.

FIDO2

FIDO2 è uno standard di autenticazione passwordless sviluppato dalla FIDO Alliance in collaborazione con il W3C.
Il suo obiettivo è consentire l’accesso ai servizi digitali senza l’uso di password, basandosi su:

• crittografia a chiave pubblica
• dispositivi fisici o biometrici.

FIDO2 è oggi supportato dai principali browser (Chrome, Firefox, Edge, Safari) e sistemi operativi.

Come funziona FIDO2

Il funzionamento di FIDO2 si articola in due fasi:

Registrazione (enrollment)
L’utente accede al servizio e registra un autenticatore (chiave hardware USB/NFC, smartphone, sensore biometrico). Il dispositivo genera una coppia di chiavi crittografiche:

chiave pubblica → inviata al server

chiave privata → conservata solo sul dispositivo dell’utente
La chiave privata non lascia mai il dispositivo

Autenticazione

• Il server invia una challenge

Quando l’utente tenta di accedere il server genera un numero casuale molto grande. Questo numero è unico per quella sessione e viene inviato al dispositivo dell’utente. Questa stringa casuale si chiama challenge. E’ importante che sia casuale perché impedisce attacchi di replay. Se un aggressore intercettasse una vecchia autenticazione, non potrebbe riutilizzarla, dato che la challenge cambia ogni volta.

• Il dispositivo firma la challenge

Nel dispositivo dell’utente (chiave hardware USB, smartphone, sensore biometrico) è memorizzata una chiave privata generata al momento della registrazione. Il dispositivo prende la challenge ricevuta, la elabora tramite un algoritmo crittografico, la firma digitalmente con la chiave privata

Attenzione: Non viene inviata la chiave privata. Viene inviata solo la firma della challenge.

La firma è un risultato matematico che dimostra che chi la produce possiede la chiave privata corretta.

• Il server verifica con la chiave pubblica

Il server, al momento della registrazione iniziale, ha salvato la chiave pubblica dell’utente. Quando riceve la firma utilizza la chiave pubblica, verifica matematicamente che la firma sia valida, controlla che la firma corrisponda proprio a quella challenge

Se la verifica ha esito positivo, significa che chi ha risposto possiede la chiave privata corretta quindi è il legittimo utente

Perché la chiave privata non lascia mai il dispositivo?

Questo è il punto centrale.

La chiave privata viene generata localmente, è conservata in un’area sicura del dispositivo (Secure Element, TPM, Secure Enclave), non viene mai trasmessa in rete, non viene mai salvata sul server.

Nemmeno il server conosce la chiave privata.

Di conseguenza anche se il server venisse violato, l’attaccante non potrebbe impersonare l’utente. Anche se qualcuno intercettasse il traffico di rete, non potrebbe ricostruire la chiave

Esempio intuitivo

Immaginiamo questo scenario:

• Il server dice: “Dimostrami che sei tu firmando questo numero: 93847291”
• Solo chi possiede la chiave privata può produrre la firma corretta
• Il server verifica con la chiave pubblica
• Se la verifica è corretta → accesso consentito

È come avere un timbro unico che solo il proprietario può usare, ma che chiunque può verificare come autentico.

Vantaggi di FIDO2

• Eliminazione delle password
• Immunità al phishing
• Protezione contro credential stuffing
• Elevata sicurezza crittografica
• Migliore esperienza utente

Conclusione

La crittografia, l’autenticazione e la gestione delle chiavi costituiscono il cuore della sicurezza digitale. Comprenderne i principi e le tecnologie permette di proteggere dati, identità e servizi in maniera efficace e scalabile.