Re^2: Customer data encryption

I feel that the customer is responsible for the collected data at his end, and should protect the output file with appropriate permissions. The original O/S config+log files are not encrypted (unless the administrator uses an encrypted filesystem scheme), but rather by default O/S permissions.

But it is my responsibility to (at all cost) protect the customer's system info on my side, so ikegami's comment on securing the storage is important in my view. Being overly cautious is fine... and the suggestion about an alternative like a SSL webserver for uploads sounds good too.

When I get a bit of extra time, I'll do some tests to compare the straightforward RSA file encryption against the hybrid method, and post the results. I have a hunch that the time differences will be significant if the keys are generated upfront.

Niel

Comment on Re^2: Customer data encryption

Replies are listed 'Best First'.
Re^3: Customer data encryption by salva (Canon) on Feb 26, 2007 at 09:16 UTC
SFTP is actually a full featured remote file system protocol. Using it, it would be posible to process the data without downloading it first to the local harddisk. You could even write the output file directly on the remote host so sensible data never gets stored on your system. Net::SFTP or Net::SFTP::Foreign would allow you to do so. For maximun security, ssh keys should be protected by a keyphrase, but that would require to launch the process manually.	[reply]
Re^4: Customer data encryption by 0xbeef (Hermit) on Mar 01, 2007 at 14:28 UTC
Regarding SFTP, I would not like to make to make many assumptions about the customer. Consider the network policies of the institution. At most banks where I provide support, almost every outgoing protocol (FTP/SSH/SFTP) is blocked. Some organisations ONLY allow HTTP/HTTPS, so I would then have to set up a SSH tunnel over HTTP, which adds additional complexity and assumptions into the mix. In other words, if I do provide an SSH/SFTP mechanism, I would consider it a secondary method. Niel	[reply]