Secure Authentication using ASP.NET (avoid Account hijacking, information leakage ) Part 2

Figure 2.7: Windows Authentication Prompt

To implement Windows authentication, modify the web.config file as _follows:

<authentication mode="Windows" />   <authorization>     <deny users="?" />   </authorization>

You must then open the Internet Services Manager and select the properties for the protected content directory. Uncheck anonymous access and select an authentication method.

IIS provides four standard methods for authentication:

Basic authentication

Digest authentication

Integrated Windows authentication

Client certificate mapping

Basic Authentication

Basic authentication works by prompting a Web site visitor for a username and password. This method is widely used because most browsers and Web servers support it. The benefits are:

• • It works through proxy servers.

  • It is compatible with nearly every Internet browser.

  • It allows users to access resources that are not located on the IIS server.

Basic authentication also has some drawbacks:

• • Information is sent over the network as cleartext. The information is encoded with base64 encoding (see RFC 1521 for more information on base64 encoding), but it is sent in an unencrypted format. Any password sent using basic authentication can easily be decoded.

  • By default, users must have the Log On Locally right to use basic authentication.

  • Basic authentication is vulnerable to replay attacks.

Because basic authentication does not encrypt user credentials, it is important that traffic always be sent over an encrypted SSL session. A user authenticating with basic authentication must provide a valid username and password. The user account can be a local account or a domain account. By default, the IIS server will look locally or in Active Directory for the user account. If the user account is in a domain other than the local domain, the user must specify the domain name during logon. The syntax for this process is domain name\username, where domain name is the name of the user’s domain. Basic authentication can also be configured to use user principal names (UPNs) when you use accounts stored in Active Directory.

To prevent exposing user credentials to others on the network, it is essential that you always use SSL with basic authentication. Note that basic authentication causes the browser to send user credentials to every page on the same site or within the same realm, not just the login page. If you don’t use SSL on every page, user credentials will be visible on the network. One way to prevent these credentials from being sent on unprotected content is to use a unique realm for protected and unprotected content. 

Digest Authentication

Digest authentication has many similarities to basic authentication, but it overcomes some of the problems. Digest authentication does not send usernames or passwords over the network. It is more secure than basic authentication, but it requires more planning to make it work.

Some of the similarities with basic authentication are:

• • Users must have the Log On Locally right.

  • Both methods work through firewalls.

Like all authentication methods, digest authentication does have some drawbacks:

• • Users can only access resources on the IIS server. Their credentials can’t be passed to another computer.

  • The IIS server must be a member of a domain.

  • All user accounts must store passwords using reversible encryption.

  • The method works only with Internet Explorer 5.0 or higher.

  • Digest authentication is vulnerable to replay attacks, to a limited extent.

Digest authentication is secure due to the way it passes authentication information over the network. Usernames and passwords are never sent. Instead, IIS uses a message digest (or hash) to verify the user’s credentials. In order for digest authentication to work, all user accounts must be stored using reversible encryption in Active Directory, which may be a potential risk. After this setting is enabled for a user account, the user’s password must be changed to create the plaintext copy.

Digest authentication does provide more security, but for most Web sites, the limitations of this method outweigh the benefits. One interesting peculiarity with IIS is that when you send authentication headers to a client, it will send the basic authentication header before the digest one. Many Internet browsers use the first header they encounter and therefore opt for the weaker basic authentication.

Integrated Windows Authentication

Integrated Windows authentication is also a secure solution because usernames and passwords aren’t transmitted across the network. This method is convenient because, if a user is already logged on to the domain and if the user has the correct permissions for the site, the user isn’t prompted for his or her username and password. Instead, IIS attempts to use the user’s cached credentials for authentication. The cached credentials are hashed and sent to the IIS server for authentication. If the cached credentials do not have the correct permissions, the user is prompted to enter a different username and password.

Depending on the client and server configuration, integrated Windows authentication uses either the Windows NT LAN Mangager (NTLM) or Kerberos for authentication. You cannot directly choose which one is used; IIS will automatically choose a method based on the server and client configuration. The Web browser and the IIS server negotiate which one to use through the negotiate authentication header. Both Kerberos and NTLM have their own advantages and disadvantages. Kerberos is faster and more secure than NTLM. Unlike NTLM, which authenticates only the client, Kerberos authenticates both the client and the server. This helps prevent spoofing. Kerberos also allows users to access remote network resources not located on the IIS server. NTLM restricts users to the information located on the IIS server only.

Kerberos is the preferred authentication method for an intranet Web server. However, the following requirements must be met for Kerberos to be used instead of NTLM:

• • Both the client and server must be running Windows 2000 or later.

  • The client must be using Internet Explorer 5 or later.

  • The client and server must be in either the same domain as the IIS server or in a trusted domain.

Integrated Windows authentication has a few limitations:

• • It works only with Internet Explorer 3.01 or later.

  • It does not work through a firewall. The client will use the firewall’s IP address in the Integrated Windows hash, which will cause the authentication request to fail.

Client Certificate Mapping

Client certificate mapping is the process of mapping a certificate to a user account. Certificates can be mapped by Active Directory or by IIS. Both of these methods require Secure Sockets Layer (SSL). There are three types of certificate mappings:

• • One-to-one mapping

  • Many-to-one mapping

  • UPN mapping

Certificate mapping is the process of linking a certificate to a specific user account. Normally, if we wanted to give a user authenticated access to the intranet, we would either create a user account or allow the user to log in using his domain account. Creating duplicate accounts is time-consuming, yet if users use their domain accounts, there is the concern that their domain passwords could become compromised.

To provide better security and reduce the administrative workload, we could choose to issue each user a certificate. Certificates can be used to verify a user’s integrity. It is actually more efficient to use a certificate than a user account because certificates can be examined without having to connect to a database. It is generally safer to distribute certificates than user accounts. Furthermore, it is much easier to guess or crack someone’s password than it is to forge a certificate.

Authenticating Users

If you are securing an intranet application for which you have control over the server and client configuration and the corresponding clients and server(s) are in the same domain, integrated Windows authentication is probably the best solution. For a public Web site, the most widely supported method is basic authentication over an SSL connection. Because basic authentication is secure only if you use SSL, you might want to enforce this policy on your server. You can do this through an HTTP module, as shown in Figure 2.8 (C#) and Figure 2.9 (VB.NET). Every time an authentication request is sent to the server, this code checks to see if the request is using basic authentication and if it is sent over an SSL connection. If both those criteria are not met, the code returns a “403.4 SSL Required error” message back to the client.

using System; using System.Web; using System.Security.Principal; namespace HttpAuthModules {   public class AuthenticationModule : IHttpModule   {     public AuthenticationModule()     {     }     public void Init(HttpApplication httpApp)     {       // Register the event handler with Application object.       httpApp.AuthenticateRequest +=          new EventHandler(this.AuthenticateRequest);     }     private void AuthenticateRequest(object obj, EventArgs ea)     {       HttpApplication objApp = (HttpApplication) obj;       HttpContext objContext = (HttpContext) objApp.Context;           // Deny access if user is using basic authentication without SSL       if (objApp.User.Identity.AuthenticationType == "Basic" &&          objContext.Request.IsSecureConnection == false)       {               objContext.Response.StatusCode = 403;               objApp.Response.End();             }       }     public void Dispose()     {     }   } }

Figure 2.8: Blocking Basic Authentication Without SSL: C#

Imports System.Web Public Class AuthenticationModule   Implements IHttpModule   Public Sub Init(ByVal app As HttpApplication) Implements IHttpModule.Init     AddHandler app.AuthenticateRequest, AddressOf Me.AuthenticateRequest   End Sub   Public Sub Dispose() Implements IHttpModule.Dispose   End Sub   Private Sub AuthenticateRequest(ByVal obj As Object, ByVal ea As        System.EventArgs)     Dim objApp As HttpApplication     Dim objContext As HttpContext     objApp = obj     objContext = objApp.Context     ' Deny access if user is using basic authentication without SSL     If objApp.User.Identity.AuthenticationType = "Basic" And _       objContext.Request.IsSecureConnection = False Then       objContext.Response.StatusCode = 403       objApp.Response.End()     End If   End Sub End Class

Figure 2.9: Blocking Basic Authentication Without SSL: VB.NET

Another problem with authenticating to the operating system or domain is that there is no direct control over which account is used to log in. If you provide a login box, anyone with an account on that system can try to log in. They might not be able to gain access to the resource, but they can authenticate to the server. This gives attackers the opportunity to launch brute-force attacks against privileged accounts such as Administrator.

Depending on the network and server configuration, Windows authentication might also allow relaying attacks from the Web server to other trusted domains or servers on the internal network. Windows authentication allows the user to enter a domain-qualified name in the format domain\username to authenticate to other trusted domains. If an attacker knows the name of other trusted domains that the Web server can see, he or she can potentially relay attacks by trying to authenticate to the internal domain. Basic authentication can also be configured to leverage UPNs when you use accounts stored in Active Directory, again providing more opportunity for data relay attacks.

When using Windows authentication, you might want to restrict which users can log in to the server. You can use file or URL authorization to prevent access, but this doesn’t prevent the user from trying to authenticate—it just prevents the user from accessing the content. Both of these methods enforce access based on the username, so a user must first be authenticated. If you don’t want to expose a privileged user account to a brute-force attack through your authentication mechanism, you can simply prevent that user from authenticating at all through the Web application. One way to accomplish this goal is through an HTTP module, as shown in Figure 2.10 (C#) and Figure 2.11 (VB.NET). This code checks the username whenever an authentication request is sent to see if it contains the user Administrator and returns an “HTTP 401 error” message if it does. This prevents anyone from even attempting to authenticate as Administrator.

using System; using System.Web; using System.Security.Principal; namespace HttpAuthModules {   public class AuthenticationModule : IHttpModule   {     public AuthenticationModule()     {     }     public void Init(HttpApplication httpApp)     {       // Register the event handler with Application object.       httpApp.AuthenticateRequest +=          new EventHandler(this.AuthenticateRequest);     }     public void AuthenticateRequest(object obj, EventArgs ea)     {       HttpApplication objApp = (HttpApplication) obj;       HttpContext objContext = (HttpContext) objApp.Context;         // If user identity is not administrator, return 403 code       if ( objApp.User.Identity.Name.IndexOf("administrator") >= 0)       {         objContext.Response.StatusCode = 403;         objApp.Response.End();       }           }     public void Dispose()     {     }   } }

Figure 2.10: Blocking Administrator Logins: C#

Imports System.Web Public Class AuthenticationModule   Implements IHttpModule   Public Sub Init(ByVal app As HttpApplication) Implements IHttpModule.Init     AddHandler app.AuthenticateRequest, AddressOf Me.AuthenticateRequest   End Sub   Public Sub Dispose() Implements IHttpModule.Dispose   End Sub   Public Sub AuthenticateRequest(ByVal obj As Object, ByVal ea As _  System.EventArgs)     Dim objApp As HttpApplication     Dim objContext As HttpContext      objApp = obj     objContext = objApp.Context     ' If user identity is not administrator, return 403 code     If objApp.User.Identity.Name.IndexOf("administrator") >= 0 Then       objContext.Response.StatusCode = 403       objApp.Response.End()     End If   End Sub End Class

Figure 2.11: Blocking Administrator LoginsVB.NET

Security Policies

• • Always use SSL with every page that uses basic authentication.

  • Use unique realms for protected and unprotected content.

  • Use Integrated Windows authentication if possible in an intranet environment.

  • Block privileged users from brute-force attacks by preventing them from authenticating.

Passport Authentication:

In mid-1999, Microsoft released its Passport service, a single sign-on and e-commerce solution for the Web. Despite widespread privacy and security concerns, the Passport service is constantly growing, with support from large companies such as eBay, McAfee, and Citibank.

But many consumers feel uneasy with the concept of such a large central database controlled by a private company. With so much centralized control over this data, the potential for abuse is great. Another concern is security. Microsoft’s Passport service has had problems and has not gone long enough without security flaws to prove itself a reliable service.

Nevertheless, Passport does have its benefits. For consumers, it’s fewer passwords to remember; for Web sites, it involves no hassle setting up a user database. One could argue that having a single authentication service with a few flaws might even be better than a thousand poorly secured Web sites. But the risk is with the single point of failure: If someone hijacks your Passport account, that person gains access to every service you use with Passport.

One problem is that Microsoft has not proven that the service is secure; all we really have to go by is that the company says it is secure. Being a proprietary system, it has not gone through a public review. Microsoft doesn’t make much effort to publish third-party audits of the Passport services, nor does the company justify its security with details of the security measures it employs. Consequently, only time will tell us how secure Passport is. Another problem is that as more sites begin to use Passport, the more attractive it will become as a target.

The Passport login forms from different sites are not consistent in appearance or format—sometimes appearing inline, as at Hotmail.com and MSN.com; appearing on their own pages at the same site, as at eBay.com (see Figure 2.12), or appearing as a customized branded page at login.passport.net (see Figure 2.13). Depending on your operating system, you might also be prompted for a .NET Passport from a Windows dialog box or wizard. The problem with this lack of consistency is that it makes it more difficult for users to discern a real login box from a fake login box. In fact, anyone can probably put a fake .NET Passport sign-in box on a Web site and simply collect the usernames and passwords people enter.