What that depends on, though, is how "confidential" (and time-sensitive) the information is. In any situation like this, you should assume that someone is watching the transfer. So, is it:

1. information that someone else should never see (like customer data),
2. information that nobody should see for a certain time period (like information about an upcoming product release), or
3. stuff that they just don't really want someone to see (how many hats someone ordered)?

In the first case, I'd consider both encrypting the data and sending via a more secure method (ssh, VPN). Case two, just encrypt it. Sure, someone could record and eventually decrypt it, but by then it won't matter. In the last case, you could probably just email it, but I wouldn't. I'd still encrypt it, but I'm paranoid about those things. I tend to go beyond assuming that there's "someone" who "could be" watching it. I assume that every single computer my data passes through is watching, recording, and has an interest in discovering my information.

The short version of this: never ever take a chance with customer information. Not just for the sake of their business, but to keep your name from showing up on the news as the person who lost the data.

1. create GPG key with client and show them how to use it with a co-operative email client - say Thunderbird and Enigmail
2. make them back the private key up onto a floppy or other external medium, and keep it somewhere safe.
3. when parsing a form, encrypt using the client's public key.
4. store a copy (encrypted!) on the server and email them a copy.
5. depending on client, either automatically delete those stored on server after a certain time (one week?), write a web interface to them, or instruct them on how to download them through FTP. This is just a double check for them so that they can check they received all emails mailed to them
6. If the client has no objections, also keep copies encrypted with your public key - back in the days when I was doing this ('99), I had a few clients who either lost their private key(?) or would buy a new computer and 'forget' to retrieve their key from their old machine. And even if they have backed up their key - well, let's just say you shouldn't be surprised :)

Some new modules look promising - eg Mail::GPG but I have no experience of it.

However you do it, you'll probably get warnings about "using shared memory". A bit hard to do much about though if it's not your box. That's about as safe as you'll get on a shared box IMHO ;-)

cLive ;-)

I think that this is an excellent suggestion. The only problem is that generally the people getting the e-mail have no computer knowledge. I deal with HIPAA every day and have found out how scary their lack of the computer side has been. I transmit the new X12-834 standard file out to over 20+ customers, they all require that it be slightly different, nice standard :-) The log-in to each company's website type interface is currently one of the most used, but a real pain since they all use different methods and it takes time.

PGP and PGP self-decrypting archives have been the best choice for me. Check into it, it will cover your a$$ if they decide to come for you. It also lets you back away from training every customer to some point. It should be integrated into every mail application and should just be the standard as far as I'm concerned, but others here do know a lot more then me on the subject (I'm not being flip, they really do). I PGP everything that might even look like Protected Information...

Good luck, Politicians and computers, SCARRY...

Good luck, Politicians and computers, SCARRY...

Ah, HIPPA. Well, that's a case of having far too detailed requirements! 8)

But it does answer the question of how sensitive the data is. I'd have to agree that end-to-end encryption, as one component in an overall security architecture, is probably called for in this case.

"Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers

Thanks mkenney, nice to see someone dealing with HIPAA. Questions: are your customers receiving encrypted e-mails? And if so, are you encrypting them with PGP and then sending? Or are you sending encrypted attachments? If you wouldn't mind a bit more detail, I'd appreciate it.


—Brad
"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton

It should be integrated into every mail application and should just be the standard as far as I'm concerned, but others here do know a lot more then me on the subject (I'm not being flip, they really do). I PGP everything that might even look like Protected Information...

I agree with you there. I deal with HIPAA every day, not with email, but with electronic data transfers, primarily the mechanism, not file layouts (thats for someone else with more patience for such things than myself :). One of the tools we use is a product called SilverKey (its not perfect but its pretty decent). It creates a 448-bit encrypted exe that can be extracted with a password (like a self-extracting Zip file). We encrypt just about everything, regardless of whether it is PHI or not, and try to get our customers/vendors to do the same for incoming data. Our security folks just implemented secure email using Zixmail (don't know anything about it) that checks the content of the message and will encrypt if necessary. HIPAA can be a nightmare somedays, but I personally think some of it is a good thing, and about time too :-)

Good summation and advice, cLive ;-). No matter what I do, it will take so doing by both me and the client. I will look at the modules mentioned here and by responders.


—Brad
"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton

Let's assume that there's an order entry clerk on the other end. Further, let's say the customer judges the data to be confidential in that revealing it will result in commercial disadvantage, but not sudden death, or extreme legal liability. So, that rules out encrypted email on the one hand, because the order entry clerk position turns over frequently, and a given incumbant may or may not be able to grok S/MIME or PGP/Gpg. That means the data must stay on the server (or its back-end database) after being entered by the customer. If we have good SSL and authentication in place on the web server (it's apparently good enough for the sensitive data to be entered in the first place.) why encrypt the data for storage in the database? Does the database server reside on a insecure network? You had better hope not! So store it unencrypted, and put your effort into ensuring that access mechanisms are solid. (Good passwords, stored securely, changed frequently etc.)

That's one possible set of answers to your question. But it all depends on the details of the customer requirements.

OB module link: GnuPG is a good module for encrypting stuff, as long as the other end of the conversation can deal.

I am not sure I agree with other respondents that suggested encryption may not be appropriate, or that you may gain something by double-encrypting through using an encrypted channel. Encryption can be made as strong as needed by the right choice of key length; if you need absolute security of the data for 10 years, I would recommend 2048 bit keys. And any issues with technical learning curve for dealing with encrypted mail for the customer should be mitigated by automatically decrypting and storing the data at the customer site. You really want to avoid spreading the security of your solution between multiple implementations/aspects, since you would have to make sure all are equally hardened.

There are multiple GPG modules available on CPAN to help you out with the implementation.

Arguing implementation details is fruitless without knowing the particular requirements in great detail. However, I don't believe I "suggested encryption may not be appropriate." I only meant that the 128-bit SSL provided by the web server might be enough, as long as the data were not too sensitive, and if some other factor didn't mandate that the transmission from the web server over email was necessary .

I agree that "automatically decrypting and storing the data" would be useful in overcoming difficulty with personnel training. But I think that this adds complexity, and could only be justified if the sensitivity of the application were such that 128bit SSL was inadequate to protect the data.

As to 2048bit keys and ten years of protection, I'd be wary of that. The number suggests you are referring to public key cryptography. Such systems are probably vulnerable to breakthroughs in quantum cryptography. Whether such a breakthrough is likely to occur in the next ten years is debatable, but a symmetric system is more likely to have a good shelf life nowadays. Second, it is very, very rare that data need protection over a term of ten years, If the data is that sensitive, using the Internet at all needs to be seriously questioned.

But hey, Perl can handle it regardless. 8)

"Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers

I'm thinking more and more of just encrypting and storing the input from the user as you discuss in your 2nd paragraph. Later individual therapists can log on with username and password to see input destined for them.

Question: can you, or anyone, recommend a Perl module for encrypting the user input (I've been using Crypt::CRC for passwords and I suppose could continue with this one). Thanks!


—Brad
"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton