......You are awakened by the phone in the wee hours of the morning. Your assistant summons you to the office saying only that there's been a terrible accident. You rush to the high security glass and steel structure, showing your Picture ID to the guard at the front desk to gain access to the building. Reaching the main entrance to your offices, you notice that the alarms have been turned off. Others are already there. You slide your card through the reader to gain access to the computer room. Your heart begins to pound as you see the stunned looks on the faces of your colleagues. They're gone. Your algorithms....your as-yet unpatented, proprietary programs which were to be the core technology for your entire new product line....gone, along with the $20 million worth of research that led up to them. They were conservatively estimated to be worth $225 million. Gone. The thieves erased everything, but left you a cute little note thanking you for your contribution. You can restore the information from back-ups, but it doesn't change the fact that it's all gone. You feel sick, thinking about what you're going to say to the Board of Directors when you tell them that you've allowed the entire future of your company to slip through your fingers. Later analysis of the access logs will show that the thieves made good use of the extra time afforded them by the weekend to hack their way past the firewalls of your secure network.....through your company Web page......

Pretty scary, huh? Unfortunately, every word of it is true (well, maybe I did embellish it just a little.). While there are those of us who question the wisdom (sanity?) of entrusting the future of the entire civilized world to the vagaries of invisible electromagnetic pulses, the fact is that almost all of our most important, most sensitive collective and individual secrets are stored somewhere in magnetic form. We entrust our very lives to these ephemeral companions almost everyday. Lights light, planes land, telephones ring, stock tickers tick, bank balances balance; all because of the computer's astonishing ability to extract order from chaos. Fortunately for you and your business, the world is filled with kind, trusting souls who would happily exchange their credit card numbers for whatever you are offering on your Web site. Sadly, there are also those among us who would see our cities go dark, our stock markets crash, and your bank balance transferred to a place more to their liking..... just because they can. Like Shiva, they are the destroyers, and you need to protect yourself, your company, and your customers from them. In short....

.....We need to talk.

     In this section we are going to discuss the need for security and the extraordinary lengths to which some software developers and site administrators are willing go to ensure it. We are also going to show you why you need to pay attention to security, even if whatever information you are offering or collecting on your Web site is not sensitive in the slightest.

Let's Play Post Office
When we mail a letter, most of us trust that it will eventually get to it's destination. But few of us stop to think about how little control we actually have over how it gets there. While we may know the location of the drop-box, we have no way of knowing which truck will pick it up, which machines will sort it, or who will handle it along the way. Transmitting information across the Internet involves a similar process. If you live in Los Angeles and are sending E-mail to a friend in Phoenix, your letter will probably not go straight to your friend. Depending on the traffic on the net, your letter may settle on a server in Seattle for a while, or just languish in Los Angeles, patiently awaiting it's turn in the transmission que. The interaction of the various routing computers along the way will determine the actual path that your letter takes. If you don't believe me, take a look at the routing headers on your next piece of E-mail. The headers will provide you with a short history of where your letter has been.

     Unlike regular mail, which is at least sealed in an envelope and protected by law, most E- mail is still transmitted as plain old ASCII text. This essentially means that anyone who is willing to go through the trouble of intercepting it is free to read, or even change, the contents of your letter. This is somewhat analogous to conducting all of your paper correspondence via post card. While this is perfectly appropriate for some communications, most of us will at some point be feeling the need for a little more privacy. This desire to hide our medical information, credit card numbers, and other sensitive secrets from the prying eyes of casual observers leads us directly to another subject which has become the driving force behind almost all digitally mediated commerce, namely.....

Cryptography
Cryptography has been with us for eons. Battles have been won and lost, governments built and toppled, kings made and deposed, all because of our ability or inability to transmit secrets using "unbreakable" codes. Unfortunately, the same technology which has brought us cheap and powerful computers has left our traditional methods of keeping secrets increasingly vulnerable to attack. Ciphers which stymied our finest minds during the cold war may seem almost childishly simple to modern cryptographers working in the computer age. Clearly, more powerful methods were needed, and we found them. As a matter of fact, some of the encryption schemes commonly in use on the Internet today are so powerful that the Government is now attempting to ban their use.

     Cryptography is based on the use of a "key"; a formula for encoding and decoding information. Traditionally, if you wanted to send me a coded message, you would encrypt the message using the key. The encrypted message would be transmitted to me by courier or by wire. I would then use the same previously-agreed-upon key to decode the message. If the message fell into the wrong hands somewhere in-between, we could only hope that our enemies weren't smart enough to break the code, or at the very least, it would take them so long that it wouldn't matter.

     With the advent of powerful high-speed computers came the ability to mount systematic mathematical "attacks" on our heretofore unbreakable codes. Sophisticated code breaking formulas which would have required eons of calculation time a decade ago can now completely run their course in a matter of minutes. If all else fails, "brute force" attacks can be devised, in which the computer literally tries every possible mathematical combination of keys until it finds one that fits.

     This escalating insanity has led to the invention of encryption codes which are constructed by the computer, a necessary step if they are to reach the level of complexity required to thwart a computer attack.

     Even though modern cryptography is incredibly strong, until fairly recently it still lacked the one element which would make it available to the masses, namely, it required that we both have the same key in order to code and then decode the messages we were passing across the network. If I had the resources of, say, a large corporation or a government, it wasn't a problem. I could simply devise the appropriate encryption scheme, then send the keys to you on our private jet via a trusted courier, perhaps a vice president, or a soldier with a briefcase chained to his wrist. If, however, I was just a kid from Yonkers who wanted to buy the latest Puddle of Mudd album from the Internet Record Club, I was faced with somewhat of a dilemma....I couldn't just blithely sail my credit card numbers across an unsecured network in the hope that no one would steal them. What I really needed was a secure channel so that I could send my encryption keys to the record club. Hell, if I had the luxury of a secure channel, I wouldn't need encryption! Hmmmm....

     The problem was finally solved through the development of an encryption scheme which now forms the technological core for many of the new browsers, and provides users with the means to conduct secure transactions over the internet. This breakthrough is known as.......

Public Key Cryptography
While Public Key Cryptography was originally the brainchild of a cryptographer in the employ of Her Magesty's Secret Service and was a closely-held state secret for many years, the concept was re-discovered and introduced to the public in 1976 by Dr, Whitfield Diffie and Martin Hellman in order to eliminate the need for the sender and receiver to share secret key information. The step which allows Public Key Cryptography to work so well over the net involves the act of splitting the key used to encode and decode data into a set of two complimentary keys. Using carefully constructed random numbers called SEEDS, the computer generates two huge prime numbers which in turn are used to construct the key set containing a "public key" and a "private key". Like a safe deposit box, which also requires two keys, both cryptographic keys are required to complete the encode/decode cycle. Because of the properties inherent in a mathematical construct called a one-way function, it is almost impossible to calculate the secret of the private key, even though you may have the public key. This is because while it is relatively easy for the computer to multiply two huge prime numbers together to obtain their product (a necessary step in the process), it is computationally difficult to find the prime factors of any given composite number. Like scrambling an egg, it's kind of a one-way process. Although it's easy to break the egg and mix the yolk and the white together with a whisk, you would have a pretty tough time if I asked you to put the egg back together the way you found it. This quirk in the math makes it possible to maintain security even though one of the keys may be kept in a public place.

     Because the keys are created as a set, they are complimentary, and it can be said that in practice, one key decodes what the other key makes. There is a difference in the two keys, however, because while both keys contain information about the one-way function used in the keyset, the Private Key also contains a Trap Door, which is essentially the solution to the puzzle. This means that the keys are, in effect, Directional. Whoever has the Private key containing the Trap Door can easily perform the function in both directions. Without the Trap Door, the function can only be performed in the Forward Direction. The Forward direction is used for encrypting messages and verifying signatures, and the Inverse Direction is used for decrypting messages and generating signatures.

     When you encode a message, your cryptography program provides the computer with instructions for performing a series of nonlinear transformations on your data, thereby transforming your cogent, exquisitely crafted prose into totally unintelligible gibberish in a matter of moments. (As a matter of fact, almost everything I've written up until now was cogent, exquisitely crafted prose just moments ago......No,...really!). Anyway, when it's time to decode the text, the second key is used to reverse the process and complete the cycle from text, to gibberish, back to text.

     That being said, let's use public key cryptography to receive a letter over the Internet......

     First, I'm going to use my public key cryptography program to create a set of keys. One key, my "Private" key, will live only on my computer, completely hidden from the rest of the world. The other key, my "Public" key, can be freely distributed to all my friends via E-mail, or even loaded onto a special server designed to be a kind of big internet key ring.

     Now I'm going to call my friend Olivia and ask her to send me a private letter over the internet. First she'll need to write a letter. Then she'll need to download my public key from the Internet key ring. Using her copy of the public key cryptography program, she'll encode her letter using my public key and send it to me via E-mail. Because I am the only person in possession of the second, complimentary key, I am the only person who will be able to unscramble her letter, even though my public key is on the internet for all to see.

     Likewise, if I wanted to send a private letter to her, I would have to download her public key from the internet key ring, encode the letter using her public key, and send it via E-mail. Because the encryption keys used in this scheme are complimentary, I could even verify myself as the author and guarantee the integrity of the message with the addition of one extra step. First, I would write the letter. Next, using my cryptography program, I would create an unforgeable digital signature. (The program uses a routine called a Secure Hash Function to generate a message digest based on the actual contents of the letter. The digest forms a kind of digital fingerprint, which is then encrypted using my private key.) When I was ready to send the letter, I would encrypt the whole thing, previously encrypted signature and all, using her public key. When she received the letter, she would essentially reverse the process, first using her private key to unscramble the letter, and finally, using my public key to unscramble the digital signature. If the contents of the message had been altered in any way, the signature would be ruined, and she would know that the message had been tampered with.

     As you can see, we are close to assembling all of the elements we need for a secure transaction. There are, however, a few more issues that we need to address...

Authentication
When I see my friend Olivia or talk to her on the phone, I can easily recognize her because I have known her for a long time. Over the years we have developed a relationship of trust, and so I would think nothing of giving her my credit cards or my car keys. I know from years of experience that she is who she claims to be, and that I can count on her to be responsible, trustworthy and reliable. Some of my other friends, who trust me but don't know her as well, might be reluctant to entrust her with their possessions. If she needed my friend Tommy's car, for instance, he might not be willing to give it to her unless I was willing to vouch for her.

     We run into a similar situation on the World Wide Web. You may be logged on to a site which claims to be the Internet Record Club. You know that the Internet Record Club really exists, and you know that you can trust them because your friends have had good things to say about them, but is this really the Internet Record Club, or is it a server pretending to be the Internet Record Club in order to capture your credit card numbers? Is the sight really secure, or is it possible that someone could intercept your credit card information on the way to the server? Clearly, there is a need for a way to Verify the identity of the server that you are connected to. To accomplish this, software designers have invented another digital entity, known as .....

The Digital Certificate
The purpose of the digital certificate is to provide your customers with a certain degree of assurance that you are who you say you are. Digital Certificates are issued by a Certification Authority. In order to get a certificate, the Certification Authority requires that you complete an application, providing them with detailed information about yourself and your business, which is then verified. If everything checks out, they issue a certificate to you which is valid for a fixed period of time, and is digitally encrypted using public key cryptography to prevent anyone from tampering with it. The certificate is then used by your customer's browser as part of the procedure of establishing a secure connection between you and your customer.

     Please note that while a valid Digital Certificate is necessary in order to establish a secure channel in an SSL compliant transaction, it does not in any way vouch for your character. The possession of a certificate doesn't necessarily mean that you have good products, or low prices, or even that you're an honest person. It simply means that a particular server is registered to a particular business with a valid business license.

     Because Digital Certificates are based on Public Key Cryptography and used as an integral part of a secure transaction, the certificates offer a number of advantages if the scheme is properly implemented. The signed digital certificate contains two groups of information. First is the certificate information itself, which includes the name of the server, its public key, the certificate's validity dates, and the name of the CA. The second piece of information on the certificate is the certificate's unforgable digital signature. The entire message is then digitally signed by the Certification Authority who is known to many servers and who can verify the relationship between a server and its public key. In addition, the CA usually requires that you provide them with an unambiguous name and E-mail address before they will issue a Class 1 Certificate to you. All of his information helps to identify you with your server and makes it tougher for others to impersonate you.

     Even with all of these security precautions, there are times when the system breaks down, usually because someone simply wasn't paying attention. The folks at Digicrime have recently managed to securea digital certificate made out to root@localhost which they have thoughtfully placed on the Web for your viewing pleasure. In this case the CA has obviously broken their own rule about names and E-mail addresses, since root@localhost is a totally generic term, kind of like addressing your paper mail to mailman@postoffice. While no great damage was done in this case, it does point out the fact that the value of the certificate can be easily compromised if the standards are not upheld. If the significance of this escapes you at first, let me just say this...it's as if I had applied for a credit card for my dog, and shortly thereafter received a Platinum Master Card issued in her name. Since my dog has no computer and no pen, it's unlikely that she could have run up much of a bill. A real person with a valid digital certificate made out to a fictitious character, however, could wreak havoc on your credit card balances and subsequently disappear before you even knew anything had happened.

     In defense of the CA, they did revoke the certificate as soon as they figured out what had happened. There are times when you would want to have the option of revoking a certificate. If, for instance, you knew that security had been breached, you would want to make sure that the certificate could not be used. This, however, brings up an interesting question of ownership, because a certificate is basically an idea encoded in magnetic pulses on a distant server, and not an actual physical thing. If you were, for instance, a CA who had discovered that the person you had issued a certificate to was a crook, how would you get it back? While most CAs do provide lists of revoked certificates, as of right now the Online Certificate Status Protocol, a mechanism for checking the status of unexpired certificates, is not widely implemented, so as far as my browser is concerned, that certificate will remain valid until it expires unless the business owner voluntarily removes it from the server. The fact that this particular certificate was issued to Digicrime at all raises a number of larger questions, among them....

Who owns the rights to a Digital Certificate?

Should browsers by default be required to check the validity of unexpired certificates?

If the CA fails to show due diligence in investigating an applicant before issuing a certificate, should they be held liable in the event that the certificate holder turns out to be a crook?

What constitutes due diligence?

    The reason that the answers to these questions are important has to do with trust. People just won't use the technology unless they have confidence in the system's ability to protect them from fraud. And if your business depends on your ability to get people to trust you with sensitive information, you're going to be in big trouble if they don't trust the system, even if they do trust you.

     That said, let's move on to the culmination of all this research. While there are a number of excellent protocols which have been developed to facilitate secure transactions over the Net, such as S/WAN, S-HTTP, and PCT, (which is a versatile and very secure method developed jointly by Microsoft and Visa), for now we're only going to say a few words about what is arguably one of the most popular protocols for conducting secure transactions over the Web........

The Secure Sockets Layer
The Secure Sockets Layer is a protocol which was developed by Netscape, then placed in the Public Domain for the benefit of the internet community at large. A number of other companies, such as Microsoft, have subsequently built SSL compliance into their secure server software. Using all of the technologies that we've talked about so far, your SSL compliant browser and a secure server perform an elaborate dance, automatically opening a channel, generating and exchanging cryptography keys, authenticating the server, and generally preparing both the browser and server for the exchange of encrypted information. The protocol also provides methods for ensuring that no one tampers with your data during transmission. Other than a short pause by the browser and a change in the status bars, the process is almost completely invisible to the user.

     SSL operates at the transport layer and mimics the Socket Library, forming a transparent security barrier between the upper application protocols (such as HTTP, FTP, and TELNET) and the lower networking protocols (such as TCP/IP). This Applications Independence means that most programs which normally work over the internet will run just fine in secure mode without any code alterations.

     Now that we've spent all this time telling you about how secure Web transactions came about, we thought we'd give you a little peek at how the process works. In a nutshell, here's what happens when you log onto an SSL server with an SSL-compliant browser. (Pay attention, this gets crazy)....

Your browser sends a request to connect to the server....

The server responds by returning it's Digital Certificate (digitally signed by the CA) and it's cipher preferences.....

Your browser verifies the certificate, then generates a master key for the session, which it encrypts with the server's public key, which is on the certificate. It then sends the encrypted master key for the session back to the server......

The server recovers your encrypted master session key using it's own private key. It then authenticates itself to your browser by sending back a message which has been encrypted with your agreed-upon master session key......

Subsequent data is encrypted from keys made from the master session key......

The Server has the option of challenging the authenticity of your browser. (I'll show you mine if you'll show me yours.) Your browser will respond by sending it's digital signature, along with it's public key certificate.

 Whew!...and you thought that explaining your job to your Mom was complicated.....

Even though we've shown that it's possible to protect your customers by maintaining a secure connection between your server and their browsers, your security worries are far from over. As a matter of fact, they've just begun, because you are now the proud owner of a secure server filled with sensitive information. If a thief manages to eavesdrop on a purchase transaction with one of your customers, it's possible that he could get a credit card number. Very Bad. What if the thief managed to hack his way on to your server? Now he's hit the Motherload. Now he has 10,000 credit card numbers. Very, Very Bad. Guess who's gonna get sued?

     Before that happens, let's take a look at the next thing that you're going to have to worry about.....

Site Security

Here are a few tips that will help you to maintain the integrity of your secure server.......

Secure Your Private Keys

Make sure that your private key file is protected. An attack on the key file constitutes the fundamental security risk for the server. Store the key file in a directory that only the root user or the server's user account can access.

Protect Your Passwords

Keep your passwords confidential, and never write them down. Choose passwords that are a mix of letters, numbers, and valid punctuation marks. Make sure that any files which are stored on backup tapes or are otherwise available for someone to intercept are stored in a secure manner.

 Limit Physical Access to the Server

While this is probably the simplest security measure, it is one which is often forgotten. The server machine should be kept in a locked room that only authorized people can enter. This prevents anyone from hacking onto the server machine itself.

 Limit Applications

You should carefully consider all applications that run on the server machine. Disable all unnecessary system daemons and services. For example, the sendmail daemon is difficult to configure securely and it can be programmed to run other possibly detrimental programs on the server machine. Carefully choose the processes started from initab and rc scripts. Don't run telnet or rlogin from the server machine. You also shouldn't have rdist on the server machine (this can distribute files but it can also be used to update files on the server machine).

 Limit Ports

You should disable any ports not used on the machine. Use routers or firewall configurations to prevent incoming connections to anything other than the absolute minimum set of ports. The secure server runs on port 443, so connections to any other port should fail. This means that the only way to get a shell on the machine is to physically use the server's machine, which should be in a restricted area already.

Limit Methods of Administration

 You should never administrate the server from a remote location, especially if the network itself is not secure. Anyone could intercept your administration password and reconfigure the server. Unlike a Commerce Server, Administration Servers often don't have SSL security. You should also restrict access to the server administration forms by allowing only local hosts.

 Change Your Passwords Often

 Don't keep passwords for long periods and always use proper passwords. Your password should be long and include upper and lowercase characters, numbers, and special characters. You should never use words known in any language. A good password is one you'll remember but others won't guess. For example, MBi12!mo could be remembered as "My Baby is twelve months old!" A bad password would be your child's name or birth date. It is also very important to use different passwords for different applications. Your root password should be different from your server administration password and your keyfile password.

Know Your Limitations

 While a secure sever offers secure connections between the server and the client, it can't control the security of information once you have it, nor can it control access to the machine itself and its directories and files. Being aware of these limitations helps you know what situations to avoid. For example, you might acquire credit card numbers over a secure connection, but are those numbers stored in a secure file on the server machine? What happens to those numbers after the secure connection is terminated? You should be responsible for securing any information clients send to you through a secure connection.

Patch, patch, patch.

Keeping your security patches up to date is one of the most important tasks of anyone administering a secure server. While it can be an odd combination of boring and frustrating, it is absolutely necessary if your machines are exposed to the Internet. Coordinated attacks by professional criminals have become big business, and new vulnerabilities are discovered everyday.

In addition to the security risks mentioned above, there are literally hundreds of ways for thieves to hack into your system. Certain programs or combinations of programs running on the Common Gateway Interface can also constitute a security risk if the hacker knows how to exploit them. Anticipating all of the possible paths of attack requires a level of understanding which approaches black art.

As you can see, designing a secure system is not a job for amateurs or the faint of heart. Hardware, software, the physical structure of the environment, and all of your administrative procedures must be thoroughly and intelligently evaluated in order to construct a credible threat model and plan defenses against possible attacks. You have a responsibility to protect any sensitive information that your customers may give you. This is not something that you should attempt yourself unless you have the expertise.

Now that we've discussed each of the major components that you'll need to build your site, let's talk about putting all the parts together. If you haven't already been to the recommendations section, you may want to take a look now. We're going share some of the guidelines and general advice that we like to give our clients to help them get started. We hope you'll join us.