A04:2025 Cryptographic Failures: proteggere i dati in transito e a riposo

Questa è una falla silenziosa: un sito che cifra le password con MD5, o che usa TLS ma con cifrari deboli, funziona perfettamente, nessun errore visibile, nessun crash. Solo il giorno in cui qualcuno ruba il database, la falsa sicurezza si rivela per quello che era. OWASP nota che il vero rischio non è quasi mai «rompere» un algoritmo forte: è usarlo male, o non usarlo affatto.

1. Dati in transito: TLS aggiornato, niente eccezioni

La raccomandazione ufficiale è netta: cifrare tutti i dati in transito con protocolli TLS 1.2 o superiore (oggi la pratica corrente punta a TLS 1.3), con cifrari a forward secrecy e abbandonando i cifrari CBC. Su HTTPS, l'header HTTP Strict Transport Security (HSTS) va imposto esplicitamente.

Lo scenario ufficiale mostra perché conta: un sito che non impone TLS su tutte le pagine permette a un attaccante su una rete non fidata di declassare la connessione da HTTPS a HTTP, intercettare il traffico e rubare il cookie di sessione. dirottando l'account autenticato dell'utente.

Fonte: OWASP Top 10:2025 — A04, «How to prevent»: cifrare tutto il traffico con TLS ≥ 1.2, forward secrecy, HSTS; scenario #1: downgrade da HTTPS a HTTP e furto del cookie di sessione.

2. Cifrature deboli: gli algoritmi da abbandonare

OWASP elenca esplicitamente gli algoritmi da evitare: MD5 e SHA1 come funzioni hash deprecate, la modalità ECB come modalità di cifratura insicura, e il vecchio schema di padding PKCS#1 v1.5.

Due controlli aggiuntivi da tenere a mente, sempre dalla documentazione ufficiale: preferisci sempre authenticated encryption alla semplice cifratura, e verifica che l'algoritmo non possa essere declassato o aggirato (il cosiddetto algorithm downgrade).

3. Password hashing: la lista ufficiale degli algoritmi giusti

Il manuale ufficiale è preciso sull'ordine di preferenza: Argon2, yescrypt, scrypt o PBKDF2-HMAC-SHA-512, tutti con un work factor (fattore di rallentamento) e salt. Bcrypt viene citato specificamente per i sistemi legacy, non come prima scelta per un progetto nuovo.

Lo scenario ufficiale mostra perché il salt conta: un database con password in hash senza salt (o con hash semplici e veloci) può essere violato per intero con una rainbow table, una tabella precalcolata di hash. Anche con il salt, un hash generato da una funzione veloce può cadere sotto la forza bruta di una GPU.

// PHP: Argon2id, l'algoritmo raccomandato, con un work factor esplicito
$hash = password_hash(
    $password,
    PASSWORD_ARGON2ID,
    [
        'memory_cost' => 65536,
        'time_cost'   => 4,
        'threads'     => 2,
    ]
);

4. Gestione delle chiavi: dove vivono, come nascono

• Le chiavi più sensibili vanno conservate in un HSM (Hardware o cloud-based Security Module), non in un file di configurazione qualunque.
• Le chiavi devono nascere da un generatore casuale crittograficamente sicuro (CSPRNG), mai da una funzione random ordinaria, pensata per altri scopi.
• Un vettore di inizializzazione (IV) non va mai riutilizzato con la stessa chiave e le chiavi non vanno mai versionate insieme al codice sorgente.

Un ultimo punto, spesso trascurato: OWASP raccomanda ora di iniziare a prepararsi per la crittografia post-quantistica, con l'obiettivo di rendere sicuri i sistemi più critici entro la fine del 2030.

In sintesi

Il filo conduttore: la crittografia non fallisce quasi mai per un attacco matematico spettacolare, ma per una scelta banale sbagliata, un algoritmo vecchio lasciato lì, una chiave mai ruotata, un salt dimenticato. Controllarle una per una è, quasi sempre, sufficiente.