Windows memory protection: VirtualProtect vs CryptProtectMemory

Question

So my question is pretty straight forward:

For securely storing passwords in memory which one is better (ie more secure, harder to bypass, less performance heavy, more compatible with different Windows versions, etc): VirtualProtect (with PAGE_NOACCESS ) or CryptProtectMemory (with CRYPTPROTECTMEMORY_SAME_PROCESS ) or a combination of both?

Implementation-wise VirtualProtect can only protect whole pages in memory (multiples of 4096 bytes) while CryptProtectMemory can protect multiples of CRYPTPROTECTMEMORY_BLOCK_SIZE (16 bytes). So CryptProtectMemory has less overhead.

Are there any security considerations to be taken into account that I am not aware of? I know the PAGE_NOACCESS restriction could be lifted by another malicious process using VirtualProtectEx . What about CryptProtectMemory though?

(I already have implemented both, so I could add code if that helps)

Answer 1

CryptProtectMemory does much more than VirtualProtect. Think of, for example, memory that has been paged out to disk. If you just use VirtualProtect then (assuming the page is not locked) whatever is in memory will get written out to disk. CryptProtectMemory actually encrypts the memory rather than just changing bits that modify what the CPU allows to happen. In that sense I would expect VirtualProtect to take less time, but really, passwords get used so infrequently that efficiency should definitely take a backseat to security concerns.

Now, the OS will normally not allow the paging file to be directly read but there are ways around that. But honestly if you have to worry about security to that degree (protecting against memory being paged out then power being cut to the machine and the disk being plugged into some other system) then there really is not a whole lot you can do. Physical control over a system is pretty much game over as far as security is concerned - after all, even as the remarks to CryptProtectMemory say the password has to be decrypted at some point if you are actually going to use it.

About the best that can be done is to keep the plaintext password around for as short a time as possible and only store that decrypted password in a locked page - that is one that is not subject to paging. I think Windows allows a very limited number of pages to be locked into memory even without the SE_LOCK_MEMORY_NAME privilege but I am not certain of that.