Oui, il est recommandé d'écraser les données particulièrement sensibles lorsque les données ne sont plus nécessaires, c'est-à-dire dans le cadre d'un destructeur d'objet (soit un destructeur explicite fourni par le langage, soit une action que le programme prend avant de désallouer l'objet). Il est même recommandé d'écraser des données qui ne sont pas en soi sensibles, par exemple pour remettre à zéro les champs de pointeur dans une structure de données qui n'est plus utilisée, et également mettre à zéro les pointeurs de sortie lorsque l'objet qu'ils pointent est libéré même si vous savez vous n'allez plus utiliser ce champ.
Une raison de le faire est au cas où les données fuiraient à travers des facteurs externes tels qu'un vidage de mémoire exposé, une image d'hibernation volée, un serveur compromis permettant une mémoire vidage des processus en cours d'exécution, etc. Les attaques physiques où un attaquant extrait les bâtons de RAM et utilise la rémanence des données sont rarement un problème sauf sur les ordinateurs portables et peut-être les appareils mobiles tels que les téléphones (où la barre est plus haute car la RAM est soudée), et même alors surtout dans des scénarios ciblés uniquement. La rémanence des valeurs écrasées n'est pas un problème: il faudrait un matériel très coûteux pour sonder l'intérieur d'une puce de RAM pour détecter toute différence de tension microscopique persistante qui pourrait être influencée par une valeur écrasée. Si vous vous inquiétez des attaques physiques sur la RAM, une plus grande préoccupation serait de vous assurer que les données sont surécrites dans la RAM et pas seulement dans le cache du processeur. Mais, encore une fois, c'est généralement une préoccupation très mineure.
La raison la plus importante d'écraser des données obsolètes est une défense contre les bogues du programme qui entraînent l'utilisation de la mémoire non initialisée, comme le tristement célèbre Heartbleed. Cela va au-delà des données sensibles car le risque ne se limite pas à une fuite des données: s'il y a un bogue logiciel qui provoque le déréférencement d'un champ de pointeur sans avoir été initialisé, le bogue est à la fois moins sujet à l'exploitation et plus facile à tracer si le champ contient tous les bits-zéro que s'il pointe potentiellement vers un emplacement mémoire valide mais dénué de sens.
Attention, les bons compilateurs optimiseront la remise à zéro s'ils détectent que la valeur n'est plus utilisée. Vous devrez peut-être utiliser une astuce spécifique au compilateur pour faire croire au compilateur que la valeur reste en cours d'utilisation et ainsi générer le code de remise à zéro.
Dans de nombreux langages avec gestion automatique, les objets peuvent être déplacés en mémoire sans remarquer. Cela signifie qu'il est difficile de contrôler les fuites de données périmées, à moins que le gestionnaire de mémoire lui-même n'efface la mémoire inutilisée (ce n'est souvent pas le cas, pour les performances). Du côté positif, les fuites externes sont généralement tout ce dont vous avez à vous soucier, car les langages de haut niveau ont tendance à empêcher l'utilisation de mémoire non initialisée (méfiez-vous des fonctions de création de chaînes dans les langages avec des chaînes mutables).
Par la façon dont, j'ai écrit «zéro» ci-dessus. Vous pouvez utiliser un modèle de bits autre que tous les zéros; all-zeros a l'avantage d'être un pointeur non valide dans la plupart des environnements. Un modèle de bits que vous connaissez est un pointeur invalide mais qui est plus distinctif peut être utile pour le débogage.
De nombreuses normes de sécurité imposent l'effacement des données sensibles telles que les clés. Par exemple, la norme FIPS 140-2 pour les modules cryptographiques l'exige même au niveau d'assurance le plus bas, ce qui à part cela ne nécessite que la conformité fonctionnelle et non la résistance aux attaques.