The requirement for security begs the question of how and why common mechanisms for collecting information from web forms are not secure. The following are many of the security problems involved with the use of standard web forms:

• The data sent from your client to the web server is unencrypted; it is susceptible to eavesdropping, modification, and interception.
• Your client has no way to ensure that the web site s/he is using is really yours and not one set up to pretend to be yours and to trick the client into revealing up sensitive information
• If your web form emails the collected information to you, then you suffer from all the insecurities inherent in normal email, such as:
  • Eavesdropping
  • Interception of messages
  • Modification of messages
  • Duplicate or re-sent messages
  • Unsecured backups viewable by other people
• If you store the sensitive information on the web server or in a database, this data is also susceptible to
  • Being ready by others with access
  • Unsecured backups viewable by others (sometimes long after the fact)
  • Modification

These issues are all very serious -- especially the strong possibility that undesirables could intercept or read the sensitive data... sometimes long after it was collected by looking at backups or other archives.

It is very important to be able to mitigate all of these issues so that the privacy and security of the data is guaranteed.

The first part of the solution is to use a "secure web site". This means getting an "SSL Certificate" and installing it in your web server so that your clients can connect to your web site securely using URLs that start with https:// (which designates a secure connection), versus URLs that start with http:// (which designates an insecure connection). Using a secure web site gives you the following security enhancements:

• All data sent to and from the web site and your clients is encrypted so that it cannot be eavesdropped upon, intercepted, or modified during transmission. This is like a "secure pipe" between the client and your server that no one can penetrate.
• If your secure SSL Certificate is purchased from a trusted organization, like Thawte or Verisign, then your client can trust that s/he is connecting to your actual web server and not some other server setup by a malicious entity who is trying to use a fake secure connection. Why? Trusted third parties will verify your identity and right to secure your domain before granting you an SSL certificate in which they vouch for your legitimacy! This is very important, as anyone can create an untrusted certificate which provides encryption but no measure of assurance that you are connecting to the intended party; however, most web browsers will immediately warn you when they encounter such untrusted certificates.

For more information on SSL, see How Does Secure Socket Layer (SSL) Work?

So, use of a secure web site protects the sensitive information during the first leg of transit -- from the client to your server -- and it also helps the client trust that s/he is connecting to the intended web site. However, we still need to ensure that the data gets from the web server to you in a safe and secure way.

The safest way to do this is to use PGP or S/MIME and keep the "private key" on a separate computer from the web server. We will first examine the common case where you want the sensitive data securely emailed to you.

In PGP (and S/MIME, or any "public key" or "asymmetric" cryptography system, more details ), there are two "keys" -- a public one and a private one. The beauty of these systems is that anything encrypted with one key can ONLY be decrypted with the other. You can also have password on either of the keys so that they cannot be used without knowledge of the password. So, here is how this technology will help us:

1. You will create a PGP or S/MIME public and private key pair.
2. You will ensure that the private key has a good password.
3. You will keep the private key in your email program on your personal computer.
4. The public key will be put on your web server.
5. The sensitive data will be encrypted using your public key and then emailed to you.
6. When you get the email, you can decrypt it because you have your private key and you know its password. Most common email programs, such as Thunderbird and Outlook, support use of PGP encryption through the addition of plugins or addons. S/MIME generally integrates without additional software.

The security benefit of this scenario can be summarized as follows:

• Once the data is encrypted with the public key, it can only ever be decrypted by someone in possession of the private key and its password. Thus, no matter where the data goes or is kept -- it is safe. The data is secure during transmission and storage -- even though it is being sent in a normal email message.
• If someone were to modify the encrypted content of the message at all, that action would corrupt the message and no one would be able to open it. Thus, the data is safe from tampering. The message can be destroyed, but the original content cannot be altered.

PGP and S/MIME both ensure that the sensitive information that is emailed to you is secure during the transit from the web server to your email, is safe during any backups on any machines, and cannot even be accessed in your email unless the person accessing it has access to both your private key AND its password (which should be unrelated to any other passwords you have).

You could also secure your form data by encrypting it and saving it on the web server itself. You could then login though your SSL-secured web site and have your web site decrypt and display the sensitive information to you in your web browser. The procedure for this scenario is as follows:

1. The web site contains both the public and private keys, but doesn't know the password to the private key.
2. The web site encrypts the sensitive data it receives with your public key and stores it in a database or file.
3. You access your secure web site and login.
4. You request to view one of the items of encrypted sensitive information.
5. The web site asks you for the password to your private key.
6. You provide the password through a secure web site form.
7. The web site uses that and the private key to decrypt the information and the sends it back to your web browser.

This mechanism allows storage and retrieval of sensitive data in a way that doesn't depend on email and that can be shared with anyone to whom you grant access to your secure web site and knowledge of the private key password. It provides all the same benefits of sending the data in encrypted email messages -- secure transmission and storage and non-modifiability.

This database-based mechanism also allows you to communicate with multiple people through your web site -- "sending" them secure information that they can "pick up" by logging into your secure web site and providing the password to their private key (which could have been automatically generated by the web server itself!)

One natural question that follows from the proposed solutions in the previous section is "what is missing?" Are there any security or privacy risks that are left? Are there any issues of trust remaining? Here we will address these issues:

1. Use of SSL: SSL provides encryption during data transport and also provides some level of trust that the client is connecting to your actual web site and not someone else's. However, the "trust" part is only truly useful for educated clients. Many naive or new Internet users get in the bad habit of clicking "go away" on any and all warning messages and dialog boxes that their web browser may display. Such users will not necessarily be aware if they are being conned into going to a web site that looks like yours but which is not and which uses an untrusted SSL certificate. They may then enter their sensitive data there, making it available to unintended parties. These are so-called "phishing" attacks, where hackers are "fishing" for sensitive data by sending forged email from respectable companies that tries to get unsuspecting recipients to log into fraudulent web sites setup to look like the real ones to give them anything from content information, to account data, to credit card numbers, etc.

   There is no simple way to assist uneducated users who do not pay attention to browser warnings and dialog boxes. There are many things that can be done -- such as using one-time passwords and security tokens for access -- but these complicate access. For most small web sites, "phishing" attacks are not likely to be an important issue as hackers usually spend their efforts going after "big fish," where they have a better chance of significant return on their effort.

2. Trust of the Web Server: There is an implicit level of trust you place in your web server and web hosting company. Your sensitive data is unencrypted and insecure at one point in time -- inside your web site script(s). If someone were to break into your web server and have access to your web site scripts, then they could modify them to capture the sensitive data after it arrives via SSL and before it is encrypted. This would grant them full access to all new sensitive data (though previously captured data would still be safe). The interloper could be a hacker breaking in through vulnerabilities in the web server or web host's infrastructure, or it could be an agent in the web hosting company who already has high-level access to the server.
3. The Email Scenario:. In the scenario where the encrypted data is emailed to you, you must be sure that the password to your private key is known only to authorized people and that only such people have access to the key itself. If someone else gets a copy of a secure message and your private key, they can try to break into the sensitive data via "brute force" by trying all kinds of different passwords until one works -- if you pick an easily guessed password, this will not be a hard thing to do.
4. Database Scenario: In the scenario where the encrypted data is stored in on the web server along with the private key, there is a further level of trust involved. Anyone with access to the private key and the stored data can try to break into the sensitive data by "brute force", as described in (3). Furthermore, anyone with access to your web scripts could modify them to save a copy of the password to the private key when it is passed to your secure web site. They can then login later and get that saved password and unlock all of the encrypted data. So, in this scenario, you are really trusting that no one can have unauthorized access to your web site and data.
5. Fake data: In the various scenarios we have discussed, the sensitive data is encrypted and saved or emailed. When you decrypt and read this sensitive data, there is no way to be 100% sure that it was created by your web site forms. It might have been created and encrypted by anyone else with access to your public key and web server and then stored or emailed in the same way (this takes some doing but is possible).

Use of SSL with PGP or S/MIME can protect your sensitive data to a very high level -- high enough to meet all HIPAA regulations and for you and your clients to feel confident sharing even sensitive financial information. Used together, these technologies ensure:

• Your data is protected during transmission over the Internet.
• Your data is protected during storage.
• Only the intended recipient of the data can ever access it.
• The data cannot be modified without being corrupted.
• The sender can be sure that s/he is sending to the intended recipient.

In the end, there is always an issue of trust -- you must place a strong degree of trust in your web hosting provider. You should choose one that:

• Is generally regarded as trustworthy.
• Has very strong privacy and non-disclosure policies.
• Really understands security and encryption.
• Will answer your security-related questions and help you implement your solution.

One such company, LuxSci, is ready to help you implement SSL with PGP or S/MIME solutions. LuxSci provides SSL-secured web sites, is partnered with Thawte.com to help you obtain very good and well trusted SSL certificates, and has ready-made scripts for capturing secure form data, encrypting it, and emailing it to you. LuxSci has a great deal of experience in S/MIME and PGP-based data protection and web security.