Perché la verifica email conta più di quanto pensi

La verifica email ha tre obiettivi principali. Primo conferma che l'utente controlli effettivamente l'indirizzo fornito — errori di battitura come [email protected] sono sorprendentemente frequenti. Secondo riduce la creazione massiva di account automatizzati da bot che usano indirizzi falsi o usa e getta. Terzo — il punto più sottovalutato — un indirizzo email verificato è un prerequisito di sicurezza per il ripristino della password. Senza verifica, un attaccante potrebbe registrare l'indirizzo di qualcun altro e attivare un'email di ripristino. L'OWASP Authentication Cheat Sheet copre questi rischi in dettaglio.

Il flusso di verifica completo passo per passo

Il protocollo di trasporto email è definito nell'RFC 5321 — ma le decisioni a livello applicativo spettano completamente allo sviluppatore. Ogni passaggio conta:

1. L'utente invia il modulo di registrazione. Validare il formato email lato server — non solo lato client.
2. Generare un token crittograficamente casuale. Non un UUID, non un ID sequenziale, non un timestamp — vera casualità crittografica con almeno 32 byte di entropia.
3. Memorizzare l'hash del token nel database. Salvare l'hash SHA-256 del token, non il token grezzo — insieme all'ID utente, timestamp di creazione, scadenza e flag "usato".
4. Inviare l'email di verifica. Il link contiene il token grezzo come parametro di query. Usare sempre HTTPS.
5. L'utente clicca il link. Il server riceve il token grezzo nella stringa di query.
6. Validare il token. Hashare il token in arrivo, trovare la corrispondenza nel database, verificare scadenza e stato "usato".
7. In caso di successo: marcare l'email come verificata, marcare il token come usato, effettuare il login dell'utente.
8. In caso di fallimento: mostrare un messaggio di errore specifico e azionabile con un link per richiedere una nuova email.

Generazione sicura di token

L'errore più comune è usare UUID v4 come token di verifica. Gli UUID vanno bene come identificatori di database, ma non sono progettati come token di sicurezza. L'approccio corretto: usare il generatore di numeri casuali crittografici del tuo runtime. In Node.js: crypto.randomBytes(32).toString('hex'). In Python: secrets.token_urlsafe(32). In .NET: RandomNumberGenerator.GetBytes(32). L'OWASP Authentication Cheat Sheet raccomanda almeno 32 byte (256 bit) di entropia.

Testare correttamente il flusso di verifica

Ogni modifica al flusso di verifica deve essere testata con una vera email verso una vera casella di posta. Aprire un indirizzo email temporaneo, copiarlo nel modulo di registrazione, creare un account di test e osservare l'email di verifica arrivare in tempo reale. Questo prova definitivamente che l'email viene effettivamente consegnata — non solo accettata dall'API del provider.

Autenticazione email: SPF, DKIM e DMARC

Senza corretta autenticazione email, le email di verifica finiscono nello spam. SPF autorizza i server di invio tramite un record DNS TXT. DKIM aggiunge una firma crittografica. DMARC definisce la policy quando SPF o DKIM falliscono. Usare MXToolbox per verificare le tre configurazioni. Consultare la documentazione sull'autenticazione email del tuo provider di invio.

Errori comuni da evitare

• Non invalidare il token dopo l'uso. Impostare sempre il flag "usato" e verificarlo ad ogni validazione.
• Inviare email di benvenuto prima della verifica. Attivare le sequenze di onboarding solo dopo verifica confermata.
• Non limitare le richieste di reinvio. Limitare i reinvii per indirizzo a per esempio tre all'ora.
• Inviare link di verifica via HTTP. Usare sempre HTTPS — senza eccezioni.
• Non registrare gli eventi di verifica. Quando il token è stato creato, inviato e cliccato — essenziale per la diagnostica.
• Usare lo stesso token per più scopi. Token separati per verifica, reset password e cambio email.