Hashing Bcrypt e Argon2 per Autenticazione Sicura — Proteggi le Password dei Tuoi Utenti senza Scuse

Se stai leggendo questa guida, molto probabilmente hai già un'applicazione web con un form di login. E con altrettanta probabilità stai conservando le password nel peggiore dei modi: SHA-1, MD5, o – peggio ancora – in chiaro. Noi, di Meteora Web, lo vediamo ogni giorno nei progetti che ci arrivano per audit di sicurezza. Clienti che hanno speso budget in design e advertising, ma hanno lasciato la porta sul retro spalancata. Un database esposto significa migliaia di utenti compromessi, azioni legali, fiducia bruciata. E tutto perché qualcuno ha scelto la via più facile invece di quella corretta.

In questa guida vediamo esattamente come proteggere le password usando bcrypt e Argon2, e come gestire le sessioni in modo che un attacco di furto non mandi tutto all'aria. Niente teoria accademica: roba che puoi applicare oggi stesso nel tuo progetto Laravel, PHP vanilla o Node.js.

Perché un semplice hash SHA-256 non basta per proteggere le password

Partiamo da un errore comune: "uso SHA-256 con un salt, è sicuro, no?" La risposta è no. SHA-256 è un algoritmo di hashing veloce. Veloce per te, ma ancora più veloce per un attaccante con una GPU. Una singola RTX 4090 può calcolare miliardi di SHA-256 al secondo. Anche con un salt, una rainbow table adattata al tuo algoritmo cracka la maggior parte delle password in ore.

La differenza tra un hash veloce e uno lento sta nel cost factor. Bcrypt e Argon2 sono progettati per essere intrinsecamente lenti: aumentano deliberatamente il tempo di calcolo. Un tentativo di login per l'utente legittimo impiega 100-200 millisecondi. Per un attaccante che prova milioni di combinazioni, quel tempo diventa proibitivo.

Noi, di Meteora Web, abbiamo visto aziende con centinaia di migliaia di utenti usare ancora SHA-1 perché "tanto nessuno ci attacca". Poi è arrivato un attacco di credential stuffing e hanno perso tutto. La sicurezza non è opzionale, è parte del prodotto.

Come funziona bcrypt rispetto ad Argon2

Bcrypt è lo standard de facto da anni. Si basa su Blowfish e su un costo configurabile (il parametro "rounds"). È CPU-bound: più alzi il costo, più tempo serve. Funziona bene su hardware normale, ma ha un limite: non sfrutta la memoria, quindi è vulnerabile ad attacchi con GPU parallele se il costo è basso.

Argon2 è il vincitore del Password Hashing Competition (PHC) del 2015. Esiste in tre varianti: Argon2d (resistente a side-channel), Argon2i (resistente a timing attack) e Argon2id (ibrido, raccomandato). È memory-hard: richiede una quantità definita di RAM oltre che tempo di CPU. Questo lo rende molto più resistente ad attacchi con ASIC o GPU.

La scelta pratica: se usi PHP 7.2+, Laravel già include PASSWORD_ARGON2ID nella funzione password_hash. Se sei su versioni precedenti o su ambienti legacy, bcrypt va ancora più che bene – basta alzare il costo a 10 o 12. In Node.js, bcrypt e argon2 sono pacchetti npm maturi.

Noi consigliamo Argon2id se possibile, perché offre un buon bilanciamento tra sicurezza e performance. Ma se il tuo hosting ha limiti di memoria (es. server condivisi), bcrypt con costo 10 è comunque accettabile.

Come configurare il costo di bcrypt in PHP

// Hash con costo 12 (tempo ~250ms su CPU moderna)
$hash = password_hash('password_utente', PASSWORD_BCRYPT, ['cost' => 12]);

// Verifica
if (password_verify('password_inserita', $hash)) {
    // Login ok
}

// Algoritmo migliore disponibile (Argon2id su PHP 7.3+)
$hash = password_hash('password', PASSWORD_ARGON2ID, [
    'memory_cost' => 65536, // 64 MB
    'time_cost'   => 4,
    'threads'     => 2
]);

Come aggiornare automaticamente l'hash di password esistenti

if (password_verify($password, $storedHash)) {
    if (password_needs_rehash($storedHash, PASSWORD_ARGON2ID, ['memory_cost' => 65536])) {
        $newHash = password_hash($password, PASSWORD_ARGON2ID, ['memory_cost' => 65536]);
        // Salva $newHash nel database
    }
}

Quale implementazione scegliere in Laravel per una sicurezza senza falle

Laravel usa già bcrypt di default, ma puoi passare ad Argon2ID modificando il file config/hashing.php. Ecco la configurazione che usiamo nei nostri progetti:

'driver' => env('HASHING_DRIVER', 'argon2id'),
'argon2id' => [
    'memory' => 65536,
    'time'   => 4,
    'threads' => 2,
],

Non dimenticare di impostare HASHING_DRIVER=argon2id nel tuo .env. Poi tutti i Hash::make() e Hash::check() useranno Argon2id. Per le password già esistenti, Laravel non le re-hasha automaticamente: devi implementare la logica di upgrade come sopra.

Come gestire le sessioni in modo sicuro

Anche con password ben hashat, se rubano il cookie di sessione, l'attaccante entra senza nemmeno provare la password. Ecco i punti che controlliamo sempre nei nostri audit:

Rotazione del session ID dopo il login

Dopo un login riuscito, devi rigenerare l'ID di sessione. In Laravel si fa con session()->regenerate(). In PHP vanilla: session_regenerate_id(true). Senza questa rotazione, un attaccante che ha intercettato il cookie pre-login può continuare a usarlo dopo il login.

Cookie di sessione sicuri

Il cookie deve avere i flag HttpOnly (non accessibile da JavaScript), Secure (solo HTTPS), e SameSite=Strict o Lax. In Laravel, imposti SESSION_SECURE_COOKIE=true e SESSION_SAMESITE=lax nel .env. In PHP manuale:

session_set_cookie_params([
    'lifetime' => 1209600, // 14 giorni
    'path' => '/',
    'domain' => 'tuodominio.com',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'
]);

Memorizzazione sessioni su database o Redis

Evita sessioni su file su server condivisi – possono essere lette da altri utenti del sistema. In Laravel, imposta SESSION_DRIVER=database o redis. Per database, crea la tabella con php artisan session:table e migra. In più, imposta un tempo di scadenza breve e un cron job che pulisca le sessioni scadute.

Timeout di inattività e logout forzato

Un utente che lascia la sessione aperta su un computer pubblico è un rischio. Implementa un timeout di inattività (es. 30 minuti) e un logout automatico. In Laravel, puoi usare middleware o listener per tracciare l'ultima attività.

Cosa fare adesso

Non aspettare che il tuo database venga esposto per agire. Ecco la checklist operativa:

• Controlla l'algoritmo di hashing nel tuo progetto: se non è bcrypt o argon2, è sbagliato. Cambialo subito.
• Imposta un costo adeguato: per bcrypt almeno 10, per argon2id memory 64MB, time 4.
• Aggiungi la rotazione del session ID nel callback di login.
• Configura i cookie con HttpOnly, Secure, SameSite.
• Sposta le sessioni dal filesystem a database o Redis.
• Testa con password_needs_rehash per upgrade graduale.

Noi di Meteora Web abbiamo messo in sicurezza decine di progetti con queste tecniche. Se hai dubbi o vuoi un audit completo, partiamo da una domanda: quanto vale per te la fiducia dei tuoi clienti? Per approfondire tutto il perimetro della sicurezza web, leggi la nostra guida pillar sulla sicurezza web per sviluppatori.