Sì, è buona norma per la sicurezza sovrascrivere i dati particolarmente sensibili quando i dati non sono più necessari, cioè come parte di un distruttore di oggetti (un distruttore esplicito fornito dal linguaggio o un'azione che il programma richiede prima di rilasciare l'oggetto). È addirittura buona prassi sovrascrivere i dati che non sono di per sé sensibili, ad esempio per azzerare i campi del puntatore in una struttura dati che non è più utilizzabile e anche azzerare i puntatori quando l'oggetto a cui puntano viene liberato anche se si conosce non utilizzerai più quel campo.
Un motivo per farlo è nel caso in cui i dati passino attraverso fattori esterni come un core dump esposto, un'immagine di ibernazione rubata, un server compromesso che consente un dump di memoria dei processi in esecuzione, ecc. Attacchi fisici in cui un utente malintenzionato estrae la RAM bastoni e fa uso di dati di rimanenza sono raramente una preoccupazione tranne che su computer portatili e forse dispositivi mobili come telefoni (dove la barra è più alta perché la RAM è saldata), e anche allora solo in scenari mirati solo. La rimanenza dei valori sovrascritti non è un problema: occorrerebbe un hardware molto costoso per sondare all'interno di un chip RAM per rilevare eventuali differenze di tensione microscopiche persistenti che potrebbero essere influenzate da un valore sovrascritto. Se sei preoccupato per gli attacchi fisici alla RAM, una preoccupazione più grande sarebbe quella di assicurare che i dati siano scritti nella RAM e non solo nella cache della CPU. Ma, di nuovo, di solito è una preoccupazione molto minore.
Il motivo più importante per sovrascrivere i dati obsoleti è come difesa dai bug del programma che causano l'uso di memoria non inizializzata, come il famigerato heartbleed. Questo va al di là dei dati sensibili perché il rischio non è limitato a una perdita di dati: se c'è un bug software che causa il dereferenziamento di un campo puntatore senza essere stato inizializzato, il bug è meno incline allo sfruttamento e più facile da tracciare se il campo contiene tutto-bit-zero rispetto a se potenzialmente punta a una posizione di memoria valida ma priva di significato.
Fai attenzione ai buoni compilatori che ottimizzeranno l'azzeramento se rileveranno che il valore non è più utilizzato. Potrebbe essere necessario utilizzare qualche trucco specifico del compilatore per far sì che il compilatore creda che il valore rimanga in uso e quindi generi il codice di azzeramento.
In molte lingue con gestione automatica, gli oggetti possono essere spostati in memoria senza preavviso. Ciò significa che è difficile controllare le perdite di dati obsoleti, a meno che il gestore della memoria stesso non cancelli la memoria inutilizzata (spesso non lo fanno, per le prestazioni). Tra l'altro, le fughe esterne sono di solito tutto ciò di cui ti devi preoccupare, poiché i linguaggi di alto livello tendono a precludere l'uso della memoria non inizializzata (fai attenzione alle funzioni di creazione di stringhe nelle lingue con stringhe mutabili).
A proposito, ho scritto "zero out" sopra. È possibile utilizzare un modello di bit diverso da tutti gli zeri; tutti gli zeri ha il vantaggio che è un puntatore non valido nella maggior parte degli ambienti. Un po 'di schema che conosci è un puntatore non valido ma che è più distintivo può essere utile nel debug.
Molti standard di sicurezza impongono la cancellazione di dati sensibili come le chiavi. Ad esempio, lo standard FIPS 140-2 per i moduli crittografici lo richiede anche al livello di garanzia più basso, che a parte ciò richiede solo conformità funzionale e non resistenza agli attacchi.