Someone told me that his company is storing all application data (at least the sensitive data I guess) in RAM for security. Their application runs for long periods of time, so data stays in memory for a long time.

Is it more secure to you keep sensitive data in RAM instead of disk? Is RAM harder to access/exploit, or is it just because it's volatile?

  • it sounds as potential problem to me, when all sensitive data remains in RAM. what happens if RAM is physically gone ?
    – ElYusubov
    Commented Jul 3, 2012 at 14:41
  • 1
    How does the data get into ram? Doesn't it have to start from a database or a file? Of course the data could be encrypted.
    – mhoran_psprep
    Commented Jul 3, 2012 at 14:43
  • 4
    Not to mention data in memory can get to disk when OS swaps.
    – herby
    Commented Jul 3, 2012 at 14:46
  • 1
    @herby: Having no swap solves that problem.
    – Blrfl
    Commented Jul 3, 2012 at 15:02
  • 1
    @Blrfl Or just marking the memory pages as non-swappable, using an API such as VirtualLock
    – Polynomial
    Commented Jul 3, 2012 at 15:36

7 Answers 7


Keeping information in RAM can enhance security, if done right and if the requirements allow it. I'm going to show two security architectures where keeping the data in RAM provides a security benefit. These are fairly specific scenarios; most of the time keeping data in RAM doesn't help.

Protection against file dump attacks

Consider a web application that manipulates files on the server. One kind of vulnerability that it might have is to allow users to download files that are not supposed to be exposed remotely at all. If a piece of critical data is only stored in the memory of some process(es) (here it's not RAM that's relevant, but virtual memory as opposed to the filesystem), then it will not be revealed by a file exposure vulnerability.

Of course, the data may be revealed through other vulnerabilities, for example with an attack chain that first arranges to have the confidential data written into a file (such as an error dump of some kind) and then to have the dump file exposed.

Keeping the data in memory only helps if it isn't loaded from a file in the first place. Where do you get the data after boot? The data could be stored encrypted, but that requires someone to enter the decryption key after a reboot; this is no good for most web applications as they can't afford the downtime. The data can be stored in a file that requires additional privileges that the web server does not have: the web server process would start with elevated privileges, read the file, then drop privileges. This raises the bar for an attacker since they would have to find a local privilege escalation vulnerability in addition to the remote vulnerability that gave them a foothold. The benefit remains small because many attacks that give the attacker unprivileged local access also provides a way to inspect the memory of active processes.

Defense against some attacks with physical access

Information in RAM disappears if the RAM is powered off. Hence, if the attacker can only manage to grab hold of the target system by powering it off, he will have more trouble accessing data if it's only in RAM. However, storing the data in RAM won't do much good on its own, because RAM has some data remanence of a few seconds to a few minutes. (See also Recover the prior contents of RAM from a turned-off PC?). This is enough to reboot the computer into an operating system that's controlled by the attacker or to transfer the RAM sticks into another computer. (See also Are there volatile memory chips which dont retain data after power off?)

Encrypting the data helps, but you have to store the encryption key somewhere. And if you're going to encrypt the data, you can do this on a disk anyway. Encrypting most the sensitive data does help in that if the attacker is unlucky enough that the key is lost, the data is safe.

So in order for storing the data in RAM to enhance security, there have to be additional physical security measures. If the RAM is inside a tamper-resistant case that causes the power to be turned off if opened, it might be enough to exceed the RAM's remanence. For better results, tamper attempts should cause the motherboard to zero out the RAM before turning off the power (which means the motherboard should have a small battery). Encrypting the data helps because then only the key needs to be zeroed out, which takes less long. Even if the anti-tampering measures can be defeated with good enough tools, it makes the attack more difficult than a simple pass-and-snatch (an intruder with a bolt cutter is more noticeable than an attacker with a circuit board inside a cellphone case).

Going further, it can be worthwhile to encrypt RAM, and ensure that the key is kept in the processor cache or registers. The attacker typically has to reboot to try obtaining the key; rebooting quickly enough to find a pristine cache and without clobbering the cache is harder, and unplugging the CPU is harder than unplugging RAM.

There is of course always the problem of where the data is loaded from (or if it's encrypted, where the key is stored). Some use cases value confidentiality over availability and can afford to require someone to come and enter a key after each reboot (e.g. a big datacenter might have someone available to do it around the clock, in case an intruder gets that far). This security measure can also benefit systems that process data but do not store it.

  • How would RAM encryption work? Wouldn't it break DMA?
    – user541686
    Commented Apr 15, 2018 at 5:49
  • @Mehrdad RAM encryption can be done with specialized hardware that processes data as it goes onto the bus, or in software if you have some high-security memory (e.g. in-CPU cache) and you treat the rest as swap. Memory used for DMA has to be in cleartext unless the device itself has a shared communication key with the CPU. Commented Apr 15, 2018 at 9:59

They are feeling comforted by a false sense of security by obscurity

If someone gains root access to your machine then they can see all the contents of everything that any application can. Encryption won't help if the application has to be able to work with the plain text since the application will have to store the keys somewhere. Hiding those keys is where the security by obscurity comes from - eventually the intruder will find and copy them.

The above notwithstanding, having all data held in RAM does provide a measure of physical safety since loss of power means loss of data. However, once that data is out of RAM and on to a persistent store, say through a memory swap operation, then all bets are off. Also, any data center worth its salt will have a solid physical security plan in place that is insured against break-ins so it's kind of pointless.

Of course, keeping data in RAM for fast access for performance reasons is completely valid, just don't think that security is somehow enhanced as a result.

  • 1
    One improvement on this is to store the encrypted data in nonpaged pool via a kernel module. That way you're placing the data in the same area of the system that you would consider the final bastion of integrity. Once kernel-mode is compromised, the entire box is compromised. Not sure how this stacks up on Linux systems that allow /dev/kmem access to root, but at least it adds an element of complexity to a potential attack.
    – Polynomial
    Commented Jul 3, 2012 at 15:41
  • 2
    Alternatively, they could use a HSM.
    – Polynomial
    Commented Jul 3, 2012 at 15:42
  • 2
    @Polynomial "that allow /dev/kmem access to root" I believe this is usually turned off on "harden" sensitive systems
    – curiousguy
    Commented Jul 3, 2012 at 16:25
  • Your first and last sentences are too peremptory. It depends what the flow of data is, as you discuss in between. Commented Jul 3, 2012 at 18:10
  • @curiousguy Figured as much. I'm not that familiar with Linux hardening, but I had a feeling such a thing wouldn't be allowed.
    – Polynomial
    Commented Jul 4, 2012 at 14:12

I'm surprised that nobody has pointed out the danger of core files. Most Unix or Linux variants will helpfully write a "core" file to disk when a process crashes. The core file usually contains that process's RAM contents at crashtime so that you can try to find what data or condition cause the problem. Later, a user with the right privileges can access this file and search for remnants of the data that the dead process once kept in memory. For this reason alone I'd say that data kept in memory is not really any more secure than data stored on disk. Anyone have anything to add about this?

  • 2
    Anything to add? Sure: ulimit -c 0. Obviously, if you want data to be kept in RAM, you have to disable things like swapping to disk and crash dumps. Commented Jul 3, 2012 at 23:32

It is marginally harder since it does go away when the machine is powered off. It requires someone to gain access to the machine when it's running rather than just stealing the hard-drive/laptop.

That said, the memory needs to be populated from somewhere. If that's a remote machine, then you've opened that avenue of attack which is usually more risky than keeping the data on disk in the majority of scenarios.

  • "That said, the memory needs to be populated from somewhere." Hear! hear! "If that's a remote machine" if that's what the person recommending the "all in RAM" solution, they should say so. "I keep data in RAM" is an empty security concept if you don't say where it comes from.
    – curiousguy
    Commented Jul 3, 2012 at 16:34

Memory might be harder to retrieve sensitive information from than disk, but the possibility still exists. If the data is not also encrypted, then it can be compromised. We recently looked into secure strings in PowerShell for this reason. Yes it needs to be plain text at some time, but not while waiting to be used. Data from RAM can be retrieved from a forced crash dump, and just because it's in RAM doesn't mean it never gets on the disk during a paging operation.

  • 1
    In order for storing data in RAM to help, you'd have to design the whole system for this kind of security, it's not something you can plug into an existing infrastructure. Commented Jul 3, 2012 at 18:07
  • @Gilles - I believe you are correct for large amounts of data as the OP mentioned. PowerShell has methods specifically for working with secure strings, but usually it's a small amount of data, like a few variables, or a password.
    – Bratch
    Commented Jul 3, 2012 at 21:57

I think this is mostly silly. If an attacker can access the data on your hard drive, they will almost certainly have access to your memory as well (and vice versa). Regardless of where the data lives, it needs to be encrypted. That's the real solution to this problem.

Besides, keeping all your data in memory can have some bad side effects in your application (memory bloat, more complicated code, etc.) This isn't the "right" way to solve they problem.

  • “Regardless of where the data lives, it needs to be encrypted.” And where do you store the encryption key? “This isn't the "right" way to solve they problem.” How can you know, without knowing what their problem is? Commented Jul 3, 2012 at 18:05

What can help is new memory encryption technologies like Intel's SGX and AMD's SEV that rely on a hardware root-of-trust. In the case of Intel SGX, an application's data is encrypted in memory using a key that is accessible only to the CPU, and can be pinned to a specific code, such that no other application (even a root user) would be able to access the data. Moreover, it is possible to encrypt stored data (at-rest) using a CPU specific key, which prevents some of the aforementioned attacks.

You must log in to answer this question.