6.3 Authorization

6.3 Authorization

Authentication is only part of the story. Authorization comes next; access control uses the HTTP FORBIDDEN status code (403). When a user attempts to access a URL that is restricted in this way, the server returns this status code to tell the user's browser that access is not allowed. Cached information in the browser is reissued with each request in a WWW-Authenticate header. The browser now issues a second request for the URL containing the information necessary to establish the user's credentials. The server checks the contents of the information, and, if it validates successfully, the request is passed on to the authorization phase of the transaction, where the server will decide whether the authenticated user has access (ACL) to the requested URL. On future requests to this URL, the browser remembers the user's authentication information and automatically provides it with each query. This way the user doesn't have to provide his user name and password each time he or she accesses a secure page.

Now we will confuse all of this with a concept known as "realms." A realm is a directive that is sent with the browser each time it tries to authenticate with a server. The realm directive is required for all authentication schemes that issue a challenge to a URL. The realm value is normally a string, and it is assigned by the web server. (See ftp://ftp.isi.edu/in-notes/rfc2617.txt for more information about realms.) If the authentication information becomes invalid, the server can again issue a 401-response status code, thus forcing the browser to request the user's credentials all over again. There are several methods to enhance this process that are server dependent and specific, including use of browser cookies.

6.3.1 Passwords

In a system that uses user names and passwords, you should make sure that your users use hard-to-guess passwords. Following are some general guidelines for passwords.

• The password must not contain a word, name, or number that has some significance, such as a telephone number, address, or Social Security number.

• Passwords should be six to eight characters in length. (This requirement can be different from one company to another.)

• The password should be a mixture of letters, numbers, and special characters (which could include *, ?, @, !).

• Do not share the password with anyone else.

• Do not use the default password that is given to you. Change it as soon as possible.

• Do not write down your password.

• Do not use "password" as a password.

• Try not to use any word from a dictionary. (We already discussed directory/dictionary attacks.)

• Do not use any names as your password, like Bubba, Mike, or Billy Joe Bob.

• Never tell anyone your password not even your system administrator or account manager. Make sure you have chosen a password that you can remember.

• Don't use the same password for all of your Internet accounts.

• Try to change your password on a regular basis.

• If someone calls you on the phone and says, "Yes, and we are with the Network Password Police, and we need to know your password," don't give it to them! But if you do give your password out over the phone, take the following steps:

  1. Create an e-mail message.

  2. Put your credit card number in the subject line.

  3. Put your cash PIN number in the body of the message.

  4. Mail this message to the authors of this book.

  5. We will have fun shopping on your credit card.

Password management should not always be left up to the user. Most operating systems and web servers will have some built-in mechanism to manage the password policies that you will put in place. If possible, take the following steps:

1. Enforce a reasonable minimum password length, which increases the number of permutations needed to randomly or programmatically guess someone's password. You should also enforce an alphanumeric password combination.

2. Enforce maximum and minimum password age. A maximum password age forces the user to change the password after a period of time, preventing someone else from discovering it. A minimum password age prevents a user from immediately reverting back to a previous password after a change.

3. Enforce password uniqueness and maintain password history. These steps prevent users from bouncing between their favorite passwords. You should specify the number of unique passwords that a user must have before that user can use a password that has previously been used.

6.3.2 Tokens

One authentication method is to use a concept known as "tokens." Tokens can be hardware and/or software. One mechanism that tokens provide is to authenticate at a central point and receive a token. That token is then used via a session to access several secure resources. NT uses a similar system with its System Account Management (SAM) DB. Another type of token is a computerlike card, which is effectively a password calculator. In this case, there is no physical connection to the client computer. In essence, no software or hardware is required of the client. The token contains a secret value, which is used to respond to challenges. Some of the best-known tokens cards are from ActivCard and from Security Dynamics (Secure ID).

Token cards can also protect against both passive attacks and instant replay attacks, in which one of the "bad dudes" records valid authentication information exchanged between one of the computers and then attempts to replay it later to gain entry. Sorry, Charlie, but this won't work, because token cards provide "once only" passwords. The password can change many times during a day, making replay nearly impossible.

There are software token cards. These tokens allow a person who travels frequently to various locations, and who uses a personal computer or lap-top, to access various services. The disadvantage of using the software token cards method is that some specialized software normally needs to be loaded onto one personal computer for its use. Also, you may be limited to one personal computer, whereas the hardware token card can be used on any personal computer. In the best case, you will need to load the software again on each computer you use or carry some type of token software with you.

The use of token-based authentication systems is becoming an efficient and cost-effective means to implement security. If you are on the road and need access to your company's network, you can do so just by plugging your laptop into any network-enabled Ethernet connection. Here is how it works: You will use a simple device known as a "KEYFOB," which has a numeric display that shows a series of numbers. The numbers change every 60 seconds. You enter the number from the token card and a PIN. Now you can access your network. In 60 seconds, the numbers that you used to get into the network will not work.

Token-based security systems have been on the market for more than 10 years. Using these types of systems, you can secure most types of hardware and software. The goal of these authentication systems is to provide strong authentication not only to your network but to the desktop as well. So watch out for future enhancements and new products.

One process that we have not discussed is using browser cookies. You can use cookies as a token. The process, as follows, is simple and effective.

1. The user will access a web server via a browser.

2. The server will issue a cookie to the browser. The cookie is encoded and time stamped, for example, for 30 minutes.

3. Using the cookie, the browser now can access other servers and access data using the cookie as credentials.

4. The server can then monitor the cookie and track its user and expiration. If the cookie is not used in 30 minutes, it is declared invalid.

Advantages

• Only one prompt per authentication is necessary. HTTP realms can be bypassed or managed via this type of system.

• It is easy to track each cookie as it authenticates into each application.

• Using this type of system, you can "time out" users due to inactivity.

Disadvantages

• The user must enable cookies. If not, the user could go crazy with prompt warnings about cookies from the browser.

• Specialized software is necessary that can communicate between servers to pass "validity" information about current and authorized users.