Sí, es una buena práctica para la seguridad sobrescribir datos que son particularmente sensibles cuando los datos ya no son necesarios, es decir, como parte de un destructor de objetos (ya sea un destructor explícito proporcionado por el lenguaje o una acción que realiza el programa antes de desasignar el objeto). Incluso es una buena práctica sobrescribir datos que no son sensibles a sí mismos, por ejemplo, para poner a cero los campos de punteros en una estructura de datos que queda fuera de uso, y también poner a cero los punteros cuando el objeto al que apuntan se libera, incluso si lo sabe. ya no vas a usar ese campo.
Una razón para hacer esto es en caso de que los datos se filtren a través de factores externos como un volcado de núcleo expuesto, una imagen de hibernación robada, un servidor comprometido que permita un volcado de memoria de procesos en ejecución, etc. Ataques físicos donde un atacante extrae la RAM. los bastones y el uso de la remanencia de datos rara vez son una preocupación, excepto en las computadoras portátiles y quizás en dispositivos móviles como los teléfonos (donde la barra es más alta porque la RAM está soldada), e incluso en su mayoría solo en escenarios específicos. La remanencia de los valores sobrescritos no es una preocupación: se necesitaría un hardware muy costoso para probar dentro de un chip RAM para detectar cualquier diferencia de voltaje microscópico persistente que podría estar influenciada por un valor sobrescrito. Si está preocupado por los ataques físicos en la RAM, una mayor preocupación sería asegurarse de que los datos estén sobrescritos en la RAM y no solo en la memoria caché de la CPU. Pero, de nuevo, eso suele ser una preocupación menor.
La razón más importante para sobrescribir los datos obsoletos es como una defensa contra los errores del programa que causan el uso de memoria no inicializada, como el infame Heartbleed . Esto va más allá de los datos confidenciales porque el riesgo no se limita a una fuga de datos: si hay un error de software que hace que se elimine la referencia de un campo de puntero sin haber sido inicializado, el error es menos propenso a la explotación y más fácil de rastrear si el campo contiene todos los bits-cero que si potencialmente apunta a una ubicación de memoria válida pero sin sentido.
Tenga en cuenta que los buenos compiladores optimizarán la puesta a cero si detectan que el valor ya no se usa. Es posible que deba usar algún truco específico del compilador para hacer que el compilador crea que el valor permanece en uso y, por lo tanto, generar el código de reducción a cero.
En muchos idiomas con administración automática, los objetos se pueden mover a la memoria sin previo aviso. Esto significa que es difícil controlar las fugas de datos obsoletos, a menos que el administrador de memoria borre la memoria no utilizada (a menudo no lo hace, por su rendimiento). En el lado positivo, generalmente no debe preocuparse por las fugas externas, ya que los lenguajes de alto nivel tienden a impedir el uso de memoria no inicializada (tenga cuidado con las funciones de creación de cadenas en idiomas con cadenas mutables).
Por cierto, escribí "cero" arriba. Puede utilizar un patrón de bits distinto de todos los ceros; all-ceros tiene la ventaja de que es un puntero no válido en la mayoría de los entornos. Un patrón de bits que sabe es un puntero no válido pero que es más distintivo puede ser útil para la depuración.
Muchos estándares de seguridad exigen el borrado de datos confidenciales, como las claves. Por ejemplo, el estándar FIPS 140-2 para módulos criptográficos lo requiere incluso en el nivel de seguridad más bajo, que además de eso solo requiere el cumplimiento funcional y no la resistencia contra ataques.