Actually, I did say a bit about the network. Its a windows network, (windows 2003 server, I believe) with the exception of the database servers which are on Linux.

How is it vulnerable after the data is unencrypted? As I stated, the encrypted data is downloaded to a desktop application over SSL and THEN unencrypted via the private key on the desktop users system. (a location not where the servers are).

The data is fairly secure on the way from a users browser to the webserver (via SSL) and even if some program like Ettercap can capture encrypted data .. well, its encrypted.

My biggest worry is the unencrypted data, at the webserver, before I've run it through GNUPG (public/private key encryption at 2048 bits).

So ... how do I protect the pre-encrypted data in memory? or is there no way an ourside program can access data in RAM that perl is using?

Yes, you're correct: if the data stream is unencrypted on the client's machine, that's pretty secure, although you might want to investigate the encryption scheme, local firewalls, etc..

So at the risk of oversimplifying: there's a WAN side and a LAN side. In most networks, the LAN side is highly controlled; that does not sound like the case in your situation. I suggest that you imagine that anyone on the LAN side is capable of running ettercap. I suggest that you run ettercap on the LAN side and see what shows up. You might be OK; you might not be OK.

I think the data in RAM is pretty secure, again with caveats about firewalls, etc.

I think the data in RAM is secure as long as your process has the RAM allocated to it. At least that's how it works in Linux. Not sure about Windows.

Once you free the RAM, other processes can potentially be allocated that same RAM and get access to the data in it. The usual defense against this is to write binary zeros over the sensitive data before freeing that section of memory. I'm not sure how to do this reliably in Perl, though.

Another potential risk is that the sensitive data will be swapped out to disk by the virtual memory system. Linux has a way of locking memory pages so they can't be swapped out (but the program has to be setuid root). I vaguely recall some setting in Windows that erases the VM file on shutdown. I think that would offer some protection against this risk.

I think the data in RAM is secure as long as your process has the RAM allocated to it. At least that's how it works in Linux.

... if you trust the kernel, any loaded modules, and any program with read access to /proc/kmem.

Data in RAM isn't as secure as it seems. Even if you never store a piece of data on disk it can end up on disk as part of your swapfile for months and years if the page in memory its in happens to be swapped out. Perl variables (I believe) also do not guarantee erasure. Even simply reassigning the value of a variable or undefing it does not guarantee that its previous value is gone from memory. This problem just gets worse when you're dealing with more complicated perl constructs (hashes and arrays)

$a=qw{foo};
$a=qw{bar};
[download]

"foo" may still exist in memory somewhere L

Yes, you have every right to be paranoid. Preferably, you will never store unencrypted sensitive data in RAM, but this is isn't always possible. So you aim for keeping it around for a short a time as you can. The swap space is a big problem, too. If it hits swap, it should be assumed that you will never get rid of it.

Under *nix, you wouldn't have a problem with unpriviledged users getting at the RAM. You still have to trust the superuser (which you pretty much have to in any case). A Win32 system is less certain, since there are a lot of Windows admins that are sloppy with permissions, but if properly set, it should be as good as *nix in this regard.

Preferably, you wouldn't store credit card information in the database at all, even encrypted. If you do, it should be for a limited period of time. However, I imagine this would require a lot of changes to your application which are beyond your reach ATM. Encrypting everything was probably the right thing to do, IMHO.

1. The operating system still has access to RAM. This means the administrator has access to RAM. You need to trust the owner and administrator of the machine.

2. A user has access to the RAM of all of their processes. This is definitely true of a shared hosting environment. It likely has one web server. Your scripts are probably being run as separate processes as the same user, or in the same process (this is especially true of IIS).

3. Operating systems will swap memory out to disk. The secure data can be read later from disk. C programs can control if RAM can be swapped or not, but Perl does not have that control. The solution is to keep secure strings in memory for short times as possible. One trick is to overwrite the strings when you are done with them.

I would be most concerned about the shared hosting environment. I wouldn't be concerned about the data in RAM. It takes a skillful attacker on the same machine could potentially read it, but they have easier ways to steal credit cards. The biggest risk in unencrypted numbers in a database and you have already taken care of that. I would be more concerned about the security of the private key. The key, must be accessible to the web server, which means it is probably accessible to other on the web server.

I would be more concerned about the security of the private key. The key, must be accessible to the web server, which means it is probably accessible to other on the web server.

Thanks for your comments but on this comment above, I think I am covered. The private key is *never* available to the webserver. Only the public key. The private key resides on the computer of the owner of the site, in his office, within a desktop application I've set up for them. The info is downloaded encrypted from the database, and then decrypted on his desktop for him to view.

From all the various comments I am gathering that the best solution is a non-shared hosting environment, or at least one that is more controlled. I'd feel much better about setting him up on a *nix system but I've not a choice in the matter.

Thanks again for everyone's insights.