Forum Moderators: coopster
I have a form on my website, and I want the users to be able to fill it out, click a button, and have it emailed to me. OK, I can do that with the PHP mail function, no problem.
My question is, how can I make that secure? There will be sensitive information on the form (ssn, etc.). Do I need to use SSL? Or is there a way to make the php secure?
Thanks.
I saw a good definition of e-mail once. E-mail is anything that you won't mind seeing posted on a highway billboard.
The only option I'm aware of would be an SSL/Certificate solution if you want secure email. Speaking to PHP, mcrypt might hold a solution. Perhaps someone with a better understanding of mcrypt can add their thoughts.
> how can I make that secure?
It all depends on what the meaning of 'that' is...
To protect sensitive data, it is important to look at the entire process line, from end to end. It is more than just to 'make the php secure'.
The following comes into mind:
(0) check your national information security legislation about the legal implications for processing and storing private sensitive data.
(1) a visitor fills your form: you should offer him/her a [page...] with a valid SSL-certificate on your server so that this part of the communication cannot be tapped and the user has a warm fuzzy feeling that you seem to care about security.
However, the visitor does not know if your server and your back-end is secure or at risk (or already compromised?)
(2) therefore your web site should sit on a tightly administered server box with a professional administration to have all known vulnerabilities and holes patched and closed and regularly checking the intrusion detection and other system logs for operational irregularities and oddities.
You need an own box, no shared hosting (other shared customers are additional risk, either by contributing to more weakness of the server by 'bad' own software scripts, or by actively snooping around in your account).
(3) The mail transport has to be secured: you should encrypt the mail data before sending them out.
One way could be to put a public key on your server to encrypt the mail data (gnuPG). Be sure not to keep cleartext copies somewhere in /tmp.
(4) The receiving end: receiving a mail and decrypt it with the GPG private key is just one thing.
How will the sensitive data then be stored? How long? Is that machine secure? Not an already trojaned Windows box directly hooked to a DSL line but another tightly administered server behind a firewall and a DMZ? How easyly could the data be read/ stolen/ compromised from that end? How many local users have access to these data?
(5) to lessen the overall risk you may think about what sensitive data you really need from your users, as users may think about giving out too much private data for nothing.
Sorry, that there is no simple answer ...
Regards,
R.
This client is an attorney, and he currently has new clients print a form off his site, fill it out, and bring it to him. He now wants them to be able to email it to him. So I think I'll recommend a plain old insecure form that uses the php mail function, but does not ask for ssn, and maybe no address, either. How does that sound?
Thanks for your help!
Getting the data securely from the client to the webserver is easy (SSL + digital cert). Getting it from the webserver to the merchant is where it can get tricky.
1) Use gnuPG to encrypt the data and set up the merchant's email client to decrypt (as Romeo said). Advantage: nothing stays on the server. Disadvantage: You'll need to walk your client through generating a private key and teach them to decrypt their messages.
2) Set up an SSL connection to a machine in the merchant's location. Not very practical usually, so that's all I'll say.
3) Store the info on the server securely + create a secure interface for the client to retrieve the info. Can use MySQL's crypt function for example. Then write a script that the client can connect to via SSL to decode the message. Advantage: Much easier on the client. Disadvantage: Cost and security. The data is stored on the webserver. If you use MySQL's crypt like I mention the password will need to live in the scripts (there's a workaround, but still not optimal). I wouldn't recommend this in a shared hosting environment. I'd highly recommend that the database be on a separate server, behind a firewall on a local subnet (not directly accessible from the web).
Remember, a typical webserver is a security nightmare. Storing sensitive data on a webserver is not usually a good idea.
just a thought, but why not use an upload script? At least if you secure the directery, not having ssl, seems a pretty good idea. Any thoughts on security here vs. email?
Interactive Gun: do you mean just upload the form's data to a file instead of emailing it? Then SSL could encrypt the transmission of the data from the web page to the server, and the directory the file is stored in could be password protected. But then how does my client securely get the file off the server? He doesn't have his own server, and I'm not sure yet where his current site is hosted.
Can you guys tell I know nothing about security?
1) Use gnuPG to encrypt the data and set up the merchant's email client to decrypt (as Romeo said). Advantage: nothing stays on the server. Disadvantage: You'll need to walk your client through generating a private key and teach them to decrypt their messages.Not sure if my client could handle that, but if he could, it might be an option.
OK, I'll stay away from that.
2) Set up an SSL connection to a machine in the merchant's location. Not very practical usually, so that's all I'll say.
My client doesn't have his own server, so this option won't work for him.
3) Store the info on the server securely + create a secure interface for the client to retrieve the info. Can use MySQL's crypt function for example. Then write a script that the client can connect to via SSL to decode the message. Advantage: Much easier on the client. Disadvantage: Cost and security. The data is stored on the webserver. If you use MySQL's crypt like I mention the password will need to live in the scripts (there's a workaround, but still not optimal). I wouldn't recommend this in a shared hosting environment. I'd highly recommend that the database be on a separate server, behind a firewall on a local subnet (not directly accessible from the web).
I'm still leaning towards removing sensitive data from the form, and having him enter that by hand when he sees the client in person.
A setup such as this may or may not work for you. You said that the client does not have their own server, but their website must be hosted somewhere, so they have access to a server. This server may be shared, or there may be other conditions that are less than ideal. But this is probably the most secure method that would be the easiest to implement and use.
