Secure Authentication using ASP.NET (avoid Account hijacking, information leakage ) Part 2
Post date: Jul 20, 2011 3:02:13 AM
Previous article we were discussed about form authentication.
When using forms authentication, remember that it only applies to those resources managed by ASP.NET. That includes any files with the extensions:
.asax
.aspx
.ascx
.ashx
.asmx
.axd
.vsdisco
.rem
.soap
.config
.cs
.csproj
.vb
.vbproj
.webinfo
.licx
.resx
.resources
.jsl
.java
.vjsproj
If you use forms authentication and request a file in a protected directory with any of these extensions, you will be forwarded to the login page. If you request a file with any other extension, you will get the file directly, with no request for authentication. For instructions on how to secure all files.
Most ASP.NET security features only protect ASP.NET resources, so you must take extra measures to protect non-ASP.NET files. To do that, you have to map these resources to the ASP.NET ISAPI filter using IIS 5 or IIS 6.
Using IIS 5:
In the Internet Services Manager, select the properties for the application to configure.
From the tab, click the button.
From the tab, click the button.
Click the button, and locate the .NET ISAPI filter (typically located at C:\Winnt\Microsoft.NET\Framework\<version>\aspnet_isapi.dll).
Enter the extension you want to map to ASP.NET (or enter to map all extensions).
Using IIS 6:
In the Internet Services Manager, select the properties for the application to configure.
From the tab, click the button.
From the tab, click on the button.
Click the button and locate the .NET ISAPI filter (typically located at C:\Winnt\Microsoft.NET\Framework\<version>\aspnet_isapi.dll).
Enter the extension you want to map to ASP.NET.
To add a wildcard mapping, click from the tab, and enter the path to the .NET ISAPI filter.
Note that adding wildcard application maps cause ASP.NET to handle all file extensions. This will work fine for most static content, but you will not be able to do this for extensions mapped to other applications, such as Perl or Cold Fusion. Wildcard mappings might have some effect on server performance, depending on the type of content in your Web directories. ASP.NET does have a special handler for static content, but you might want to run performance tests for your particular Web site.
Using Windows Authentication
In addition to Forms authentication, ASP.NET provides support for native IIS authentication methods, collectively referred to as Windows Authentication. When Windows Authentication is used, the browser prompts the user for a username and password, as shown in Figure 2.7.
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
Tip
Note that code in an HTTP module runs only on files handled by ASP.NET. If you want ASP.NET to handle all files, follow the instructions in the sidebar “Mapping Non-ASP.NET Resources.”
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.
Figure 2.12: Citibank’s Passport Login Form
Although Passport lets you set various parameters for security, there is no guarantee that other participating sites are going to use the same level of security. In other words, although you might choose to use more secure settings, the user’s password is no more secure than the security implemented by the least secure participating Passport site.
Despite these shortcomings, there are many uses for Passport. Web sites that use Passport for user customization or sites that do not store personal information are particularly well-suited for Passport authentication. In fact, it is beneficial for sites such as these to use Passport authentication rather than giving a user yet another username and password to have to remember. Many Web developers are not qualified to create secure account management features, and in these cases, Passport is a more secure option.
But for Web sites with sensitive financial and personal information, you should carefully consider the risks of Passport or any single sign-on mechanism. The Citibank example in Figure 2.13 says that after authenticating with .NET Passport, you’ll be asked to enter another password. Although this is a good security measure and makes up for many of Passport’s shortcomings, it makes me wonder why anyone would even bother with a single sign-on solution if you are going to make the user remember another password anyway.
Security Policies
Avoid using Passport on Web sites that store sensitive financial and personal information.
If using Passport on a sensitive site, consider implementing additional methods to authenticate the user.