The raw memory itself isn't safe either.<p>Ed Felton did some great work (2008) where he physically removed the sticks of DRAM from one computer, stuck them in another, and read their contents. But doesn't DRAM lose it's content without continuous power? Not if you turn a can of compressed air upside down and spray the chips first, cooling them to -50C! He used this to recover encryption keys and defeat whole disk encryption.<p>Pretty crazy stuff: <a href="https://citp.princeton.edu/research/memory/" rel="nofollow">https://citp.princeton.edu/research/memory/</a><p>update: link to images/videos: <a href="https://citp.princeton.edu/research/memory/media/" rel="nofollow">https://citp.princeton.edu/research/memory/media/</a>
Windows has a CryptProtectMemory() function [1] that can be used to encrypt in-memory secrets using an OS-allocated session key. As far as I know the key is stored in non-paged memory in kernel memory space.<p>On Linux, libgcrypt can do encrypted malloc, which might also help.<p>[1] <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa380262(v=vs.85).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/windows/desktop/aa38...</a>
So given the stories about the Target hack, which mentions "memory scrapers", how can this be done on an entire network of (Windows in this case, no idea what version) systems? I assume you would have to have discovered an escalation attack that gave you sufficient privileges to read another processes' memory. But even given that, how do you find what bytes are useful to scrape?
Would something like TRESOR[1] along with RAM encryption help? Or would this just move the attack target to the CPU itself? (Certainly this would be harder to attack than sticks of DRAM, like was demonstrated by a group a few years ago)<p>I guess the number one thing is to prevent physical access, and failing that, make an attack that targets RAM take longer.<p>1. <a href="http://en.wikipedia.org/wiki/TRESOR" rel="nofollow">http://en.wikipedia.org/wiki/TRESOR</a>
No, and neither are cryptographic keys derived from passwords, and neither are cipher tables derived from cryptographic keys.<p>A simple defense would be to access all such material through a permutation table. (Which need not be explicitly stored in memory, but could be computed by means of multiplication modulo a prime.)
> virtual machines and cloud computing cannot be ultimately safe<p>Can somebody with more expertise comment on this? I was under the impression that virtualization software (Xen etc) was deemed safe?
Another recommendation that I learned from an old boss is the following.<p>1. Store password in a function and return the password.
2. Whenever the password is needed call the function.<p>Example in JS.<p>function getPassword(){
return 'I am a password';
}<p>if(req.data.password == getPassword()){
passwordIsCorrect();
}else{
passwordIsNotCorrect();
}<p>This is not for sure. Core dump and debug dump usually dumps variables, but not the source code of program.