We’ve been conditioned to worry about the security of our personal information while surfing the web. Perhaps the most important and effective security practice is to be prudent and sparing when sharing important information.
As web site users and web site owners/developers there are some steps we can take to help safeguard information. Today’s post focuses on the secure, encrypted communication offered by some web sites.
Some Background from the Web User’s Perspective
When we go to a typical web site, like ashmug.com, we are sending a simple message out through the Internet asking to display the ASHMUG web site. The ASHMUG web server sends us back the pictures and text and instructions that construct the page. If there is a simple form on one of the pages, like the form on the Contact Us page, any information we type into that form gets sent back to the server in the same way.
By default this exchange of information is in the open. If someone could “listen in” to the flow of information they could read and understand what is being said, including the information we type into the form. In many cases this is no big deal, since the information is generally known by the public anyhow.
If the information requested in the form is sensitive – such as a credit card number – the web site can safeguard it by encrypting, or coding the information before sending it out over the “wires”.
Safari Icon – EncryptedThere are a couple ways to spot if this extra protection is present on a web page you are visiting. If you use Safari as your browser there is a little gray padlock in the upper right corner of your browser window. In some browsers you can also spot that the web page URL/address starts with https: . This indicates a secure page, while http: indicates an open or unsecure page.
Encryption Information in FirefoxIf you use a recent version of Firefox , up in the address bar, just to the left of the page address is a box that displays the name of the site owner. Clicking on that shows more information about the encryption.
Let’s look at this information a bit more. There is a note that the site ownership is verified by GoDaddy.com. That means that GoDaddy has taken extra steps to verify the site’s identity, and has given the Intrade.com site a digital certificate supporting the verification.
If you see information like these two examples, then you can be pretty confident that the information on the form will go out on to the Internet in a safeguarded form – encrypted. That reduces, significantly, the chance that an eavesdropper can intercept and see your sensitive information.
This kind of protection is particularly important if you are viewing/using a web site through a public wireless hotspot, like at a coffee shop, the library, or on campus. Your communication in these public places is easier to catch and intercept. If you are home, connected to the Internet by a cable, or sitting behind a password protected wireless hotspot, the actual odds of someone intercepting your information are pretty slim. Still, it is good practice to expect a web site to secure the communication of important, sensitive information. And virtually all good web sites take this precaution. You’ll routinely see it used when shopping online, or banking, or a variety of other functions.
How Does it Work?
As a user you might be mildly interested in this. As an owner or developer of a site, this information is more important.
To offer a secure page and communication the web site needs to register with a security certificate company. There are many, including Network Solutions, GeoTrust, GoDaddy, and more. These companies ask to verify who actually owns/operates the site, and who the key contact is. They then issue a security certificate and a public key. The certificate helps display the kind of information on Intrade we saw above. This certificate is made available to browsers who visit the secure page. The public key is a very long, seemingly random assortment of numbers and letters. This key can be 100s of characters long.
The web site sends this public key to the browser. The browser uses the public key to convert the plain-language information into coded gibberish. If a bad person intercepts a communication that is encrypted, they can find out the public key, but that is not enough information to decrypt, or translate the gibberish into useful information. When the encrypted information comes back to the web server, the server matches the public key to a private key stored on the server. Once the match is made, that private key can unlock the information and make it readable. No one can see that private key, and it is kept in a safe place on the web server.
If you are developing a web site and you want to safeguard the transmission of information, the first thing to do is consult with your web hosting service. They will probably have established procedures to help you get a security certificate, and to install it in your site. It will cost you an extra annual fee to renew the security certificate, and sometimes a one-time set up fee. The process for doing this on your own is pretty complicated, so make use of any service your hosting company offers.
Coding Notes for Your Web Site
Once you have the security things set up with your host, you need to tell the browser when to switch to secure mode. Let’s use the example of a contact form page, and imagine that you want the information on that form to be encrypted when it is submitted. So, we are on the home page of mydomain.com and you have a menu that includes the contact form page. Ordinarily you would link to contact.html, with some HTML like this:
<a href="contact.html">Contact Us</a>
We now need to change this to indicate a secure page. The new code might look like this:
<a href="https://mydomain.com/contact.html">Contact Us</a>
See the https: in the code? For a regular link we don’t have to worry about http: or even the domain name – those are just assumed when linking within a web site. In this case though we are more specific and saving we want the Contact Us page to be displayed and used in secure mode.
So, now the user is taken to contact.html and the page is displayed in secure mode. Good.
The next step is to make sure the form on that page goes to a similarly safeguarded page. Maybe the form tag sends the information to getform.html. That page might have some programming that takes the form information, and does something with it – save it or create an email with it. To be safe your form tag should look like this:
<form action="https://mydomain.com/getform.html" method="post">
...form fields go here...
</form>
One last step… Go to the HTML coding for that original form page and see if any of the images in particular are specified like this:
<img src=”http://mydomain.com/images/image1.jpg” />
This kind of coding should be changed to use secure functions, or else the browser will warn the user that some parts of the page are not secure. In truth this isn’t a security hole, but it will worry your user. So use either of these coding styles for your images.
<img src="images/image1.jpg" /> Your browser will assume the image should be retrieved securely.
<img src="https://mydomain.com/images/image1.jpg" /> This leaves no doubt
Very often we work with page templates where the heading and navigation menus are standard on all pages. That can mean that some images, like a logo, are displayed with the same code, page after page. Generally this isn’t a problem when these templates use the shorter version above, <img src=”images/image1.jpg” />. If this appears on a secure page the browser assumes the image should be retrieved securely, and otherwise not.
Why Bother?
This is actually a fair question. If you are contemplating a web site that will deal with sensitive, personal information it is a good idea to step back and ask yourself if you want to make the effort to secure the site, and also secure any information that you collect and store. Also, if you collect and store sensitive information you assume a legal risk or liability if that information is compromised. This is the beauty of services like Google Checkout (soon to be renamed Google Wallet) and PayPal, or the Yahoo Store. If you set up accounts with one of these services and can then send your site visitors to their secure pages, you can be more comfortable with your user’s security. These services spend tons of money perfecting their security set up. I know a guy who works for PayPal in the security area and he and his colleagues spend practically full time trying to anticipate hackers, and building mechanisms to foil them. Most of us don’t have the resources to match that. Working with a large, legitimate online shopping service is often the best route.
