Would it be good secure programming practice to overwrite a "sensitive" variable before deleting it?

Yes that is a good idea to overwrite then delete/release the value. Do not assume that all you have to do is "overwrite the data" or let it fall out of scope for the GC to handle, because each language interacts with the hardware differently.

When securing a variable you might need to think about:

• encryption (in case of memory dumps or page caching)
• pinning in memory
• ability to mark as read-only (to prevent any further modifications)
• safe construction by NOT allowing a constant string to be passed in
• optimizing compilers (see note in linked article re: ZeroMemory macro)

The actual implementation of "erasing" depends on the language and platform. Research the language you're using and see if it's possible to code securely.

Why is this a good idea? Crashdumps, and anything that contains the heap could contain your sensitive data. Consider using the following when securing your in-memory data

• SecureZeroMemory
• .NET SecureString
• C++ Template

Please refer to StackOverflow for per-language implementation guides.

You should be aware that even when using vendor guidance (MSFT in this case) it is still possible to dump the contents of SecureString, and may have specific usage guidelines for high security scenarios.

Storing a value that isn't used again? Seems like something that would be optimized out, regardless of any benefit it might provide.

Also, you may not actually overwrite the data in memory depending upon how the language itself works. For example, in a language using a garbage collector, it wouldn't be removed immediately (and this is assuming you didn't leave any other references hanging around).

For example, in C#, I think the following doesn't work.

string secret = "my secret data";

...lots of work...

string secret = "blahblahblah";

"my secret data" hangs around until garbage collected because it is immutable. That last line is actually creating a new string and having secret point to it. It does not speed up how fast the actual secret data is removed.

Is there a benefit? Assuming we write it in assembly or some low lever language so we can ensure we are overwriting the data, and we put our computer to sleep or left it on with the application running, and we have our RAM scraped by an evil maid, and the evil maid got our RAM data after the secret was overwritten but before it would have just been deleted (likely a very small space), and nothing else in RAM or on the harddrive would give away this secret... then I see a possible increase in security.

But the cost versus the benefit seems to make this security optimization very low on our list of optimizations (and below the point of 'worthwhile' on most applications in general).

I could possibly see limited use of this in special chips meant to hold secrets for a short time to ensure they hold it for the shortest time possible, but even then I'm uncertain about any benefit for the costs.

You need a threat model

You should not even begin to think about overwriting security variables until you have a threat model describing what sorts of hacks you are trying to prevent. Security always comes at a cost. In this case, the cost is the development cost of teaching developers to maintain all of this extra code to secure the data. This cost means it may be more likely your developers will make mistakes, and those mistakes are more likely to be the source of a leak than a memory issue.

• Can the attacker access your memory? If so, is there a reason you think they couldn't/wouldn't just sniff the value before you overwrite it? What sort of timeframes does the attacker have access to your memory
• Can the attacker access core dumps? Do you mind if they can access sensitive data in exchange for being noisy enough to cause a core dump in the first place?
• Is this open source, or closed source? If it's open source, you have to worry about multiple compilers, because compilers will optimize away stuff like overwritten data all the time. Their job is not to provide security. (For a real life example, Schneier's PasswordSafe has specialized classes to protect the unencrypted password data. In order to do so, he uses Windows API functions to lock the memory, and force it to be overwritten properly rather than using the compiler to do it for him)
• Is this a garbage collected language? Do you know how to force YOUR particular version of your particular garbage collector to actually get rid of your data?
• How many tries can the attacker make at getting sensitive data before you notice and cut him off with other means (such as firewalls)?
• Is this being run in a virtual machine? How sure are you of the security of your Hypervisor?
• Does an attacker have physical access? For example, windows is more than happy to use a flash drive to cache virtual memory. All an attacker would need to do is convince windows to push it onto the flash drive. When that happens, it is REALLY hard to get it off. So hard, in fact, that there is no recognized method of reliably clearing data from a flash drive.

These questions need to be addressed before considering trying to overwrite sensitive data. Trying to overwrite data without addressing the thread model is a false sense of security.