views:

182

answers:

5

I'm working on a Java password manager and I currently have all of the user's data, after being decrypted from a file, sitting around in memory at all times and stored plainly as a String for displaying in the UI etc.

Is this a security risk in any way? I'm particularly concerned with someone "dumping" or reading the computer's memory in some way and finding a user's naked data.

I've considered keeping all sensitive pieces of data (the passwords) encrypted and only decrypting each piece as needed and destroying thereafter... but I'd rather not go through and change a lot of code on a superstition.

+2  A: 

Yes it certainly is, especially since you quite trivially can debug an application. Most code dealing with encryption and unsafe data use char arrays instead of strings. By using char arrays, you can overwrite the memory with sensitive details, limiting the lifetime of the sensitive data.

disown
If you can debug a program, you can grab the ciphertext AND the key and generate the plaintext yourself. Debug privileges are practically impossible to defend against.
Kevin Montrose
Yes, you have a point there. But it does make a text search a little bit tricker.
disown
Why a dump when reading from `/proc` can do just fine.
Xepoch
@Xepoch: Well, if an attacker knows the victim's root password it's not my fault.
Kavon Farvardin
@KavonFarvardin, I have not tried this lately, but I believe `/proc/PID/mem` also works as user-owned procs.
Xepoch
+11  A: 

If your adversary has the ability to run arbitrary code on your target machine (with the debug privileges required to dump a process image), you are all sorts of screwed.

If your adversary has the ability to read memory at a distance accurately (ie. TEMPEST), you are all sorts of screwed.

Protect the data in transit and in storage (on the wire and on the disk), but don't worry* about data in memory.

*Ok, there are classes of programs that DO need to worry. 99.99% of all applications don't, I'm betting yours doesn't.

Kevin Montrose
So, essentially, if I were to make the change and keep all of the data encrypted, it would just make something already very hard/unlikely even harder. I can imagine finding the byte[] containing the AES key is _much_ harder than finding plaintext.
Kavon Farvardin
Not really in Java; it becomes a search for a byte[] object of a given size (as opposed to a String object) in the heap. But yeah, the kind of attacker you're concerned about is so vanishingly rare you'd be wasting your time trying to defend against them (and probably not succeeding).
Kevin Montrose
Couldn't agree more with you Kevin.
rFactor
+2  A: 

In theory, you cannot protect anything in memory completely. Some group out there managed to read the memory contents 4 hours after the computer was turned off. Even without going to such lengths, a debugger and a breakpoint at just the right time will do the trick.

Practically though, just don't hold the plaintext in memory for longer than absolutely necessary. A determined enough attacker will get to it, but oh well.

Seva Alekseyev
+1  A: 

It is worth noting that the OS might decide to swap memory to disk, where it might remain for quite a while. Of course, reading the swap file requires strong priviledges, but who knows? The user's laptop might get stolen ...

meriton
A: 

If possible, try to avoid having passwords known even to you... password hashing :)

Veli