Figure 6.2
|
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.)
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.
Advantages
Easy to implement and manage
Inexpensive provided with most operating systems and web servers
Only minimal training required for end users
Disadvantages
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)
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.
Advantages
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)
Disadvantages
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
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.
Advantages
The person is the authentication very difficult to impersonate
Directory attacks are nearly impossible
Offers some mechanisms for a single sign-on solution
Disadvantages
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.)
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.
Advantages
Easy to bind the card to the person
The card can hold keys and other information about the user
If keys are included, then it is easy to encrypt data and e-mail
Easy to train users on the technology
Great solution for roaming users; the certificate can easily be transported
Disadvantages
Very expensive, although the cost of this technology is dropping
Still easy to give the card and PIN to another user i.e.,"tailgating"
Requires a support system and may require more hardware on each PC
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.
Advantages
Easy to implement
Little to no user training required
Ability to conduct secure transactions without registering a user with a user name and password. How? Have you ever purchased a book online and used a credit card? Not all companies will require you to create an account. All you need to do is enter your credit card information (and hopefully you used SSL!)
Disadvantages
Clearly, there is no binding to a specific user. Consequently, you don't know who accessed the data
Cannot block access on a "per-user" basis
Potentially open to "spam" attacks, where garbage is dumped onto your site
No logging or audit trail
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.
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
|
