Hai dimenticato la password di un account e fai clic su "Password dimenticata". Inserisci il tuo indirizzo email e, dopo qualche istante, ricevi un link per crearne una nuova.
È un'esperienza familiare, ma dietro questa procedura si nasconde un aspetto importante della sicurezza: il recupero password è un percorso alternativo per accedere a un account e deve essere protetto quanto il login, se non di più.
Se la procedura presenta controlli insufficienti, un attaccante potrebbe tentare di prendere il controllo di un account senza conoscere la password originale.
Vediamo quali rischi considerare e come progettare un sistema di recupero password sicuro per siti web, e-commerce e piattaforme SaaS.
Perché il recupero password è un punto critico
La procedura di reset esiste proprio per consentire l'accesso a chi non dispone più delle proprie credenziali. Per questo deve offrire un modo per dimostrare che la richiesta proviene da una persona autorizzata.
Nella maggior parte delle applicazioni, la verifica avviene attraverso un link inviato all'indirizzo email associato all'account. Altri sistemi possono utilizzare procedure di recupero differenti, in base al livello di rischio e al tipo di servizio.
Il problema nasce quando il meccanismo di verifica è debole, il token può essere indovinato oppure il link rimane valido troppo a lungo.
Un sistema di recupero password deve quindi bilanciare tre esigenze:
- consentire all'utente legittimo di recuperare l'accesso;
- impedire a terzi di completare il reset senza autorizzazione;
- evitare che la procedura possa essere abusata per ottenere informazioni o causare disservizi.
1. Utilizzare token di recupero casuali e imprevedibili
Il token di reset è il valore che consente di dimostrare il possesso del link di recupero.
Se il token è prevedibile, contiene informazioni ricostruibili o viene generato con un sistema casuale debole, un attaccante potrebbe tentare di indovinarlo.
Per evitare questo rischio, il token dovrebbe essere generato con un generatore crittograficamente sicuro, con una quantità adeguata di entropia.
In PHP è possibile utilizzare random_bytes() per generare dati casuali:
<?php
$token = bin2hex(random_bytes(32));
Questo esempio produce una stringa esadecimale derivata da 32 byte casuali.
Il token è soltanto un esempio di valore da inserire nel link: la sua generazione, da sola, non rende sicura l'intera procedura. È necessario gestirne anche la scadenza, l'associazione all'account, la verifica e l'invalidazione dopo l'utilizzo.
2. Conservare il token in modo prudente
Quando possibile, è preferibile non conservare nel database il token di recupero in chiaro.
Un approccio comune consiste nel salvare un hash del token e confrontarlo con l'hash del valore ricevuto quando l'utente apre il link.
Per esempio:
<?php
$token = bin2hex(random_bytes(32));
$tokenHash = hash('sha256', $token);
L'applicazione può memorizzare tokenHash insieme all'identificativo dell'account, alla data di scadenza e allo stato di utilizzo. Il token originale viene inviato all'utente attraverso il canale previsto.
Quando arriva una richiesta di reset, il server calcola nuovamente l'hash del token ricevuto e lo confronta con quello conservato.
Questa soluzione riduce il rischio che una copia del database riveli immediatamente i link di recupero ancora validi.
È importante utilizzare un token sufficientemente casuale: gli hash dei token non sostituiscono l'entropia del valore originale.
3. Impostare una scadenza breve e invalidare il token dopo l'uso
Un link di recupero non dovrebbe rimanere valido indefinitamente.
La scadenza deve essere abbastanza breve da limitare l'esposizione, ma sufficientemente lunga da permettere all'utente di completare la procedura.
Il valore esatto dipende dal contesto e dal livello di rischio dell'applicazione.
Oltre alla scadenza temporale, il token dovrebbe diventare inutilizzabile dopo un reset completato con successo.
Il server deve verificare che:
- il token esista e corrisponda a quello atteso;
- non sia scaduto;
- non sia già stato utilizzato;
- sia associato all'account corretto;
- non sia stato revocato.
La verifica e il consumo del token dovrebbero essere gestiti in modo da evitare che richieste concorrenti possano utilizzare ripetutamente lo stesso valore.
4. Non rivelare se un account esiste
Immaginiamo un modulo di recupero password che restituisca messaggi differenti:
- "Indirizzo email non registrato".
- "Ti abbiamo inviato un link di recupero".
Questa differenza può consentire a un attaccante di verificare quali indirizzi email corrispondono ad account esistenti.
La tecnica è nota come account enumeration.
Una soluzione comune consiste nel mostrare una risposta generica, per esempio:
Se l'indirizzo è associato a un account, riceverai le istruzioni per recuperare l'accesso.
Questo messaggio non conferma l'esistenza dell'account.
La stessa attenzione dovrebbe essere applicata ai tempi di risposta e ad altri comportamenti che potrebbero rivelare informazioni indirettamente.
La risposta generica non deve però impedire all'utente legittimo di completare la procedura: il sistema può inviare il messaggio effettivo all'indirizzo registrato, senza comunicarne l'esistenza a chi ha effettuato la richiesta.
5. Proteggere la procedura dagli abusi automatizzati
Un endpoint di recupero password può essere chiamato ripetutamente per generare grandi quantità di email, provocare disagi agli utenti o consumare risorse.
Per questo è utile applicare controlli sul numero e sulla frequenza delle richieste.
Le misure possono includere:
- limiti per indirizzo IP;
- limiti per account o destinatario;
- protezioni contro richieste automatizzate;
- monitoraggio dei picchi anomali;
- controlli sul volume degli invii;
- procedure per evitare l'invio ripetuto di messaggi identici.
I limiti dovrebbero essere progettati per non penalizzare eccessivamente gli utenti legittimi. Bloccare rigidamente un account dopo poche richieste, per esempio, potrebbe permettere a un terzo di impedire al proprietario di recuperare l'accesso.
Per questo motivo, la limitazione delle richieste deve essere accompagnata da una gestione prudente degli errori e dei tentativi successivi.
6. Proteggere il link di recupero
Un link di reset contiene una credenziale temporanea. Se viene esposto, chiunque ne entri in possesso potrebbe tentare di utilizzarlo fino alla scadenza o alla revoca.
Il sito dovrebbe quindi utilizzare HTTPS e prestare attenzione a dove il token può essere trasmesso.
Tra le precauzioni utili:
- non inserire il token nei log applicativi o nei sistemi di analytics;
- evitare di trasmetterlo a risorse esterne non necessarie;
- impostare una politica
Referrer-Policyappropriata; - evitare redirect non controllati verso domini esterni;
- non includere il token in messaggi di errore o pagine pubbliche;
- limitare il tempo durante il quale il token resta valido.
È importante anche costruire i link utilizzando il dominio atteso e una configurazione attendibile. Se l'applicazione ricava il dominio da un header HTTP manipolabile, potrebbe generare link di recupero diretti verso un sito controllato da terzi.
7. Aggiornare la password in modo sicuro
Dopo aver verificato il token, il server deve gestire il cambiamento della password.
La nuova password dovrebbe essere memorizzata attraverso un algoritmo di hashing per password appropriato, come Argon2id o bcrypt, utilizzando parametri adeguati alla piattaforma.
Non bisogna conservare le password in chiaro né utilizzare hash generici veloci, come SHA-256 da solo, come sostituto di un algoritmo progettato per l'hashing delle password.
La procedura deve inoltre validare la richiesta, verificare che il token sia ancora valido e assicurarsi che l'operazione venga completata correttamente.
Un reset riuscito dovrebbe invalidare il token utilizzato e, secondo il modello di sicurezza dell'applicazione, revocare le sessioni esistenti o richiedere all'utente di autenticarsi nuovamente.
Per gli account ad alto rischio può essere opportuno richiedere ulteriori verifiche prima di consentire operazioni particolarmente sensibili.
8. Informare l'utente dopo il reset
Una notifica inviata dopo il cambiamento della password aiuta il proprietario dell'account a riconoscere un'operazione inattesa.
Il messaggio dovrebbe informare che la password è stata modificata e indicare come procedere se l'utente non riconosce l'operazione.
Non dovrebbe contenere la nuova password né altre informazioni sensibili.
È inoltre importante evitare di affidarsi esclusivamente alla notifica email come misura di protezione: la sicurezza principale deve essere garantita dal processo di verifica, dai token e dai controlli applicativi.
9. Non fidarsi soltanto del controllo email
Il possesso dell'indirizzo email è spesso utilizzato come prova sufficiente per il recupero di un account, ma non tutti gli account hanno lo stesso livello di rischio.
Se l'email associata è compromessa, anche il recupero password potrebbe essere utilizzato per prendere il controllo dell'account.
Per servizi che gestiscono dati particolarmente sensibili, amministrazione di sistemi o operazioni finanziarie, possono essere necessarie ulteriori misure di verifica.
È importante anche proteggere la procedura di modifica dell'indirizzo email: se un attaccante riesce a sostituire quello associato all'account, potrebbe rendere più semplice il successivo recupero.
Il livello di verifica dovrebbe essere proporzionato all'importanza dell'account e alle conseguenze di un accesso non autorizzato.
Checklist: come verificare un sistema di reset password
Se gestisci un sito web o una piattaforma SaaS, puoi partire da questi controlli:
- [ ] I token sono generati con un sistema crittograficamente sicuro?
- [ ] I token sono conservati in modo prudente?
- [ ] Hanno una scadenza e vengono invalidati dopo l'utilizzo?
- [ ] La procedura evita di rivelare quali account esistono?
- [ ] Sono presenti limiti contro le richieste automatizzate?
- [ ] I link vengono generati utilizzando il dominio corretto?
- [ ] I token non vengono esposti inutilmente in log e sistemi di terze parti?
- [ ] La nuova password viene memorizzata con un algoritmo di hashing appropriato?
- [ ] Le sessioni e le credenziali persistenti vengono gestite dopo il reset?
- [ ] L'utente riceve una notifica quando la password viene modificata?
- [ ] Gli account privilegiati dispongono di protezioni adeguate al rischio?
Questi controlli dovrebbero essere verificati attraverso test autorizzati e, quando possibile, test automatici che coprano anche i casi negativi: token scaduti, token già utilizzati, richieste ripetute e tentativi di modificare un account differente da quello associato al token.
Conclusione
Il recupero password è una parte fondamentale della sicurezza di un account. Token imprevedibili, scadenze appropriate, risposte che non rivelano informazioni, protezioni contro gli abusi e corretta gestione delle sessioni aiutano a ridurre il rischio di accessi non autorizzati.
Con MiHakero puoi analizzare la superficie esposta dei tuoi domini, delle applicazioni web, delle API e dei servizi pubblici, individuando problemi e configurazioni rilevabili dall'esterno. Per verificare la sicurezza completa del recupero password è utile integrare l'analisi con test autorizzati dei flussi di autenticazione e delle logiche applicative.