Autenticazione, hash, firma digitale, certificati, SAML OAuth SPID FIDO2
Dal triangolo identificazione-autenticazione-autorizzazione alle passkey: come si protegge l'identità digitale nel 2026, con hash, firma, certificati X.509 e protocolli federati.
1. Il triangolo dell'identità digitale
Identificazione = dichiarare chi sei (username). Autenticazione = provarlo (password, impronta). Autorizzazione = cosa puoi fare dopo esserti autenticato (permessi, ruoli). Tre domande: Chi sei? Sei davvero tu? Cosa puoi fare?
Quando accediamo a un servizio online il sistema deve rispondere a tre domande distinte, spesso confuse tra loro. Confonderle è il primo errore di sicurezza: dire chi sei non significa provarlo.
Chi sei?
Dichiarazione di identità. Non verificata. Username, email, codice fiscale.
Sei davvero tu?
Dimostrazione. Password, token, biometria. Può essere MFA.
Cosa puoi fare?
Controllo accessi. Avviene dopo. Basata su ruoli, policy, ACL.
Identificazione: inserisco giagnotti.doc.
Autenticazione: digito password + OTP da app.
Autorizzazione: il sistema verifica che sono docente di 5A → posso inserire voti, ma non creare nuovi utenti (permesso solo admin). Se fossi studente, vedrei solo i miei voti.
2. Password, attacchi e i tre fattori MFA
Un fattore di autenticazione è una categoria distinta di prova: qualcosa che SAI, qualcosa che HAI, qualcosa che SEI. MFA forte richiede 2+ categorie diverse, non due password.
La coppia UserID + Password è il modello qualcosa che sai. Da sola è insufficiente: 65% degli utenti riusa password e il phishing le intercetta. Servono contromisure tecniche.
| Tecnica di attacco | Come funziona | Contromisura efficace |
|---|---|---|
| Brute force | Prova tutte le combinazioni. mario123 → secondi, M@r10!2026_ITIS# → anni. | Password lunghe, rate limiting, CAPTCHA, MFA |
| Dictionary / Rainbow table | Prova parole comuni o hash precalcolati | Salt casuale unico per utente + algoritmi lenti tipo bcrypt/Argon2 |
| Credential stuffing | Usa credenziali rubate da altri breach su servizi diversi | Password uniche, monitoraggio HaveIBeenPwned, MFA obbligatoria |
| Phishing / MitM | Sito/email fake che ruba credenziali in tempo reale | FIDO2 - immune by design perché chiave legata al dominio reale |
I tre fattori - MFA forte
Knowledge factor
Password, PIN, risposte a domande segrete. Vulnerabile a furto, phishing, reuse.
Possession factor
Smartphone OTP (TOTP), token hardware YubiKey, smart card, SMS (debole).
Inherence factor
Impronta, Face ID, iride, voce. Biometria locale, template mai su server.
SPID Livello 2 = password (SAI) + OTP da app PosteID (HAI) → MFA vera. Google con password + SMS è MFA ma SMS è intercettabile (SIM swap). Meglio app Authenticator o chiave FIDO2. Due fattori della stessa categoria (es. password + PIN) NON è MFA, è solo 2-step nella stessa categoria.
Ricorda AAA con frase: "Dico chi sono, provo che sono io, poi mi dite cosa posso fare". Per MFA, usa mano: 1 dito SAI (testa), 2 dito HAI (telefono in tasca), 3 dito SEI (impronta). Se all'esame ti chiedono perché 2 password non sono MFA, rispondi: stesso fattore, non moltiplica sicurezza.
3. Funzioni di hash crittografiche
Funzione H: {0,1}* → {0,1}^n che trasforma input di qualsiasi lunghezza in digest di lunghezza fissa, deterministica, one-way, con effetto valanga e resistente alle collisioni.
L'hash è l'impronta digitale dei dati. Da password a blockchain, da firma digitale a integrità ISO: ovunque serva verificare che i dati non siano cambiati, c'è un hash.
Non invertibilità
Da digest impossibile risalire a input. hash(x) → digest ✓, digest → x ✗. Fondamentale per password.
Resistenza collisioni
Trovare A≠B con hash(A)=hash(B) deve essere impraticabile. Se accade, algoritmo compromesso (MD5, SHA-1).
Avalanche effect
Stesso input = stesso output sempre. Cambio 1 bit → 50% bit output cambiano. Password123 vs password123 → hash totalmente diversi.
| Algoritmo | Digest | Hex | Stato sicurezza | Uso / Note |
|---|---|---|---|---|
| MD5 | 128 bit | 32 | ❌ Insicuro - collisioni dal 1996 | Solo checksum non crittografico, es. verifica download ISO vecchi |
| SHA-1 | 160 bit | 40 | ⚠️ Deprecato - SHAttered Google 2017 | Rimosso da TLS, Git usa ancora ma in migrazione |
| SHA-256 | 256 bit | 64 | ✅ Standard attuale | TLS, certificati, Bitcoin, firma digitale, HMAC |
| SHA-512 / SHA3 | 512 bit | 128 | ✅ Alta sicurezza / futuro | Ambienti militari, SHA-3 vincitore NIST 2015 |
Hash non è cifratura: non ha chiave per decifrare e non è reversibile. Cifratura protegge confidenzialità, hash protegge integrità. Domanda trabocchetto esame: "Perché non cifriamo password con AES?" Perché se rubano chiave AES leggono tutte le password. Con hash+Salt+pepper, anche con DB leaked l'attaccante deve brute-force ogni hash singolarmente.
4. Firma digitale - hash + RSA
Firma = Cifra con chiave PRIVATA del mittente l'hash del documento. Garantisce autenticità (solo tu hai privata), integrità (se doc cambia hash diverso), non ripudio (non puoi negare). Non garantisce confidenzialità.
Una firma autografa scansionata si copia. Una firma digitale no: è crittografia. Basata su RSA o ECDSA: firmo il digest, non tutto il documento, per efficienza.
La scuola ti chiede tesina firmata digitalmente. Calcoli SHA-256 del PDF, cifri hash con tua chiave privata SPID (su CIE o token). Il prof verifica con tua chiave pubblica del certificato. Se modifichi la tesina dopo firma, hash cambia → verifica fallisce. Se firmi, non puoi dire "non l'ho mai inviata" (non ripudio).
Firma digitale NON cifra il documento: resta leggibile. Se vuoi confidenzialità + autenticità, devi fare: firma con tua privata + cifra con pubblica destinatario (S/MIME, PGP). In esame: firma garantisce A+I+NR (autenticità, integrità, non ripudio), ma NON C (confidenzialità). Cifratura garantisce solo C.
5. Certificati X.509 e catena di fiducia PKI
Problema: se ti invio la mia chiave pubblica via email, come sai che è mia e non di un attaccante MITM? Risposta: certificato digitale firmato da CA fidata.
PKI = infrastruttura a chiave pubblica con CA che certifica legame identità-chiave pubblica. Trust store del browser contiene 100+ Root CA fidate. Catena: Root → Intermediate → Leaf. Revoca via CRL o OCSP.
| Campo X.509 v3 | Contenuto | Perché importante |
|---|---|---|
| Version | v1/v2/v3 (oggi v3) | Definisce estensioni supportate |
| Serial Number | Univoco per CA | Usato per revoca CRL/OCSP |
| Issuer | Nome CA emittente | Chi ha firmato questo certificato |
| Validity | NotBefore / NotAfter (90gg Let's Encrypt) | Finestra temporale, previene uso infinito |
| Subject | CN, O, OU (es. CN=profgiagnotti...) | Identità titolare, verificata da CA |
| Public Key | Chiave pubblica titolare (RSA/ECC) | Dato principale: serve a cifrare/verificare |
| Extensions | SAN, Key Usage, Basic Constraints | SAN = domini validi, KeyUsage = cosa può fare |
| CA Signature | Firma digitale della CA su tutto il cert | Garantisce autenticità e integrità del cert stesso |
Quando visiti https://didattica.scuola.it il browser riceve leaf cert + intermediate. Verifica: firma intermediate valida? Firma root valida? Root è nel trust store? Validity ok? SAN contiene dominio? Se sì → lucchetto verde, TLS ok. Se certificato scaduto, self-signed, o CN mismatch → warning rosso MITM potenziale.
6. SSO, SAML, OAuth 2.0 e OpenID Connect
In azienda/cloud/PA l'utente non vuole 50 password. Vuole Single Sign-On: una login → accesso a tutto. Ma federare identità tra domini diversi richiede standard.
Single Sign-On
Una autenticazione, molte risorse. Comodo ma IdP = single point of failure → proteggilo con MFA forte.
Autenticazione federata
XML firmato, Assertion. Enterprise, PA, SPID. Verboso ma robusto, nato 2005.
Autorizzazione delegata
JSON, token, API REST, mobile. OAuth = autorizzazione, OIDC = identità su OAuth. Access token + ID token JWT.
| Aspetto | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| Finalità | Autenticazione federata | Autorizzazione delegata (+ identità con OIDC) |
| Formato | XML verboso firmato | JSON leggero, JWT (JWS) |
| Uso tipico | Enterprise, PA, università, SPID | Web, mobile, API, "Accedi con Google/Apple" |
| Token | SAML Assertion (XML) | Access Token opaco / JWT + ID Token JWT |
| Identità | Integrata in Assertion | Richiede OIDC per identità (ID Token) |
| Mobile friendly | ❌ pesante per mobile | ✅ nato per mobile/SPA |
OAuth da solo NON autentica! Un access_token dice "puoi accedere a risorsa X", non "sei Mario Rossi". Per identità serve OIDC con ID Token. Errore comune in verifica: dire che OAuth è per login. Risposta corretta: OAuth = autorizzazione, OIDC = autenticazione sopra OAuth, SAML = autenticazione federata enterprise.
7. SPID - Sistema Pubblico di Identità Digitale
SPID è infrastruttura nazionale SAML 2.0: IdP accreditati AgID (Poste, Aruba, TIM...), SP = servizi PA, cittadino con identità verificata L1/L2/L3. L2 = pwd + OTP, L3 = CIE + PIN + dispositivo fisico.
SPID è l'esempio concreto che unisce tutto: SAML + firma digitale + certificati X.509 + MFA + autorizzazione. Dal punto di vista tecnico è SAML federato nazionale.
1. Accede a Esse3 → clicca "Entra con SPID" → selezione IdP PosteID.
2. Esse3 (SP) genera AuthnRequest SAML firmata con suo certificato → redirect a Poste IDP.
3. Studente inserisce username/pwd + OTP PosteID (MFA L2) su dominio posteid.poste.it (anti-phishing).
4. PosteID crea SAML Assertion firmata con codice fiscale RSSMRA... , nome, cognome, livello L2, expiry 5 min.
5. Browser POSTa Assertion a Esse3. Esse3 verifica firma PosteID con certificato IdP (catena AgID), controlla condizioni, estrae CF.
Università non ha mai visto password dello studente. Fiducia solo nella firma digitale della CA AgID → IdP.
| Livello SPID | Fattori | Flusso | Uso |
|---|---|---|---|
| L1 | 1 fattore: password | Username + pwd | Servizi a basso rischio, quasi dismesso |
| L2 | 2 fattori: pwd + OTP | Pwd + OTP app/SMS | Standard: INPS, Agenzia Entrate, università |
| L3 | 2 fattori + dispositivo fisico | Pwd + CIE/spid L3 + hardware | Servizi critici, firma documenti sanitari |
8. FIDO2, WebAuthn e Passkey - il futuro passwordless
FIDO2 = standard W3C WebAuthn + CTAP2 che elimina password usando coppia chiavi RSA/ECC: privata resta in Secure Element dispositivo e legata al dominio, pubblica sul server. Firma challenge → autenticazione phishing-immune. Passkey = credenziale FIDO2 sincronizzabile (iCloud, Google).
FIDO2 risolve il problema alla radice: niente password da rubare, niente phishing, niente credential stuffing. Supportato da Chrome, Safari, Edge, Android, iOS, Windows Hello, Face ID, YubiKey.
Zero password, zero phishing
Niente da rubare, niente da riutilizzare, niente da digitare su sito fake. UX fluida con FaceID/TouchID. Protegge anche da MitM real-time.
Recovery e adozione
Perdita dispositivo → serve recovery (passkey sincronizzate aiutano). Adozione ancora parziale, fallback password spesso presente. Serve educazione utenti.
| Tecnologia | Garantisce | Usato in |
|---|---|---|
| Hash SHA-256 | Integrità | Password DB, firma, blockchain |
| Firma RSA+SHA | Autenticità + Integrità + Non ripudio | Documenti, email S/MIME, codice firmato, certificati |
| Certificato X.509 | Fiducia nella chiave pubblica | HTTPS/TLS, VPN, client cert |
| SAML / OAuth / OIDC | AuthN/AuthZ federata | SPID, SSO aziendale, Accedi con Google |
| FIDO2 / Passkey | AuthN passwordless anti-phishing | YubiKey, Windows Hello, FaceID, passkey Google/Apple |
9. Verifica e laboratorio
🔬 Attività pratica + domande
Svolgi il lab lab-hash-certificati.md su GitHub poi rispondi:
- Distingui con esempio scolastico identificazione, autenticazione e autorizzazione. Perché 2 password non sono MFA?
- Calcola SHA-256 di "ciao" e "Ciao" con
openssl dgst -sha256. Spiega effetto valanga e perché MD5 è insicuro. - Un server ha hash senza salt. Spiega cosa può fare attaccante con rainbow table e come salt + pepper + Argon2 risolve.
- Descrivi firma digitale passo-passo: cosa firma Ada? Cosa verifica Brian? Perché non garantisce confidenzialità?
- Disegna catena CA: Root → Intermediate → Leaf. Cosa succede se leaf scade? E se Root compromessa? Cosa sono CRL e OCSP?
- Confronta SAML vs OAuth: quando useresti SPID (SAML) e quando "Accedi con Google" (OIDC)? Cosa fa FIDO2 contro phishing che TOTP non fa?
1) Registro: username = identificazione (claim), password+OTP = autenticazione (verify), permessi docente=autorizzazione (grant). 2 password = stesso fattore "qualcosa che sai" → non MFA, non moltiplica, entrambe rubabili con stesso phishing.
2) echo -n "ciao" | openssl dgst -sha256 → b199a... diverso da Ciao → efb3bd... 1 bit cambia → 50% digest cambia (valanga). MD5 insicuro perché trovata collisione pratica 2004, due file diversi stesso hash → firma falsificabile.
3) Senza salt, hash("password123") uguale per tutti → precomputo rainbow table 1 volta e cracco tutti. Con salt casuale 16 byte per utente, hash diversi anche con stessa pwd → tabella inutile. Pepper = segreto server non in DB, Argon2 = lento + memory-hard anti-GPU.
4) Ada: H=SHA256(doc), S=RSA_priv(H). Invia doc+S. Brian: H'=SHA256(doc ricevuto), H= RSA_pub_Ada(S). Se H==H' ok. Non confidenziale perché doc in chiaro; serve cifrare con chiave pubblica destinatario per C.
5) Leaf expiry (90gg) → browser mostra warning, TLS KO, serve renew via ACME. Root compromessa → catastrofe: tutti i leaf firmati da quella Root non fidati più, rimozione da trust store, mass revocation. CRL = lista revocati, OCSP = check online stapled.
6) SPID usa SAML perché PA, enterprise, attributi firmati, XML, identity provider accreditati. "Accedi con Google" usa OIDC perché mobile, JSON/JWT, API REST leggere. TOTP è codice che utente può digitare su sito fake → phishing possibile con proxy real-time. FIDO2 chiave legata a origin (rpId) → browser rifiuta firma su dominio fake → fisicamente immune.
Riepilogo e chiusura Modulo 2
🎓 Fine Modulo 2 - Sicurezza, crittografia e identità digitale
Hai chiuso il percorso: da CIA triad e kill chain a AES/RSA, da hash e firma a PKI, SAML/OAuth, SPID e FIDO2. Prossimo modulo: livello trasporto, TCP/UDP, TLS handshake nel dettaglio e VPN. Porta con te questa domanda: se la password è morta, come sarà l'autenticazione nel 2030?