6.2 Authentication

6.2 Authentication

There are many different methods that can be used to authenticate a user.

  • User name and password

  • Certificates (x.509v3)

  • Biometric techniques (more on this later)

  • Smart cards

  • Anonymous (Yes, there is such a method and we will discuss it in this chapter.)

6.2.1 User name and password

Overall, a user name and password are easy to set up and implement. Most operating systems and web servers will have some type of user name and password authentication system. Most of these systems will have some type of mechanism to manage the user name and password architecture for example, account expiration, password expiration, password length, and/or quality of password. Currently, this is the access method of choice for most pages on the Internet.


  • Easy to implement and manage

  • Inexpensive provided with most operating systems and web servers

  • Only minimal training required for end users


  • User name and password sent in the clear for basic authentication (although not in all cases, and SSL can encrypt at the Network level)

  • User name and password subject to directory attacks

  • On the Internet, users may have many different user names and passwords (which can be a real headache to maintain)

6.2.2 Certificates (x.509v3)

User certificates can be used by end users to assure their identity; Lotus Notes has a built-in certificate system using a physical ID file. You can have an x.509v3 certificate in your browser and it will allow you to access various web applications that support this type of authentication. Access to the certificate is normally controlled by a password that is local to the certificate. For example, on Netscape you can open the certificate database with a password, which then allows you to use the certificate. With the exception of x.509v2 and SSL, thus far this technology has not been widely used on the Internet. Many companies are starting to implement user certificates on their internal network.


  • Binds the certificate to the user

  • Ability to encrypt data and digitally sign messages

  • Supported by most web browsers and e-mail packages

  • Offers some mechanisms for a single sign-on solution

  • Difficult to stage a directory attack

  • Allows roaming users, i.e., users moving from one location to another (if your vendor supports this feature)

  • Can encrypt data, e-mail, and sign with only one certificate (actually, it is better to have separate certificates for signing and encryption)


  • Cost implementing a PKI can be expensive

  • Extensive user training is required

  • Requires a support structure

  • Roaming users, i.e., users moving from one location to another (not many vendors support this feature but this is getting better)

  • Vendors are only now developing tools that can handle large-scale implementations

6.2.3 Biometric techniques

A biometric authentication system will use devices such as fingerprints or eye scanners to allow access. This type of device can ensure greater security for high-risk environments that need to limit and control access to sensitive systems. Using this type of system, you could limit "tailgating," or, allowing users to use another person's user name and password.


  • The person is the authentication very difficult to impersonate

  • Directory attacks are nearly impossible

  • Offers some mechanisms for a single sign-on solution


  • Not many vendors support this technology

  • Expensive to implement

  • Very few examples of this technology exist

(Check out http://www.microsoft.com/ Microsoft is working with I/O Software for a solution to run on Windows.)

6.2.4 Smart cards

A smart card is typically a credit card-sized plastic card that has an embedded integrated circuit (IC) chip. This chip is what makes the card "smart." The smart card can store all types of information, which can be transferred via an electronic interface that connects to a computer. This smart card can store information about who you are and cryptographic keys and perform cryptographic algorithms, like encryption. Access to the smart card is controlled via a PIN or a password.



6.2.5 Anonymous

The argument may be made that "anonymous" is not an authentication method. An anonymous user name is a method for giving users access to files so they don't need to identify themselves to the server. The user enters "anonymous" as a user ID. Usually, the password is defaulted or furnished by the server. Anonymous identification is a common way to get access to a server to view or download files that are publicly available.

Through the use of a control anonymous setting, anonymous is both an authentication method and an authorization method. By accessing a system via a control anonymous setting, you can be sure that you know where users are and what data they are accessing. This can be accomplished by use of Access Control Lists (ACLs) and audit logging. There will be cases where you want and need anonymous access to a data source. Never assume that anonymous should be a "default" access. This is dangerous. Make sure you limit anonymous access to the data sources that really need to gain access.



At this point, we are going to focus on basic authentication, a process widely used by browsers on the Internet. Basic authentication uses a series of status codes to communicate with a browser. See ftp://ftp.isi.edu/innotes/rfc2617.txt and ftp://ftp.isi.edu/in-notes/rfc2616.txt for details.

"Status code" is one of the primary mechanisms that alerts the browser to the fact that credentials are needed (i.e., user name and password). The user will type in a URL, and that URL will access a page that is "secure." The server will return a status code; one of the codes may be 401. The browser will then prompt the user with a dialog box and enter his or her user name and password, which will be submitted back to the server. There are many different status codes. Here is an extract of the status codes from RFC 2616.

Status-Code =

| "101"; Section 10.1.2: Switching Protocol | "200"; Section 10.2.1: O | "201"; Section 10.2.2: Created | "202"; Section 10.2.3: Accepte | "203"; Section 10.2.4: Non-Authoritative Informatio | "204"; Section 10.2.5: No Conten | "205"; Section 10.2.6: Reset Conten | "206"; Section 10.2.7: Partial Conten | "300"; Section 10.3.1: Multiple Choice | "301"; Section 10.3.2: Moved Permanentl | "302"; Section 10.3.3: Foun | "303"; Section 10.3.4: See Other [1] | "304"; Section 10.3.5: Not Modifie | "305"; Section 10.3.6: Use Prox | "307"; Section 10.3.8: Temporary Redirec | "400"; Section 10.4.1: Bad Reques | "401"; Section 10.4.2: Unauthorize | "402"; Section 10.4.3: Payment Require | "403"; Section 10.4.4: Forbidde | "404"; Section 10.4.5: Not Foun | "405"; Section 10.4.6: Method Not Allowe | "406"; Section 10.4.7: Not Acceptabl | "407"; Section 10.4.8: Proxy Authentication Require | "408"; Section 10.4.9: Request Time-Ou | "409"; Section 10.4.10: Conflic | "410"; Section 10.4.11: Gon | "411"; Section 10.4.12: Length Require | "412"; Section 10.4.13: Precondition Faile | "413"; Section 10.4.14: Request Entity Too Larg | "414"; Section 10.4.15: Request-URI Too Larg | "415"; Section 10.4.16: Unsupported Media Type | "416"; Section 10.4.17: Requested Range Not Certifiabl | "417"; Section 10.4.18: Expectation Faile | "500"; Section 10.5.1: Internal Server Erro | "501"; Section 10.5.2: Not Implemente | "502"; Section 10.5.3: Bad Gatewa | "503"; Section 10.5.4: Service Unavailabl | "504"; Section 10.5.5: Gateway Time-Ou | "505"; Section 10.5.6: HTTP Version Not Supporte 

This extract shows the actual process that the server will implement to send the status code back to the browser. [2] If a server receives a request for an access-protected object and an acceptable authorization header is not sent, the server responds with a "401 Unauthorized" status code and a "WWW-Authenticate" header as per the preceding defined framework, which, for the digest scheme, is utilized as follows:

challenge = "Digest" digest-challeng digest-challenge = 1#(realm | [domain] | nonce  [opaque] |[stale] | [algorithm]  [qop-options] | [auth-param] domain = "domain" "=" <"> URI (1*SP URI) <"> URI = absoluteURI | abs_pat nonce = "nonce" "=" nonce-valu nonce-value = quoted-strin opaque = "opaque" "=" quoted-strin stale = "stale" "=" ("true" | "false" algorithm = "algorithm" "=" ("MD5" | "MD5-sess"  token qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | toke 

Figure 6.2 shows a 401-status code being returned back to the browser.

click to expand
Figure 6.2

[1]This code is the same as 302, except that the client should make a GET request for the new URL, regardless of the original request method.

[2]Source: ftp://ftp.isi.edu/in-notes/rfc2617.txt

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