Who can you trust on the Web? These days, with identity theft seemingly rampant, it's more important than ever to take all possible measures to protect your privacy and to shield personal information from those who might not have good intentions. In addition to protecting ourselves, librarians also have to take reasonable precautions to ensure that the online services that we offer do not jeopardize our patrons' privacy.
I'm sure that I'm not the only one receiving spam intent on tricking me into revealing some item of personal information. The spammers sending these messages are phishing-casting a line in an attempt to snag an unsuspecting victim and draw them into a net of deceit. For the last few weeks, the most common phishing scam showing up in my in box has been a series of e-mails that appear to come from my bank. These alert me to potential trouble with my account and request that, for my own "protection," I click on a link to verify the account's status. At first glance, the link appears to connect to my bank's URL. Of course, it's a scam. A closer look reveals that the link actually connects to a different site. Consider the following:
When displayed in an HTML-formatted e-mail, this code shows up as a link that looks like it connects you to http://www.your trustedbank.com. Clicking on it, however, will actually take you to http://www.youvebeen duped.com. Not very nice, but an extremely common ploy.
Phishing falls into a category of fairly obvious scams intent on stealing personal information. Other schemes are more difficult to detect. It's important to remember that the Internet is a wide-open, public medium. Therefore, we must assume that any unencrypted information might be intercepted and viewed by others.
Fortunately, a reliable mechanism is available to help us securely transmit sensitive info across the Web. Even though it's been around for many years, librarians have not generally needed to take advantage of it, since we primarily deal with information that is intended to be shared widely. (Steal my MARC records, please! ) But as libraries develop personalized services that allow users to conduct e-commerce transactions and to create profiles for themselves that involve personal data, we need to implement these technologies that have been commonplace in the online business world for years. Let's take a look at the framework for encryption and identity verification on the Web and see what it looks like in practice. It all revolves around digital certificates.
The Keys to Security
E-commerce transactions that require the exchange of money and/or sensitive information require a very high level of trust between the consumer and the company that is offering its services on the Web. In order for people to trust the company that they are dealing with, they must know that the information they exchange in a transaction will remain private, and they must be assured of the company's identity. PKI (or the Public Key Infrastructure), with its system of public and private encryption keys, provides the basic building blocks of e-commerce security.
In order to ensure that a transaction remains private, it must be encrypted. You wouldn't, after all, want someone to be able to view your credit card number as it travels across the Internet. PKI is a security scheme that is based on two linked encryption keys: a private one and a public one. The private key, associated with a specific identity, is carefully guarded and known only to its owner. The public key, on the other hand, can be distributed widely. A message encrypted or locked by the private key can only be unlocked by its matching public key. Therefore, if you have the public key and know that it is associated with a given identity, the fact that it can unlock a message proves that the message was encrypted with the matching private key. Thus, PKI provides two important services: It encrypts a transaction so that it can't be deciphered in transit, and it confirms the identity of the partners involved. A lot of complex encryption algorithms and technologies are involved behind the scenes, but the basic concepts are fairly simple.
How does PKI translate into practice? Let's review how it's implemented on the Web.
Installing the Locks
In order to safely offer e-commerce or other secure services, a Web server must be properly configured with a digital certificate that validates its identity. A digital certificate is a file, issued by a trusted third party, that guarantees the identity of its owner. Creating and installing one of these certificates is standard practice for e-commerce Web servers, but the practical steps involved will vary according to the server software that is being used. Installing a digital certificate for Microsoft's Internet Information Server is quite different from installing one for Apache.
First, the server administrator executes a command from the software that issues a Certificate Signing Request (CSR). The CSR is a digital file that contains information related to the identity of the server, including the common name that the server will be known by on the Internet, the organization, the unit within the organization, and its physical location.
This unsigned digital document is then submitted to a certificate authority (CA), which verifies the authenticity of the request and infuses the file with its digital signature. security on the Web depends on hierarchies of trust. The CA at the top of the hierarchy essentially vouches for the identity of any server bearing a digital certificate it has signed. VeriSign is one of the best-known and most trusted of the certificate authorities, although there are many others.
Once the CA has signed the digital file, it becomes a valid digital certificate that is transmitted back to the Web server administrator and installed. After installation, selected documents or a directory of documents can be transmitted using the secure Sockets Layer (SSL) protocol.
Web pages transmitted through SSL carry the digital certificate, which recipients can view in order to verify the authenticity of the server. When communicating with a server operating in SSL, a Web browser will present an icon, usually a closed padlock, indicating that the connection is secure. Clicking on the icon will display all the relevant information relating to the digital certificate.
For example, if I'm ready to make a purchase onAmazon.com, before I enter my credit card number, I should see the locked padlock at the bottom of my screen. When I click on it, I should see that VeriSign issued the certificate for a server called http://www.amazon.com. To the extent that I trust VeriSign, I can be assured that the server is genuine, and I can enter my credit card number with a high degree of confidence that it will be encrypted and sent to its intended destination.
It's also important that the Web browser does proper error checking and validation. If, for example, a page is delivered to the browser using SSL, and the server's base URL does not exactly match the one embedded in the digital certificate, a warning message must be sent to the user.
Don't Be Lured by the Bait
Going back to our original phishing example, we can now see how to avoid being scammed. For starters, once we click on the e-mail's link and are taken to the imposter site, we should notice that the URL shown by the browser isn't the bank's, even though the content on the page might look convincing. It's also possible that the URL shown in the browser might look genuine. By now, however, we know that we wouldn't enter our bank account numbers or other personal information on the purported site unless it was secured with SSL. Most often, the page linked to a phishing e-mail will not be secured, and that makes it suspicious. And, even if the phony site were secured with SSL, an inspection of the digital certificate would reveal its true identity.
Security Is Essential Now
Like any other organization that performs its business on the Web, libraries also need the security provided by PKI. While a library's basic Web site and online catalog functions don't need enhanced security, it's important to use SSL for the transactions that involve sensitive information, such as those that accept payment for fines and fees via the OPAC. It's also needed when patrons are required to enter personal details such as addresses, phone numbers, usernames, and/or passwords. I've observed that some of the online catalogs on the market today don't use SSL by default, even when processing these personalization features. Administrators of these systems may have to do extra work to ensure that these transactions function securely.
Current trends clearly indicate that security threats on the Web will continue to increase and to intensify. To deal with this reality, it's important that librarians make appropriate use of the available technologies in order to protect their patrons' personal information. PKI and digital certificates are just some of the basic components that you can employ to strengthen your site's security and to help you earn your patrons' trust.