Securing an ASP.Net application...

 1<configuration>
 2<system.web>
 3<authentication mode="Forms">
 4<forms loginurl="login.aspx" name=".AUTHCOOKIE" protection="All"></forms>
 5</authentication>
 6<machinekey decryption="" key="Autogenerate" validation"sha1"="" validationkey="Autogenerate"></machinekey>
 7<authorization>
 8<deny users="?"></deny>
 9<authorization>
10</authorization></authorization></system.web>
11</configuration>

  1<forms> element, as follows: 
  2
  3<credentials passwordformat="”Clear”">
  4<user name="”Chris”" password="”Moniker”"></user>
  5<user name="”Maria”" password="”Petersburg”"></user>
  6</credentials>  
  7---  
  8Using this method means there is very little coding for the developer to undertake due to the support provided by the .NET Framework, as we shall see a little later when we revisit this method. 
  9
 10Note also the passwordFormat attribute is required, and can be one of the following values: 
 11
 12**Clear**   
 13Passwords are stored in clear text. The user password is compared directly to this value without further transformation. 
 14
 15**MD5**   
 16Passwords are stored using a Message Digest 5 (MD5) hash digest. When credentials are validated, the user password is hashed using the MD5 algorithm and compared for equality with this value. The clear-text password is never stored or compared when using this value. This algorithm produces better performance than SHA1. 
 17
 18**SHA1**   
 19Passwords are stored using the SHA1 hash digest. When credentials are validated, the user password is hashed using the SHA1 algorithm and compared for equality with this value. The clear-text password is never stored or compared when using this value. Use this algorithm for best security. 
 20
 21What is hashing? Hash algorithms map binary values of an arbitrary length to small binary values of a fixed length, known as hash values. A hash value is a unique and extremely compact numerical representation of a piece of data. The hash size for the SHA1 algorithm is 160 bits. SHA1 is more secure than the alternate MD5 algorithm, at the expense of performance. 
 22
 23At this time there is no ASP.Net tool for creating hashed passwords for insertion into configuration files. However, there are classes and methods that make it easy for you to create them programmatically, in particular the FormsAuthentication class. It’s HashPasswordForStoringInConfigFile method can do the hashing. At a lower level, you can use the System.Security.Cryptography classes, as well. We'll be looking at the former method later in this article. 
 24
 25The flexibility of the authentication provider for Forms Authentication continues as we can select SQLServer as our data source though the developer needs then to write bespoke code for validating user credentials against the database. Typically you will then have a registration page to allow users to register their login details which will then be stored in SQLServer for use when the user then returns to a protected resource and is redirected to the login page by the forms authentication, assuming the corresponding cookie is not still in existence. 
 26
 27This raises a further feature - we would want to give all users access to the registration page so that they may register but other resources should be protected. Additionally, there may be a third level of security, for example an admin page to list all users registered with the system. In such a situation we can have multiple system.web sections in our web.config file to support the different levels of authorization, as follows: 
 28
 29<configuration>
 30<system.web>
 31<authentication mode="Forms">
 32<forms loginurl="login.aspx" name=".AUTHCOOKIE" protection="All"></forms>
 33</authentication>
 34<machinekey decryption="" key="Autogenerate" validation"sha1"="" validationkey="Autogenerate"></machinekey>
 35<authorization>
 36<deny users="?"></deny>
 37<authorization>
 38</authorization></authorization></system.web>
 39<location path="register.aspx">
 40<system.web>
 41<authorization>
 42<allow users="*,?"></allow>
 43</authorization>
 44</system.web>
 45</location>
 46<location path="admin.aspx">
 47<system.web>
 48<authorization>
 49<allow users="admin "></allow>
 50<deny users="*"></deny>
 51</authorization>
 52</system.web>
 53</location>
 54</configuration>  
 55---  
 56Thus only the admin user can access admin.aspx, whilst all users can access register.aspx so if they don't have an account already they can register for one. Any other resource request will cause redirection to login.aspx, if a valid authentication cookie by the name of .AUTHCOOKIE isn't detected within the request. On the login page you would provide a link to register.aspx for users who require the facility. 
 57
 58Alternatively you can have multiple web.config files, with that for a sub-directory overriding that for the application a whole, an approach that we shall implement later for completeness. 
 59
 60Finally, you may also perform forms authentication in ASP.Net against a Web Service, which we won’t consider any further as this could form an article in itself, and against Microsoft Passport. Passport uses standard web technologies such as SSL, cookies and Javascript and uses strong symmetric key encryption using Triple DES (3DES) to deliver a single sign in service where a user can register once and then has access to any passport enabled site. 
 61
 62####  Consideration of suitability 
 63
 64Forms based authentication is a flexible mechanism supporting a variety of techniques of various levels of security. Some of the available techniques may be secure enough for implementation if extended appropriately. Some of the techniques are more suited to our problem domain than others, as we’ll discuss shortly. 
 65
 66In terms of specific authorities: 
 67
 68Passport is most appropriately utilized where your site will be used in conjunction with other Passport enabled sites and where you do not wish to maintain your own user credentials data source. This is not the case in our chosen problem domain where Passport would both be overkill and inappropriate. 
 69
 70SQLServer would be the correct solution for the most common web site scenario where you have many users visiting a site where the majority of content is protected. Then an automated registration facility is the obvious solution with a configuration as per the web.config file just introduced. In our chosen problem domain we have stated that we potentially have only a handful of users accounts accessing a small portion of the application functionality and hence SQLServer is not necessarily the best solution, though is perfectly viable. 
 71
 72Use of the credentials section of the forms element of web.config or a simple text/ XML file would seem most suitable for this problem domain. The extra security and simplicity of implementation offered by the former makes this the method of choice. 
 73
 74###  Authorization via ASP.Net 
 75
 76As discussed earlier this is the second stage of gaining access to a site: determining whether an authenticated user should be permitted access to a requested resource. 
 77
 78File authorization utilizes windows security services access control lists (ACLs) – using the authorized identity to do so. Further, ASP.Net allows further refinement based on the URL requested, as you may have recognized in the examples already introduced, as well as the HTTP request method attempted via the verb attribute, valid values of which are: GET, POST, HEAD or DEBUG. I can't think of many occasions in which you'd want to use this feature but you may have other ideas! You may also refer to windows roles as well as named users. 
 79
 80A few examples to clarify: 
 81
 82<authorization>
 83<allow users="”Chris”"></allow>
 84<deny users="”Chris”"></deny>
 85<deny users="”*”"></deny>
 86</authorization>  
 87---  
 88You might logically think this would deny all users access. In fact Chris still has access, as when ASP.Net finds a conflict such as this it will use the earlier declaration.  <authorization>
 89<allow roles="”Administrators”"></allow>
 90<deny users="”*”"></deny>
 91</authorization>
 92<authorization>
 93<allow post”="" verbs="”GET,"></allow>
 94</authorization>  
 95---  
 96  
 97###  Impersonation 
 98
 99Impersonation is the concept whereby an application executes under the context of the identity of the client that is accessing the application. This is achieved by using the access token provided by IIS. You may well know that by default the ASPNET account is used to access ASP.Net resources via the Aspnet_wp.exe process. This, by necessity, has a little more power than the standard guest account for Internet access, IUSR, but not much more. Sometimes you may wish to use a more powerful account to access system resources that your application needs. This may be achieved via impersonation as follows:  <system.web>
100<identity impersonate="”true”"></identity>
101</system.web>  
102---  
103or you may specify a particular account:  <system.web>
104<identity impersonate="”false”" password="”password”" username="”domain\sullyc”"></identity>
105</system.web>  
106---  
107Of course you will need to provide the involved accounts with the necessary access rights to achieve the goals of the application. Note also that if you don’t remove IUSR from the ACLs then this is the account that will be used – this is unlikely to meet your needs as this is a less powerful account than ASPNET. 
108
109ASP.Net will only impersonate during the request handler - tasks such as executing the compiler and reading configuration data occur as the default process account. This is configurable via the <processmodel> section of your system configuration file (machine.config). Care should be taken however not to use an inappropriate (too powerful) account which exposes your system to the threat of attacks. 
110
111The situation is further complicated by extra features available in IIS6 … but we’ll leave those for another article perhaps as the situation is complex enough! 
112
113Let’s move onto developing a login solution for our chosen problem domain. 
114
115###  Our Chosen Authentication Method – how secure is it? 
116
117We've chosen forms based authentication utilizing the web.config file as our authority. How secure is the mechanism involved? Let's consider this by examining the process in a little more detail. As a reminder, our application scenario is one of a web site where we've put content which we want to enable restricted access to in a sub-directory named secure. We have configured our web.config files to restrict access to the secure sub-directory, as described above. We deny access to the anonymous users (i.e. unauthenticated users) to the secure sub-directory: 
118
119<authorization>
120<deny users="?"></deny>
121</authorization>  
122---  
123If someone requests a file in the secure sub-directory then ASP.Net URL authentication kicks in - ASP.Net checks to see if a valid authentication cookie is attached to the request. If the cookie exists, ASP.Net decrypts it, validates it to ensure it hasn't been tampered with, and extracts identity information that it assigns to the current request. Encryption and validation can be turned off but are enabled by default. If the cookie doesn't exist, ASP.Net redirects the request to the login page. If the login is successful, the authentication cookie is created and passed to the user’s browser. This can be configured to be a permanent cookie or a session-based cookie. Possibly slightly more secure is a session-based cookie where the cookie is destroyed when the user leaves the application or the session times out. This prevents someone else accessing the application from the user’s client machine without having to login. 
124
125Given the above scenario we have two security issues for further consideration: 
126
127  1. How secure is the cookie based access? Note above that encryption and validation are used by default. How secure are these in reality? 
128
129Validation works exactly the same for authentication cookies as it does for view state: the <machinekey> element's validationKey is appended to the cookie, the resulting value is hashed, and the hash is appended to the cookie. When the cookie is returned in a request, ASP.Net verifies that it wasn't tampered with by rehashing the cookie and comparing the new hash to the one accompanying the cookie. Encryption works by encrypting the cookie, hash value and all with <machinekey>'s decryptionKey attribute. Validation consumes less CPU time than encryption and prevents tampering. It does not, however, prevent someone from intercepting an authentication cookie and reading its contents. 
130
131Encrypted cookies can't be read or altered, but they can be stolen and used illicitly. Time-outs are the only protection a cookie offers against replay attacks, and they apply to session cookies only. The most reliable way to prevent someone from spoofing your site with a stolen authentication cookie is to use an encrypted communications link (HTTPS). Talking of which, this is one situation when you might want to turn off both encryption and validation. There is little point encrypting the communication again if you are already using HTTPS. 
132
133Whilst on the subject of cookies, remember also that cookie support can be turned off via the client browser. This should also be borne in mind when designing your application. 
134
135  2. How secure is the logging on procedure to a web form? Does it use clear text username and password transmission that could be susceptible to observation, capture and subsequent misuse? 
136
137Yes is the answer. Thus if you want a secure solution but don't want the overhead of encrypting communications to all parts of your site, consider at least submitting user names and passwords over HTTPS, this assuming your web hosting service provides this. 
138
139
140
141
142To reiterate, the forms security model allows us to configure keys to use for encryption and decryption of forms authentication cookie data. Here we have a problem - this only encrypts the cookie data - the initial login screen data, i.e. email / password is not encrypted. We are using standard HTTP transmitting data in clear text which is susceptible to interception. The only way around this is to go to HTTPS and a secure communication channel. 
143
144Which perhaps begs the question – what is the point of encrypting the cookie data if our access is susceptible anyway if we are using an unsecured communication channel? Well, if we enable cookie authentication when we first login then subsequent interaction with the server will be more secure. After that initial login a malicious attacker could not easily gain our login details and gain access to the site simply by examining the contents of the packets of information passed to and from the web server. However, note the earlier comments on cookie theft. It is important to understand these concepts and the impact our decisions have on the overall security of our application data. 
145
146It is perhaps unsurprising given the above that for the most secure applications: 
147
148  1. A secure HTTPS channel is used whenever dealing with username/ password/ related data. 
149  2. Cookies are not exclusively relied upon: often though recall of certain information is cookie based important transactions still require authorization via an encrypted password or number. 
150
151
152
153It is up to the application architect/ programmer to decide whether this level of security is appropriate to their system. 
154
155Finally, before we actually come up with some code remember that forms based security secures only ASP.Net resources. It doesn’t protect HTML files, for example. Just because you have secured a directory using web.config / ASP.Net doesn’t mean you have secured all files in that directory. To do this you could look at features available via IIS. 
156
157###  The 'Application' 
158
159Finally to the code and making our ASP.Net application as secure as possible using the facilities ASP.Net provides. Taking the above described scenario where we have a secure sub-directory the files within which we wish to protect. However, we anticipate there will only be a handful of users who will need access to the directory and hence this is a suitable problem domain to be addressed with a web.config based authority solution as earlier decided. 
160
161Starting with our web.config file. We can secure the sub-directory either via the location element, as described above, but just to demonstrate the alternative double web.config based approach, here is the web.config at the root level: 
162
163<configuration>
164<system.web>
165<authentication mode="Forms">
166<forms loginurl="login_credentials.aspx" name=".AUTHCOOKIE" protection="All">
167<credentials passwordformat="Clear">
168<user name="chris" password="password"></user>
169</credentials>
170</forms>
171</authentication>
172<machinekey decryptionkey="AutoGenerate" validation="SHA1" validationkey="AutoGenerate"></machinekey>
173<authorization>
174<allow users="*"></allow>
175</authorization>
176</system.web>
177</configuration>  
178---  
179You can see that this sets up forms based security enabling validation and encryption and specifies a credentials list of one user, currently in Cleartext format but shortly we'll see how to encrypt the password via SHA1. You'll also see that this file doesn’t actually restrict user access at all so URL based authentication will not be used at the root level of our application. However, if we extend the configuration for the secure sub-directory via an additional web.config file:  <configuration>
180<system.web>
181<authorization>
182<deny users="?"></deny>
183</authorization>
184</system.web>
185</configuration>  
186---  
187Then if a user attempts to access an ASP.Net resource in secure they will be dealt with according to the combination of directives in the web.config file and inherited from the parent web.config file, and machine.config file for that matter. 
188
189Onto the login file: you will need form fields to allow entry of username and password data. Note that security will be further improved by enforcing minimum standards on passwords (e.g. length), which can be achieved by validation controls. There is only minimal validation in the example. Note that there is no facility to request a ‘persistent cookie’ as this provides a minor security risk. It is up to you to decide whether a permanent cookie is acceptable in your application domain. 
190
191Then in the login file, login_credentials.aspx, after allowing the user to enter username and password data, in the sub executed on the server when the submit form button is clicked we validate the entered data against the web.config credentials data, achieved simply as follows: 
192
193If FormsAuthentication.Authenticate(Username.Value, UserPass.Value) Then   
194FormsAuthentication.RedirectFromLoginPage (UserName.Value, false)   
195Else   
196Msg.text="credentials not valid"   
197End If   
198---  
199Could it be any simpler? The FormsAuthentication object knows what authority it needs to validate against as this has been specified in the web.config file. If the user details match, the code proceeds to redirect back to the secured resource and also sets the cookie for the user session based on the user name entered. The parameter 'false' indicates that the cookie should not be permanently stored on the client machine. Its lifetime will be the duration of the user session by default. This can be altered if so desired. 
200
201Back to web.config to improve the security. The details are being stored unencrypted – we can encrypt them with the aforementioned HashPasswordForStoringInConfigFile of the FormsAuthentication class, achieved simply as follows: 
202
203Private Function encode(ByVal cleartext As String) As String   
204encode = FormsAuthentication.HashPasswordForStoringInConfigFile(cleartext, "SHA1")   
205Return encode   
206End Function   
207---  
208This is the key function of the encode.aspx file provided with the code download, which accepts a text string (the original password – ‘password’ in this case) and outputs a SHA1 encoded version care of the above function. 
209
210Thus, our new improved configuration section of our root web.config file becomes: 
211
212<credentials passwordformat="SHA1">
213<user name="chris" password="5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8"></user>
214</credentials>  
215---  
216To summarize the involved files:   
217Root/web.config  |  root web.config file   
218---|---  
219Root/webform1.aspx  |  test page   
220Root/login_credentials.aspx  |  login page   
221Root/encode.aspx  |  form to SHA1 encode a password for <credentials>  
222Root/secure/web.config  |  directives to override security for this sub-directory to deny anonymous access   
223Root/secure/webform1.aspx  |  test page   
224  
225###  Conclusions 
226
227We’ve looked at the new security features of ASP.Net focusing particularly on an application scenario where forms based authentication uses the credentials section of web.config, but presenting this in the context of wider security issues. 
228
229In summary you should consider forms based authentication when: 
230
231  * User names and passwords are stored somewhere other than Windows Accounts (it is possible to use forms authentication with Windows Accounts but in this case Integrated Windows authentication may well be the best choice). 
232  * You are deploying your application over the Internet and hence you need to support all browsers and client operating systems. 
233  * You want to provide your own user interface form as a logon page. 
234
235
236
237You should not consider forms based authentication when: 
238
239  * You are deploying an application on a corporate intranet and can take advantage of the more secure Integrated Windows authentication. 
240  * You are unable to perform programmatic access to verify the user name and password. 
241
242
243
244Further security considerations for forms based authentication: 
245
246  * If users are submitting passwords via the logon page, you can (should?) secure the channel using SSL to prevent passwords from being easily obtained by hackers. 
247  * If you are using cookies to maintain the identity of the user between requests, you should be aware of the potential security risk of a hacker "stealing" the user's cookie using a network-monitoring program. To ensure the site is completely secure when using cookies you must use SSL for all communications with the site. This will be an impractical restriction for most sites due to the significant performance overhead. A compromise available within ASP.Net is to have the server regenerate cookies at timed intervals. This policy of cookie expiration is designed to prevent another user from accessing the site with a stolen cookie. 
248
249
250
251Finally, different authorities are appropriate for form-based authentication for different problem domains. For our considered scenario where the number of users was limited as we were only protecting a specific administrative resource credentials / XML file based authorities are adequate. For a scenario where all site information is ‘protected’ a database authority is most likely to be the optimal solution. 
252
253###  References 
254
255ASP.Net: Tips, Tutorial and Code   
256Scott Mitchell et al.   
257Sams 
258
259.Net SDK documentation 
260
261Various online articles, in particular: 
262
263ASP.Net Security: An Introductory Guide to Building and Deploying More Secure Sites with ASP.Net and IIS -- MSDN Magazine, April 2002   
264http://msdn.microsoft.com/msdnmag/issues/02/04/ASPSec/default.aspx   
265An excellent and detailed introduction to IIS and ASP.Net security issues. 
266
267http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/authaspdotnet.asp   
268Authentication in ASP.Net: .Net Security Guidance 
269
270You may download the code here.</credentials></machinekey></machinekey></processmodel></forms>