At least OS X and Linux do support that, no idea about Redmond OS though.

Also encrypting your harddisk partition as such might help…
IMHO these security decisions should be left to the user and not the program at hand.
If you do think you should provide something “secure”, why not make the auth system pluggable and offer something really secure like one-time auth or whatever you feel like?

Take the lock on your door for example. It is not 100% secure, but its mostly secure. There’s always a chance that someone may be strong enough to smash it.

Another example would be the encryption key size. Why use 256 bits? Why not use 1 MB? Convenience, and the probability that whoever is cracking your key does not have a giant server farm or futuristic computers.

Another program running alongside could play with timing issues, memory availability, paging, etc… Therefore, if you want this to be secure against the threat you are defending against, you have to consider these issues.

If instead you leave the password out there, and continue using your program for a couple hours then there’s a high possibility it will be swapped to disk.

> In the general case, your password will not be swapped out to a page file needlessly.

Right, but one never knows when the password will be swapped out, or the program will dump core, or the system will go into hibernate, or…

> You can use VirtualProtect with PAGE_NOCACHE on the page the memory resides on to ensure this. But this is really beyond the scope of the article.

I’m not trying to be argumentative, but your solution doesn’t fully mitigate against the scenarios listed at the top of the article. So I’d say it _is_ in scope.

> I know of no OS API which automatically takes care of the situations that you outlined above.

That seems correct. My memory was wrong.

You can use VirtualProtect with PAGE_NOCACHE on the page the memory resides on to ensure this. But this is really beyond the scope of the article.

I know of no OS API which automatically takes care of the situations that you outlined above.

1. A page of physical memory is allocated.
2. Clear-text password is stored in that page of physical memory.
3. That page is swapped to disk.
4. The code to clear the password executes.
5. The page containing the clear-text password is swapped from disk into physical memory.
6. The clear-text password is scrubbed from physical memory.

I don’t think there’s any guarantee that the clear-text password will also be scrubbed from the swap file.

Likewise, I think this solution is insufficient if step 3 above is replaced with: the program crashes and dumps core; the OS is put into hibernate mode; etc.

Ah, I (mis)remembered SecureZeroMemory doing more work than just guarding against compiler optimization.

Are you familiar enough with the internals and intricate behaviors of Python, OS swap, hibernate, sleep, etc. to guarantee that this will wipe the variable, even if it’s been written out to disk?