Professional ASP.NET Security - Jeff Ferguson

Implementing Password Policies

void Page_Load(Object sender, EventArgs e)

IblRandom.Text = System.Quid.NewGuidf).ToString();

Once the GUID is generated, we can write the new ID to the users table:

ForgotPassword.Aspx?RenewID=18dfIb48-labf-4290-8c88-ba9cbde69614

When users navigate to the page using the GUID and the new password, we can validate the new random password that we've assigned for the user and the GUID. If both are the same as those stored in the table, then we should force the user to change their password. This is a safer way to send a change password link. Of course, we want to treat those user and GUID parameters as suspect external data until they've been validated, or we're at risk for another SQL Injection attack.

Preventing Brute Force Attacks

Brute force attacks are about trying many combinations of the password several thousand times to crack the password. Since we can track the number of times different passwords have been tried for a single user account, we can easily detect this kind of attack. Suppose your application only accepts mistyped passwords three times. After this, we can lock the user account by setting the Locked column to true, and setting the LockedTimeStamp. Then we can display a message informing the user that they cannot attempt to log in again until a five minute time interval has passed.

When the user logs in next time, we can check the time difference. If the time difference is more than five minutes, then we can start processing the authentication request from the user, and try validating the password. If the difference is less then five minutes, we can be almost certain that it is a brute force attack and we can send an e-mail to the user to tell them that someone is trying to break into the system and that their account is temporarily locked. This has the potential for causing friction with impatient users, so it's important that we communicate the message very clearly to the user, so that they are aware that if they attempt to log in again within that five minute period, then their account will be locked. If the application is more sensitive, such as an online banking application, or stock trading account, then we could call the user directly, ask if they were trying to log in to the system, and offer assistance, if necessary. Again, it depends on the nature of the business.

Summary

As we have seen, part of ensuring that our application is secure involved making sure that our users use good passwords, and change them frequently. Putting in place mechanisms to ensure this forms part of a more general password policy. As developers, we need to understand the importance of a sound password policy, and put in place systems to help implement it. We have covered the following topics:

Q What makes a good password: requiring a minimum length, using mixed cases, numbers, and symbols.

G Running a dictionary check on new passwords, and ensuring that password updates are implemented.

103

Q Implementing a simple solution to ensure that users' new passwords are indeed new, and assigning a random password for each user.

Q How to safely allow users to change passwords when they forget their passwords. Q Implementing strategies to prevent brute force attacks.

In the next chapter, we will look in more detail at two key concepts involved in securing and managing access to an application: authentication and authorization.

104

The ASP.NET Security Framework

Web site security is an issue that we all have to deal with, whether we need to secure an e-commerce application to ensure our customers are matched up to their accounts and respective orders, prevent malicious users from accessing other user's data, or simply provide a limited amount of security (in the form of authentication) to provide some personalization and customization of our web site. At either end of this spectrum of security needs, there is a need for an underlying framework to provide basic security functionality, such as identifying a user, and possibly determining the user's permissions to access a specific resource.

In the past we had a limited amount of options, and often had to 'roll our own' security framework to implement such functionality. Of course there was always the option of purchasing a product that provided a security framework, such as Microsoft's Site Server or Commerce Server 2000 (which not only handle security, personalization, and customization, but also content management). Purchasing such a product could mean spending considerable sums of money (and a lower return on investment), more administration and maintenance needs, and more hardware.

An ideal solution is to have a framework - such as the ASP.NET Framework - that has a built-in security framework.

ASP.NET and the .NET Framework work in conjunction with IIS to provide an infrastructure for web application security. The obvious advantage to this is that we no longer have to write our own security framework: we can use features of the built-in .NET security framework, which has been thoroughly tested by Microsoft and a large beta testing group, and has proved to be a viable solution for providing web application security.

The .NET security framework includes classes for handling authentication, authorization, role-based authorization, impersonation, cryptography, and code-access security, and a basic framework for building custom security solutions, which may either rely on the Windows security framework, or be entirely separate from it.

This chapter is intended as an introduction to the .NET security framework - essentially a roadmap to the security framework. In later chapters, we will dig deeper into each of the topics covered in this chapter, but here, we will briefly investigate the following topics:

Q The key features of the ASP.NET security framework

Q Authentication and authorization

Q The .NET authentication providers

Q Identities and principals within the security context

Q How authentication modules work

Q How authorization modules work

Although this chapter is intended as a brief overview of the main aspects of .NET security, you might find it useful as a reference later in the book.

ASP.NET Security Processes

The ASP.NET security framework provides the necessary functionality for several key security processes, including authentication, authorization, impersonation, and encryption. The purpose of this book is to focus on web application security in terms of authentication and authorization, so in this chapter we will be looking at these three critical processes:

Q Authentication - Who goes there? What is the identity of the user that is accessing our site?

Q Authorization - What is your clearance level? Is the user who is accessing our site authorized to use the resource they are requesting?

Q Impersonation - Who are you pretending to be? Should the user be given access to the resource using their identity, or the identity of the ASP.NET process, or some other user account?

Let's take a look at each of these in turn.

Authentication

Authentication is the process of discovering a user's identity, and determining the authenticity of this identity. This is analogous to checking in at the conference registration area: you provide some credentials to prove your identity (usually a driver's license or a passport). Once your identity is known, you are issued a conference badge that you carry with you when you are at the conference. Anyone you meet can tell your identity by looking at your badge, which typically contains the basic identity information required, such as your first and last name, and possibly the name of the company you work for. This is authentication: once your identity is established, you are given a token that identifies you so that everywhere you go within a particular area, your identity is known.

108

The ASP.NET Security Framework

In an ASP.NET application, authentication is implemented through one of four possible authentication schemas:

Q Windows Authentication

Q Forms Authentication

Q Passport Authentication

Q A custom authentication process

In each of these, the user provides credentials when logging in. Once an identity is verified, the user is given an authentication token (a digital object that proves the user's identity), such as a FormsAuthenticationTicket, placed in a cookie. This provides the user's identity information each time a resource is requested.

At this point, the only thing we have done is provide a means for allowing the application to know who each user is on each request. This works very well for personalization and customization: we can use the identity information to render user-specific messages on the web pages, or alter the appearance of the web site, depending on user preferences.

Authorization

If we take our conference analogy one step further, we can say that authorization is the process of being granted permission to a particular type of session, such as the keynote speech. At most conferences it is possible to purchase different types of access: all access, pre-conference only, or exhibition hall only. If you want to go to the keynote address at Microsoft's Professional Developer Conference, for instance, to hear what Bill Gates has to say, you must have the proper permissions (the correct conference pass). As you enter the keynote presentation hall, a member of staff will look at your conference badge. Based on the information on the badge the staff member will let you pass, or will tell you that you cannot enter.

This is authorization. Depending on information related to your identity you are either granted or denied access to the resources you ask for. This particular example is a case of role-based authorization: authorization being based on the role or group the user belongs to, not exactly who the user is. If the user is in the correct role, they are granted permission to enter. Herein lies the difference between authentication and authorization - authentication is the process of discovering a user's identity, and authorization is the process of determining the access privileges of a user.

In a web application we can provide the same type of authorization to particular resources. An online banking application provides a good example of where and why we would want to use this. If you are logging into your bank to check your account, it is critical that only you are granted access to the appropriate resources - your account information. You should not be allowed to access account information for someone else. In the application we can use the ASP.NET security framework to evaluate user identity and grant access to the resources based on either the user's specific identity (such as an account number) or the role they are in (online banking customer). We investigate the implementation of authorization in detail in Chapter 12.

1O9

Impersonation

Impersonation is the process of executing code in the context of another user identity. By default, all ASP.NET code is executed under the Domain\ASPNET user account. To execute code using another identity - to impersonate another identity - we would use the built-in impersonation capabilities of

the .NET security framework. This would enable us to specify the user account to execute the code under, such as a predetermined user account other than Domain\ASPNET, or the user account for a user who has been authenticated. We can either authenticate a user with the authentication functionality available in ASP.NET, or by using standard Windows authentication. We can then set the impersonation account depending on the credentials provided, or use a predefined user account under which to execute the code.

Impersonation also allows us to provide authentication and authorization without having to use the authentication and authorization capabilities provided by ASP.NET: we can allow Windows and IIS to manage authentication and authorization using user accounts and their related permissions.

Impersonation is typically used to provide access control, such as authorization. An application will be allowed to access any resource that the impersonated identity has access to. For example, by default the DomairAASPNET user account cannot write to the file system, nor can the user account execute transactions in Enterprise Services. Using impersonation, a user can be allowed to do both of these things by impersonating a particular Windows account, which would have permissions to do so. Thus, we can ensure that some users may be able to write to the file system, while others can only read from it, and can create user accounts that represent certain access privileges, such as User, Power User, Administrator, and so on. We can enable impersonation so that users in these roles run under these user accounts (via impersonation), rather than having to set these access privileges for each user account. This saves us the administrative overhead of managing a great many user accounts - by using impersonation we can build a system where we only have to manage a few user accounts to manage the access rights of possibly hundreds or thousands of users.

Pulling It All Together

So, how do authentication, authorization, and impersonation all work together in a web application?

When a user first comes to our web site, they are anonymous. In other words, we don't know who they are, and unless we authenticate them, we will not know who they are. When any users (whether they are authenticated or not) request a non-secure resource, they automatically have access to it: this is what it means to say that it is non-secure.

When a user requests a secure resource that requires only a known identity, several steps take place:

1 , The request is sent to the web server. Since the user identity is not known at this time, the user is directed to a login page (either a Windows login prompt, a Web Form, or a Microsoft Passport login form, depending on the authentication schema being used - we look at Windows Authentication in detail in Chapter 7, at Forms authentication in Chapter 9, and at Microsoft Passport in Chapter 8).

2 . The user provides their credentials, which are verified with the application: a case of authenticating the user.

110

The ASP.NET Security Framework

3. If the user credentials are legitimate, the user is granted access to the resource. If their credentials are not legitimate, then the user is prompted to log in with the appropriate credentials, or they are redirected to an 'access denied' web page.

When a user requests a secure resource that requires only a known identity with permission to access the resource, several steps take place:

1. The request is sent to the web server. Since the user identity is not known at this time, the user is directed to a login page (either a Windows login prompt, a Web Form for providing credentials, or a Microsoft Passport login form, depending on the authentication schema being used).

2. The user provides their credentials, which are verified with the application (authentication).

3 . The user's credentials or roles are compared to the list of allowed users or roles. If the user is in the list, then they are granted access to the resource, otherwise, access is denied.

4 . Users who have access denied are either prompted to log in with the appropriate credentials for the requested resource, or they are redirected to an 'access denied' web page.

111

In either case, impersonation occurs, if it is enabled. By default, impersonation is disabled. Impersonation can be enabled by adding an <identity> element to the root-level configuration file for the application (web.conf ig).

<configuration>

<system.web>

<identity

impersonate="true"

userName="dotnetjunies\DSeven" password="aspnet"> </identity> </system.web> </configuration>

In the <identity> element we set the impersonate attribute to true, and set the userName and password attributes to the appropriate values for the account to impersonate.

If impersonation is enabled, the credentials of the impersonated user identity are evaluated, rather than the credentials that were submitted. It is possible that these two sets of credentials are identical - a user provides their credentials and their Windows account is used in the impersonation. More usefully, it is probable that these two sets of credentials will not be identical - a user provides their credentials and a predetermined Windows account is used for impersonation.

How .NET Security Works

The ASP.NET security framework provides an object model for implementing a sophisticated security schema for a web application. Regardless of the authentication schema chosen, some factors remain the same. Users who log in to the application are granted a principal and an identity based on the credentials they have provided. A Principal object represents the current security context of the user, including the user's identity, and any roles to which they belong. An Identity object represents the current user. The Principal object is created using the Identity object (representing the user's identity) and adds additional information, such as roles, or custom application data.

112

The ASP.NET Security Framework

Representing the Security Context

An Identity object represents the authenticated user. The type of identity object depends on the type of authentication used. For instance, Widows authentication uses the Windowsldentity object, while forms authentication uses a. Formsldentity object.

A Principal object, on the other hand, represents the group or role membership of the authenticated user: in other words, the security context of the current user. While the Principal object is created automatically with Windows authentication in IIS, it is also possible to create a generic principal object, on the fly, with user and role data from a custom identity store, such as a SQL Server database. The Principal object is accessible within the current HttpContext, as the User property. The HttpContext . Current . User property returns an instance of Ipr incipal - an object that implements the IPrincipal interface.

The IPrincipal Interface

Different authentication schemas may have different requirements for the security context. By using the Principal object we can represent the current principal, or security context, in a consistent manner. The IPrincipal interface defines the basic functionality of a Principal object. All Principal objects must implement IPrincipal, which is part of the System. Security . Principal namespace.

The IPrincipal interface defines a single property (identity) and a single method (isInRole). All classes that implement the IPrincipal interface will expose these, although the Identity property and the IsInRole method may be implemented differently depending on the needs of the Principal object that is created.

Q Identity property

Gets the Ildentity of the current Principal object.

Q IsInRole (roleName As String) method

Determines whether the current Principal object belongs to the specified role.

Since the Principal object is accessible through the HttpContext . Current .User property, we can access the Identity property and IsInRole method, as shown below.

We can access the Identity property of the Principal object in the following way:

and access the IsInRole method of the Principal object like this:

if (HttpContext.Current.User.IslnRole("Admin"))

//Do something }

All implementations of the iPrincipal interface must override the Identity property and the islnRole method.

The GenericPrincipal Class

The GenericPrincipal class defines the most basic implementation of the IPrincipal interface. As the name suggests, a GenericPrincipal object represents a generic, or basic, run-of-the-mill principal, which simply defines the roles of the current user. This class is a good starting point for an authentication schema, such as a Forms authentication schema, which is an integral part of the .NET Framework, while more advanced authentication schemas may use more specific implementations of the IPrincipal interface, such as Windows authentication, which uses the WindowsPrincipal object.

Each implementation of the IPricipal interface must override the Identity property and IslnRole method. The GenericPrincipal class handles the IslnRole method by comparing role values to roles defined in a string array, while the WindowsPrincipal class will handle the IslnRole method by comparing roles values to the roles assigned to the Windows user account.

We can create an instance of the GenericPrincipal class and assign it to the

HttpContext .Current .User property for use throughout the lifetime of the current request. This is done by creating an instance of the Genericldentity class and using that to create an instance of the GenericPrincipal class.

The constructor for the GenericPrincipal class takes two arguments, the Ildentity object for the user (the Genericldentity object in this example), and a string array, which represents the roles the user is in. Once the GenericPrincipal object is created it can be used to represent the security context for the user within the current request by assigning it to the HttpContext. Current. User property.

So, a GenericPrincipal object may be created in the following way:

// Create a generic identity.

Genericldentity _userldentity = new Genericldentity("DSeven");

// Create a generic principal.

//_roles is a String array of roles from a SQL Server database GenericPrincipal _userPrincipal =

new GenericPrincipal(_userldentity, _roles);

// Set the new Principal to the Current User HttpContext.Current-User = _userPrincipal;

114