Module Objectives

Authentication is any process by which one verifies that someone is who they claim they are. Typically, this involves a username and a password. It can also include any other method of demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints .

In this module we will discuss the following topics in the context of web based authentication. The objective is to familiarize the reader with commonly used authentication methods and how some these methods can be worked around, under certain circumstances.

• HTTP Authentication Basic & Digest

• NTLM Authentication

• Certificate Based Authentication

• Forms Based Authentication

• Microsoft Passport

• Password Guessing

• WebCracker

• Brutus

• WWWHACK

• ObiWan Password Cracker

Basic Authentication

• Basic authentication is the most basic form of authentication to web applications.

• The authentication credentials are sent clear -text with base64 encryption (can be decoded) and is subject to eavesdropping and replay attacks.

• The use of 128 bit SSL encryption can thwart attacks.

 

Concept  

Basic authentication ^[1] is the simplest method of authentication and for a long time was the most common authentication method used. The "basic" authentication scheme is based on the model that the client must authenticate itself with a user -ID and a password for each realm. The realm value (case-sensitive) is a string, which may have additional semantics specific to the authentication scheme. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server.

The server will service the request only if it can validate the user-ID and password for the protection space of the request-url. There are no optional authentication parameters. To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials.

When a particular resource has been protected using basic authentication, HTTP sends a 401 authentication required header with the response to the request, in order to notify the client that user credentials must be supplied in order for the resource to be returned as requested . Upon receiving a 401 response header, if the client's browser supports basic authentication, it will ask the user to supply a username and password to be sent to the server.

Every resource which is requested from the server will have to supply authentication credentials over again in order to receive the resource. Because the HTTP protocol is stateless, each request will be treated in the same way, even though they are from the same client. The client browser caches the username and password supplied, and stores it along with the authentication realm, so that if other resources are requested from the same realm, the same username and password can be returned to authenticate that request without requiring the user to type them in again. Login information is stored on the browser based on the authentication realm, and by the server name .

In this way, the browser can distinguish between the private authentication realm on one site and on another.

Note  

Basic authentication should not be considered secure for any particularly rigorous definition of secure. Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across. The username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at any particular time, but just long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Digest Authentication

• Digest authentication is based on a challenge-response authentication model.

• The user makes a request without authentication credentials and the Web Server replies with a WWW-Authenticate header indicating credentials.

• Instead of sending the username and password the server challenges the client with random nonce.

• The client responds with the message digest of the username/password.

 

Concept  

In digest authentication ^[2] , the password is never sent across the network in the clear, but is always transmitted as an MD5 digest of the user's password. In this way, the password cannot be determined by sniffing network traffic. The Digest Access Authentication scheme is not intended to be a complete answer to the need for security as this scheme provides no encryption of message content. The intent is simply to avoid the most serious flaw of Basic authentication.

Like Basic Access Authentication, the Digest scheme is based on a simple challenge-response paradigm. An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used. The Digest scheme provides the challenge using a nonce value. A nonce is a server-specified data string which may be uniquely generated each time a 401 response is made.

A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URL. In this way, the password is never sent in the clear.

Note  

Just as with the Basic scheme, the username and password must be prearranged. It is a password-based system and suffers from all the same problems of any password system on the server side. In particular, no provision is made in this protocol for the initial secure arrangement between user and server to establish the user's password.

An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonce or digests for POST or PUT requests and a time-stamp for GET requests . Again, the nonce is opaque to the client. By "opaque" we mean a string of data, specified by the server, which is returned by the client unchanged in the Authorization header of subsequent requests with URIs in the same protection space.

Note  

Although the password is not really sent at all, but a digest form of it, an attacker can use the digested password to gain access to the content, since that digested password is really all the information required to access the web site.

NTLM Authentication

• NTLM Authentication is Microsoft's proprietary NT LAN Manager authentication algorithm over HTTP. It works on Microsoft Internet Explorer only.

• Integrated Windows authentication works the same way as Message Digest authentication.

 

Concept  

NTLM ^[3] is a Microsoft-proprietary protocol that authenticates users and computers based on an authentication challenge and response. NTLM (NT LanMan) is an authentication process that is used by all members of the Windows NT family of products. Like its predecessor LanMan, NTLM uses a challenge/response process to prove the client's identity without requiring that either a password or a hashed password be sent across the network. NTLM authentication does not send the user's password (or hashed representation of the password) across the network. Instead, NTLM authentication utilizes challenge/response mechanisms to ensure that the actual password never traverses the network.

When the authentication process begins, the user's system (client) sends a login request to the telnet server. The server replies with a randomly generated "token" (or challenge) to the client. The client hashes the currently logged-on user's cryptographically protected password with the challenge and sends the resulting "response" to the server.

The server receives the challenge-hashed response and compares it to what it knows to be the appropriate response. (The server takes a copy of the original token - which it generated - and hashes it against what it knows to be the user's password hash from its own user account database.) If the received response matches the expected response, the user is successfully authenticated to the host.

Note  

However, not all is safe again as NTLM hashes (or challenge/response pairs) could be fed into a program that performs brute force password guessing. The "cracking" program would iteratively try all possible passwords, hashing each and comparing the result to the hash that the malicious user obtained. When it located a match, the malicious user would know that the password that produced the hash is the user's password.

To address the problems in NTLM1, Microsoft introduced NTLM version 2 and advocates its use where possible. The following table lists the features of the three authentication methods.

Attribute	LM	NTLMv1	NTLMv2
Password case sensitive	No	Yes	Yes
Hash key length	56bit + 56bit	-	-
Password hash algorithm	DES (ECB mode)	MD4	MD4
Hash value length	64bit + 64bit	128bit	128bit
C/R key length	56bit + 56bit + 16bit	56bit + 56bit + 16bit	128bit
C/R algorithm	DES (ECB mode)	DES (ECB mode)	HMAC_MD5
C/R value length	64bit + 64bit + 64bit	64bit + 64bit + 64bit	128bit

Certificate Based Authentication

• Certificate authentication is stronger than other authentication mechanisms

• Certificated authentication uses publicokey cryptography and digital certificate to authenticate a user. Certificates can be stored in smart cards for even greater security.

• There is no current known attacks against PKI security so far.

 

Concept  

A digital certificate is an electronic document that includes identification information, public key, and the digital signature of a certification authority based on that certification authority's private key. An individual wishing to send an encrypted message applies for a digital certificate from a Certificate Authority (CA). A certification authority (CA) is a trusted entity that signs certificates and can vouch for the identity of the user. The CA issues an encrypted digital certificate containing the applicant 's public key and a variety of other identification information. The CA makes its own public key readily available through print publicity or perhaps on the Internet.

When the user connects to a server to authenticate, he presents the server with his certificate (a digital certificate specific to the user) containing the public key and the signature of the CA. The server first verifies that the signature on the certificate is valid and was generated by a trusted CA. The server then authenticates the user by using public key cryptography to prove that the user truly holds the private key associated with the certificate.

The recipient of an encrypted message uses the CA's public key to decode the digital certificate attached to the message, verifies it as issued by the CA and then obtains the sender's public key and identification information held within the certificate. With this information, the recipient can send an encrypted reply. The most widely used standard for digital certificates is X.509. Digital certificates are used extensively. Some examples of how they are used for authentication include:

• Email. Many customers use digital certificates to encrypt emails (to provide confidentiality) or digitally sign them (to prove their authenticity).

• Network security. Many businesses have deployed smart cards and other security technologies that use digital certificates, as a way of improving the security of their computer network.

Microsoft Passport Authentication

• Single signon is the term used to represent a system whereby users need only remember one username and password, and be authenticated for multiple services.

• Passport is Microsoft's universal single sign -in (SSI) platform.

• It enables the use of one set of credentials to access any Passport enabled site such as MSN, Hotmail and MSN Messenger.

• Microsoft encourages third-party companies to use Passport as a Universal authentication platform.

 

Note  

Single signon is the term used to represent a system whereby users need only remember one username and password, and be authenticated for multiple services. Passport is a suite of services for authenticating users across a number of applications. The Passport single sign in service is an authentication service allowing users to create a single set of credentials that will enable them to sign in to any site (Referred to as "participating sites") that supports a Passport service.

In this example the user browses to Site A, a participating site or service (or browses to www.passport.com), and clicks on the "Sign In" button (or click the "Register" button on Passport.com).

The user is redirected to a co-branded registration page displaying the registration fields that were chosen by Site A. (The minimum number of fields required is two: email name and password.)

• Here the user chooses whether or not they want to opt in to share their information with other Passport-enabled sites that they sign in to.

• The user reads and accepts terms of use (or declines, and the process ends), and submits the form.

• The user is then redirected back to Site A with their encrypted authentication ticket and profile information attached.

• Site A decrypts the authentication ticket and profile information and continues the registration process, or grants access to the site.

• Other participating sites that the user does not interact with (such as sites B and C) do not receive any information about the user. The user does not need to download any software.

Nature of data stored in passport

Information	Data Type	Required to create a Passport?	Shared with other sites? 1
E-mail Address (Sign in name)	Credential and Profile	Yes	If user opts-in
Password	Credential	Yes	Never
Secret Questions and	Credential	Optional	Never
Mobile Phone Number and Mobile PIN	Credential	Only required when registration takes place on a mobile device; otherwise they are optional.	Never
Security Key	Credential	Optional (However a participating site may require the use of a Security Key)	Never

• The first time a user attempts to access a participating site that requires a security key, they are redirected to a Passport registration page.

• When creating a security key, a user is asked to provide and confirm a four-character security key and to select and answer three out of ten secret questions. The three secret questions are used to authenticate the user in the event a security key needs to be reset.

• Users are challenged to re-enter the answers to the three questions before the registration process is finalized. Once the user has successfully answered all three questions the security key is activated.

^[1] Source: HTTP Authentication with EAP, Work in progress, Internet Draft (IETF)

^[2] Source: HTTP Authentication Basic and Digest Access Authentication - RFC2617(draft)

^[3] Source: Microsoft Knowledge Base