Tuesday, January 16, 2007

User-Authentication Security

Authentication security governs the barrier that must be passed before the user can access particular information. The user must have some valid form of identification before access is granted. Logins are accomplished in two standard ways: using an HTML form or using an HTTP security request.

If a pass-through is provided to normal database access, traditional security controls can be brought into play. Figure 1 shows an example of a standard security login through the Netscsape Communications Corp.'s Netscape Navigator browser.

The HTML login is simply an HTML page that contains the username and password form fields. The actual IDs and passwords are stored in a table on the server. This information is brought to the server through a CGI script or some piece of database middleware for lookup in a user identification database. This method has the advantage of letting the DBA define a particular user's privilege. By using a table created by the DBA, numerous security privileges specific to a particular project can be defined.

Once a login has occurred, a piece of data called a "cookie" can be written onto the client machine to track the user session. A cookie is data (similar to a key and a value in an .ini file) sent from the Web server and stored by a client's browser. The Web server can then send a message to the browser, and the data is returned to the server. Because an HTTP connection is not persistent, a user ID could be written as a cookie so that the user might be identified during the duration of the session.

HTML form login security, however, must be implemented by hand. Often this means reinventing the wheel. Not only must a database table or other file be kept to track users and passwords, but authentication routines must be performed, whether through CGI script or via another method. Additionally, unless using a secured connection (see the section on SSL later in this article), both the username and password are broadcast across the network, where they might be intercepted.

HTML form login is excellent when security of the data is not paramount yet specialized access controls are required. Browser login is most useful when it is integrated with existing database security through some type of middleware. Even with users properly authenticated, additional security concerns arise.


Session Security
After the user has supplied proper identification and access is granted to data, session security ensures that private data is not intercepted or interfered with during the session. The basic protocols of the network do not set up a point-to-point connection, as a telephone system does. Instead, information is broadcast across a network for reception by a particular machine.

TCP/IP is the basic protocol for transmission on the Internet. The protocol was never designed for security, and as such it is very insecure. Because data sent from one machine to another is actually broadcast across the entire network, a program called a "packet sniffer" can be used to intercept information packets bound for a particular user. Therefore, even though a user has properly logged onto a system, any information that is accessed can be intercepted and captured by another user on the network. There is no easy way to prevent this interception except by encrypting all of the information that flows both ways.


Public and Private Key Security
The world of encryption is often a fairly arcane field of study. The growth -- as well as the insecurity -- of the Internet has forced users unfamiliar with even the basic concepts of cryptography to become at least acquainted with its common implementations.

Two basic types of encryption are used in Web security: secret-key security (using a single key) and public-key security (using two keys).

Secret-key security (which is also known as symmetrical-key security) is somewhat familiar to most people. A Little Orphan Annie decoder ring is a common example. The secret key, in this case the decoder ring, is used by each party to encrypt and decrypt messages. Both parties must have access to the same private key for them to exchange messages. If the key is lost or exposed, the system is compromised. Public-key security is a little more complicated. With public-key security, each individual holds two keys, one public and one private. The public key is freely published, and the private key is kept private. Once a message is encrypted with one key, it cannot be decoded without the other key. ( See Figure 2 .)

Using this type of encryption, someone can take a data file and encode it with your public key. Only your private key can be used to decode it. Likewise, if you encode a data file with your private key, it can only be decoded with your public key. Therefore, the receiver of the data file knows that it came from you because only your private key can generate a file that can be decoded by the public key. This is so reliable, in fact, that it is admissible in a court of law. Only you, or someone with access to your private key, could possibly have created data that can be decoded with your public key.

The primary difference between implementing these two systems is computational. Using a secret-key system, encryption and decryption can take place between 100 and 10,000 times faster than the equivalent data using a public-key system. The private-key systems often use a smaller key, perhaps even a user password. The public-key systems use computers to generate the keys, each of which is usually 512 or 1024 bits long. That's about 50 to 100 characters long -- not easy to remember off the top of your head. Most Internet systems use a combination of the two to provide secure communication. Typically they use the public-key encryption system to encrypt a secret key (usually machine-generated based on a time code).

Both the server and the client encrypt a secret key with their private keys and send the encrypted data and their public keys to each other. Alternatively, the public keys might be retrieved from a trusted third party such as a Certificate Server (which I describe later in this article).

The public keys are now used to decode the data, so both the client and the server now have secret keys. When exchanging information, the data is encrypted with the secret key and sent between the machines. This system combines the authentication and extra security of a public-key system with the speed and convenience of a secret-key system.


Secure Sockets Layer (SSL) and S-HTTP
Public/secret-key systems such as the one I just described are widely implemented on the Internet. Most large Internet product developers (such as Netscape, Microsoft Corp., and IBM Corp.) agreed to use an encryption protocol known as the Secure Sockets Layer (SSL). SSL encrypts all data transmitted between a client and a server during a session.

SSL uses Secure HTTP (S-HTTP) as its basic transmission protocol. This protocol is a variation of HTTP that provides the secure foundation for SSL transmission. S-HTTP performs what is known as a handshake when establishing a connection to exchange keys and creates an encrypted connection. Addresses to an SSL secure page use the prefix "https" instead of the common "http." Therefore, a secure page address would read https://www.dbmsmag.com.

The public-key system requires that each party has a public and a private key. These keys must be generated by a trusted source. For Internet broadcast, a few companies offer this service, the largest of which is VeriSign Inc. (Mountain View, Calif., www.verisign.com ). Generating a key costs about $300 per server for the first year and around $100 for each year after that. You must wait between two and three weeks to receive a key.

Intranets, however, have just as much reason to protect their data. In fact, the National Computer Security Association (NCSA) estimates that perhaps as much as 80 percent of an organization's security breaches occur within that organization. For private database information, all the authentication in the world won't prevent packet sniffers from intercepting data that is sent across the network. For this reason, organizations have begun to set up their own public-key servers.


Certificate Servers
Many organizations want a way to generate and track keys on a public-key system. A great deal of recent press has focused on digital signatures, digital certificates, or digital IDs. A digital signature is merely the public key of a public-key system. There is a standard called X.509 for the format of the digital certificates. For example, a user can use his private key to encrypt the text of the book War and Peace . The user can then send the encrypted book as well as his or her public key to another user. The public key or digital signature contains the ID of the trusted party that generated the key (such as Verisign and AT&T). The receiver of the document verifies that the key used to generate it was created by a trusted party and then decodes the information. Only that user's private key could have encoded the document.

A Certificate Server enables a company to become its own trusted key generator. Rather than having Verisign generate the public/private key pair, a Certificate Server within the company creates the keys and stamps its creator name on each key.

The public keys themselves are also kept on file on the server. A user can request the public key of John Smith to decode a document supposedly sent by John Smith. If the document wasn't encrypted with Smith's private key, the public key on the Certificate Server will not decode it properly.