Un’e-mail con la password dimostra reversibilità, non uno schema

Un servizio che invia via e-mail la password attuale di un utente ha dimostrato una cosa: può ottenere quel segreto in una forma che riesce a spedire. Non ha dimostrato quale colonna, algoritmo o libreria l’abbia prodotta. La distinzione conta perché il risultato è reale e la conclusione che se ne trae è di solito troppo specifica. La reversibilità da qualche parte nel percorso è il meccanismo; un formato di archiviazione ipotizzato non lo è.

Mantieni le prove a quel livello e il resto della revisione resterà accurato.

Che cosa dimostra il reinvio del vecchio segreto

Un verificatore a senso unico non può produrre la password originale, perché è stato progettato per non essere invertibile. Se il servizio può inviare la password via e-mail, in quel momento detiene materiale da cui la password è recuperabile, oppure intercetta e memorizza il testo in chiaro prima dell’hashing. In ogni caso il percorso di recupero è reversibile, e questa è una constatazione di sicurezza reale. Non dice nulla sul fatto che lo stesso database usi un hash costoso per altre colonne.

Osserva anche il caso intermedio: un blob cifrato memorizzato con una chiave detenuta dall’applicazione è reversibile in pratica, anche se la parola cifrato suona rassicurante in un rapporto.

Perché è una constatazione di progettazione, non una mappa dell’archiviazione

L’e-mail dimostra la recuperabilità e non identifica lo schema esatto. Potrebbe essere testo in chiaro, cifratura deterministica, una routine di offuscamento di un fornitore o un archivio di credenziali separato usato solo per il recupero. Parti diverse di un prodotto usano spesso archiviazione diversa. Attribuire un algoritmo sulla base di una sola e-mail è il tipo di affermazione che crolla in una riunione successiva.

Quello che puoi dire è più stretto e più utile: questo percorso può recuperare il segreto, quindi il prodotto non può affermare che non esista alcuna credenziale recuperabile. Tutto il resto richiede le prove dell’operatore.

Costruisci il ripristino intorno all’autorizzazione

Un ripristino risolve un problema diverso: dimostrare che il richiedente può scegliere una nuova password. Le linee guida OWASP in materia descrivono token o codici monouso generati in modo sicuro con una scadenza adeguata, e trattano la fase di richiesta come qualcosa da proteggere dall’enumerazione e dall’inondazione. Una richiesta non autenticata non deve cambiare l’account da sola. Valida l’autorizzazione prima di accettare la sostituzione e rendi il token inutilizzabile dopo un uso riuscito.

Il canale e-mail fa parte del modello di sicurezza. Possedere un nome account non dimostra nulla, e un flusso di ripristino che rivela se un account esiste consegna a un attaccante un elenco su cui lavorare.

Invalida ciò che la password proteggeva

Cambiare una password non termina automaticamente l’accesso che concedeva. Le sessioni VPN attive, i dispositivi memorizzati e i token emessi dal server possono avere ciascuno il proprio comportamento di invalidazione. Decidi deliberatamente quali devono terminare e verifica che l’implementazione lo faccia, perché un utente che presume che un ripristino lo abbia disconnesso ovunque spesso si sbaglia. Registra quella decisione insieme al flusso.

Per gli operatori: documenta quale componente verifica la richiesta, quale cambia la credenziale e come vengono gestite le sessioni correlate. Per gli utenti: proteggi il canale di recupero legittimo e tratta ogni messaggio che restituisce una password come sospetto.

La valutazione precisa è breve: che cosa dimostra il messaggio, che cosa resta ignoto e se il recupero sostituisce l’accesso tramite un processo controllato.