Mail security question

jasonyoung

I'm collecting info via forms, wrapping the variables up and emailing them. The good part is the forms are on https, plus they're behind a login script. But the resulting email itself is wide open.

What are my options for securing the message?

I looked into GPG, but my mail is being generated on a shared hosting server, so any custom configs are pretty much out.

Seems like I should be able to encrypt the mail somehow before it leaves the server and have Outlook decrypt it (has to be Outlook, no options on this one) on the receiving end.

Any thoughts?

Thanks in advance.

jasonyoung

Nobody has any ideas? I'm sinking here...

crazychris

It can be signed, but not really secured.
Put the message into a txt file, zip it with a password and send that?

jasonyoung

When you say signed, you mean...?

As for zipping /w a password, I guess at this point they (bad guys) would have to intercept the email, extract the attachment and run it through a cracker. All possible events.

Sooooo, if there aren't any real secure methods to get the goods here, whattya think abou this approach.

Instead of emailing the form contents, shove them into a MySQL DB. Then the email would contain a unique (random maybe) ID number with no trace back to the server holding the MySQL DB. Since we know how to get to the DB, we could web (over HTTPS) to a form, enter credentials and submit the unique ID. Submitting the ID would return a form w/ all of the variables. This could be printed.

Am I lame?

crazychris

using mysql, you can also use encrypt() and decrypt() and save it as a blob of binary, so even more secure. It's a valid method, and I have used a similar method for short-term storage of data in tables before.

signed is not encrypted, just verifies the sender.

jasonyoung

does the encrypt() / decrypt() only apply to the data while its in the DB? Would I use PHP to encrypt on the INSERT INTO and decrypt on the SELECT statements?

thanks so much for helping me with this. VERY appreciated.

as for the:

I have used a similar method for short-term storage of data in tables before.

I was thinking about having a DELETE button on the form used to view the submission, this way you could view it, print it and delete it all at once. Is this what you mean?

crazychris

sure is!

insert into table (field) values (encrypt('my data','salt'));

once read, delete it. You could even have a rolling salt, so that the decrypt() for one message is not the same as the next.

jasonyoung

Do you have any examples for the rolling 'salt' command. I've tried this before but it failed. I went to find what I had, but I must have deleted it.

Thanks so much again for all of your input. Rarely do I get such wonderful feedback!

crazychris

for salt, one of two methods is easy to achieve.

use the unique id as added slt.
Create a uniq_id() and save this with the data.

In either case, use a base salt (e.g. PassWorD) and the unique code/id above in some form (e.g. PassWorDnewsaltybit) to encrypt the data. If the unique id is numeric, then use a bit of math to mess it up some more.

$salt="salt";
$uniqid=mt_rand(111111,999999)*date("jsih");
$uniqsalt=$salt . $uniqid;
$q="insert into table (data,salt) values (encrypt('$data','$uniqsalt'),'$uniqid')";

In order to decrypt, you must use the stock salt, plus the new salty bit from the data itself. This is a very basic example, but you can use more bits to shake it up some more again. Merging the salt means that if someone gets hold of one ot the other, they still don't get the data. However, if you loose the salt, you loose the lot!

jasonyoung

ok. so I just found out my host does not support mcrypt. does this mean all of this is for nothing? basically they said shared hosting accounts cant use encryption. the good news is the agent i spoke with probably doesn't know what day of the week it is.

i'm really bummed out unless you think I may still have options.

crazychris

the encryption is all done in MySQL, not php...

what about encode/decode? That's pretty basic and works on every mysql server I have used....

jasonyoung

how does the security provided by encode/decode measuere up?

crazychris

pretty good, wouldn't sustain any lenghty attack, but nothing will. If you're looking for short-term, one off encoding, then it's fine.

MarkR

Storing stuff encrypted in the database sounds like a fairly daft idea. You have to trust that your database is not compromised, however your app is constructed. As the database is often on the same machine, if the database is compromised it's also quite likely that the app is too.

I can't see any merit in keeping stuff encrypted in the database itself. If you're worried about the server being (physically) stolen and someone obtaining the data, use an encrypted filesystem to store the (unencrypted) database on. But that's no good if you want it to be able to do unattended reboots, as someone would have to enter the key each time for it to be worthwhile.

If you're worried about data being sniffed on its way to/from the database, use an encrypted DB connection or VPN.

Mark

jasonyoung

Hi Mark and Chris,

This is all hosted off site. I don't know if MySQL is co-located on the same server or not. Theft isn't anything I can control, that's what I'm paying the hosting company for.

My real concern is the sensitive data maintained in the DB. I do have an active SSL cert so the browser is doing what it can to add a layer of security. Maybe it would help to paint a picture for all of you, so you know what exactly what I'm up against.

We are a field support team for PBX's and any related peripherals (ie. voice mail servers, call accounting servers, VoIP appliances...). All of these "devices" participate on the LAN/WAN in some fashion. With the amount of accounts and the quantity of Technicians, there's no easy way to keep IP's, SIP accounts, usernames, passwords, gateways and so on updated for all of us. We devised this idea as a page a Tech would go log into (via HTTPS) and update account info. This info would be kept in a MySQL DB. For this, I can't have one-way encryption since we would be referring back to the DB for passwords and IP's...

Since it accessible from the internet, I wanted to add as much security to the app as possible. If you have any suggestions, I'm all for it!

Thanks.

crazychris

in that case, don't hard-code the salt on the server for encoding/decoding, make the users enter it over a secure ssl connection each time (each login). That way the salt and the data are never together.

On occasion (staff movements etc.) the salt can be changed, simply updating all the data with the new encrypted version, meaning that anyone who leaves with the password will not be able to use it, and if they get access to the data, then can't decode it either.