Are passwords in memory?

Question

I have an encrypted HDD (dm_crypt). That's why I store my passwords in a simple text file. I usually copy/paste the passwords from it. Ok!
Q: If I open this text file then it goes into the memory. So all my passwords in clear text format goes "there"..will the passwords be deleted from the memory if I close the text file? Could the memory that I'm using accessed by other in real time? Are there any better/more secure ways to copy/paste my passwords? E.g. to set that if I press Ctrl+V then it should clear the clipboard? Running Fedora 14..
Or how can I "encrypt my RAM"? Are there any ways for it?
Thank you!

Answer 1

Bluntly put, yes, they could. That's the massively oversimplified answer.

The more complicated answer is that you need to understand how your operating system handles memory. You might hear talk of rings, privilege levels etc. Let me explain briefly:

• When your operating system starts (getting passed the whole 16-bit BIOS thing) it basically has a whole pile of memory (your entire RAM) to work with and does so in a privileged mode, which means it can do whatever it likes to any part of memory.
• However, x86 architectures since 1980-something before I was born have supported the concept of protected mode, where the CPU hardware provides mechanisms to allow the operating system to launch applications in such a way that their memory addresses are segregated.
• Thus this protected mode allows the operating system the ability to create a virtual address space for each application. What this means is that an application's concept of memory is not the same as actual physical memory addresses and that the application does not have privileged access to memory. Indeed, applications are directly prevented from modifying each other's memory addresses because they can't see it, except via well defined requests to the operating system (syscalls) for requests for things such as shared memory, where two processes share an address space.

(this is a simplification and I'm skipping huge chunks for brevity's sake, but that's the gist - applications have their requests to access memory managed by the OS and hardware).

So theoretically, you're OK, right? Not technically true. As I said, operating systems do provide well defined ways to access other processes' memory. In terms of the possibilities, here are how a few might present:

• If I dump the memory of the application, I can resolve that stored password fairly easily.
• A debugger or an appropriately designed userland-style rootkit might be able to provide me access to that memory. I'm not an expert on such techniques, but know it can be done under certain circumstances.
• Finally, the operating system may be self-defeating here. The virtual memory you have access to has some other consequences. Operating systems present it as virtual because they often swap memory in order to ensure there is sufficient RAM available for currently running apps. So an interesting attack might be to cause the system to swap, then crash it and examine the swap partition. Is your swap encrypted too?

Finally, I should point out that if your attacker is running code in the kernel via a kernel module, the game is over anyway, since there is nothing stopping them searching your memory space for ascii strings.

However, to be realistic:

• If your kernel is compromised via a rootkit, a keylogger is probably easier to implement than something designed to scan memory in terms of grabbing your passwords.
• Userland style rootkits involving debuggers for evaluating programs not designed to be debugged (i.e. without debugging symbols etc) are not going to be an easy thing to implement, even if they are theoretically possible. It also isn't easy to exploit this - you, the user, would have to be tricked into executing said editor under the debugger which probably implies social engineering or physical access.

My recommendation, however, is that you never store plaintext passwords anywhere. If you need a reminder, I suggest using a partial incomplete prompt that will jog your memory and allow you to deduce the passwords but reasonably prevent other people from doing so, even if they know you. This is very far from ideal, but better than plaintext passwords.

Answer 2

I would use KeepassX, which uses encrypted file via your password and optionally via key file and would not care about these theoretical problems.

Answer 3

• Using Keepass, you can also block clipboard managers, so they won't receive the notification when the clipboard changes (this prevents text pasted through auto-type to be saved in clipboard managers software for example. This happens without this auto-type enabled)

• There's also a function to split the secret that protects against applications that could regularly check the clipboard contents.