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.


  • 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.


  • 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.

6.3.3 Kerberos (guard dogs)

"Kerberos," named after the dog in Greek mythology that guarded the gates of Hades, is software that is used in a network to establish a user's identity. Developed by MIT (Massachusetts Institute of Technology) in the mid-1980s, Kerberos uses a combination of encryption and distributed databases so that a user can log in and start a session from any computer on the network. This can be a real advantage on a network with a lot of roaming users. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server across a network connection. After a client and server have used Kerberos to prove their identity, they can also encrypt all their communications for privacy and data integrity. Kerberos is freely available from MIT under a copyright permission notice very similar to the one used for the BSD operating and X11 Windowing system. MIT provides Kerberos in source form.

Kerberos is a network authentication system targeted for use on physically insecure networks. It is implemented by communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. Data stream integrity is provided. Users or systems are given "tickets" that can be used to identify themselves to other systems, and secret cryptographic keys are provided for secure communication with other systems. A "ticket" is a small sequence of a few hundred bytes. Using this ticket system, a ubiquitous access system can be designed allowing a single ticket to authenticate with many different security mechanisms. Overall, Kerberos is used in application level protocols. Remember the OSI reference model? Kerberos lives on level seven.

The Kerberos protocol is composed of three subprotocols: authentication service (AS) exchange; ticket-granting service (TGS) exchange; and client/server (CS) exchange.

Authentication service (AS) exchange

The user accesses the network by typing a log-on name and password. The Kerberos-enabled client converts the password to an encryption key and saves the result in a variable. The client then requests credentials from the Kerberos Key Distribution Center (KDC). When the KDC receives the request, it looks up the user in its database, gets the user's master key, decrypts the preauthentication data, and evaluates the time stamp inside. Once the user's identity has been validated, the KDC creates credentials that the client can present to the ticket-granting service.

Ticket-granting service (TGS) exchange

The Kerberos client on the user's workstation requests credentials for the service by sending a message to the KDC. This message consists of the identity of the service for which the client is requesting credentials and an authenticator message encrypted with the user's new log-on session key. The KDC uses the log-on session key to decrypt the user's authenticator message and evaluates it for validity. If the authenticator passes the test, the KDC extracts the user's authorization data and creates a session key for the user to share with the targeted server. The KDC encrypts one copy of the service session key with the user's log-on session key. The KDC embeds another copy of the service session key in a ticket, along with the user's authorization data, and encrypts the ticket with the server's master key. The KDC sends these credentials back to the client. When the client receives the reply, it decrypts the service session key with the user's log-on session key and stores the service session key in its ticket cache. The client extracts the ticket to the server and stores that in its ticket cache.

Client/Server (CS) exchange

Once a user has a ticket to a server, the workstation client can establish a secure communications session with that server. The client sends the server a message containing an authenticator message encrypted with the key sent by the KDC for the session with the server. Also sent is a ticket for sessions with the server, and a flag indicating whether the client requests mutual authentication. The server receives the request, decrypts the ticket, and extracts the user's authorization data and the session key. The server uses the session key from the ticket to decrypt the user's authenticator message and evaluates the time stamp inside. If the authenticator message is valid, the server checks the mutual authentication flag in the client's request. If the mutual authentication flag is set, the server uses the session key to encrypt the time from the user's authenticator message and returns the result in a message of type Kerberos Application Reply. When the client receives the reply, it decrypts the server's authenticator message with the session key it shares with the server and compares the time sent back by the service with the time in its original message. If everything matches, then the client is assured that the service is genuine, and the connection is validated.

There are several different versions and distributions of Kerberos. Most of them are based on an MIT distribution.

Versions of Kerberos V4

Versions of Kerberos V5

In the United States and Canada, Kerberos is available via anonymous FTP from athena-dist.mit.edu ( [3]

6.3.4 Single sign-on

Single sign-on programs allow a user to authenticate one time and, thereafter, be able to access additional network resources and systems without having to reenter passwords during future log-ins.

In use, many single sign-on (SSO) systems operate as follows:

  1. The user enters a user name and password to a primary log-in program. The program then authenticates the user against a master system.

  2. After this one-time authentication, the user may then request access to additional systems. Each time he or she does so, the single sign-on system will retrieve the user's password to use in the new system and will start a session using that password.

The main purpose of single sign-on, therefore, is to enable authorized users to perform one initial sign-on to access a variety of networks, systems, and applications. From the user's point of view (fewer user IDs and passwords to remember), single sign-on is a desirable feature. [4]

Advantages of Single Sign-On Systems

Through use of a secure single sign-on system, a business enterprise and its users can realize the following benefits.

Disadvantages of Single Sign-On Systems

The single sign-on selection process

When determining which single sign-on system may be the best for your enterprise, the following points should be evaluated:

The growing number of user names and passwords that users need to memorize in order to do their jobs continues to grow. SSO allows users to access many applications through the use of a single password log-on. The benefits of SSO include cost reduction due to reduced user downtime and administrative costs associated with contacting help desks to recover forgotten passwords; increased productivity; and a strengthened security infrastructure. When selecting an SSO, due consideration should be placed on selecting a system that is easy to use and administer, is compatible with existing operating systems, and allows for the addition of new applications without having to make changes to the SSO. [7]

[3]http://www.securitydynamics.com/; http://www.ibm.com/; http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/secspi/aboutsspi_302t.htm

[4]Source: http://www.m-tech.ab.ca/papers/ps_sso/node2.html


[6]Source: http://www.gocsi.com/sso_ft.htm

[7]Source: http://www4.ibm.com/software/network/globalsignon/library/whitepapers/white-overview.html

Internet Security(c) A Jumpstart for Systems Administrators and IT Managers
Internet Security: A Jumpstart for Systems Administrators and IT Managers
ISBN: 1555582982
EAN: 2147483647
Year: 2003
Pages: 103
Authors: Tim Speed, Juanita Ellis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net