I recently posted about an update to my WebPageSecurity module project to the newly named SecuritySwitch. One of the best ways to ramp up coding on the project again is to get it into a public code repository.

Get with Git?

I thought about using Git on GitHub, but I want to get moving on this and that would not be the case if I had to fumble through learning Git now. Although, I do really like the concept of a distributed version control system (DVCS). Instead, I will stick with Subversion (SVN) for now.

Google Code

That lands the project in the capable arms of Google Code, which I find to be a very nice new home for SecuritySwitch. I will likely have a dedicated page here on GeekFreeq for SecuritySwitch that refers visitors to the project on Google Code, and/or I will just pipe updates from the project site here via RSS.

Anyway, this is the first stage of a “grown-up” SecuritySwitch.

After a bit of a struggle supporting my WebPageSecurity module on Code Project, I’ve decided to put some quality effort into the project in the very near future. One of the first things that needed attention was the name.

What’s in a Name?

Could I have named it something more generic all those years ago? Perhaps, but not likely. After a few minutes of running through some of the key nouns and verbs that describe the project’s purpose, it will now be known as SecuritySwitch.

Educational Value vs. Quality Functionality

Another change to the project will be the maintenance of the dual source code languages. Since I originally started the module, a distinct project for C# and VB.NET have been maintained. While this was great for the educational aspect of the article and accompanying code, it is not ideal for a quality “product”.

After some consideration, I decided to drop the VB.NET version of the source code in favor of a single project written in C#. An immediate benefit to the community of this decision is faster releases.

What’s Next?

All of this change should be balanced with something to make it all worth while. I intend on stopping development on the 2.x version of the module for .NET 1.1 where it is now. Of course, I’ll fix any bugs, but no new features will likely be added. Version 3.x for .NET 2.0 will continue until version 4.0. That’s when I will add some of the new features in the queue and enable full support for ASP.NET MVC as well.

Keep checking back for more progress on this project.

ASP.NET Login Control

So, you’ve set the timeout value for forms authentication to a fairly large value, yet checking the “remember me” check box on the Login control still does not persist your users’ authentication, even after a fairly short period of inactivity.

<system.web>
    ...
    <authentication mode="Forms">
        <forms timeout="10080"/>
    </authentication>
    ...
</system.web>

Don’t spend hours trying to figure out why this, seemingly, basic functionality doesn’t perform as it should. The solution to this problem is very simple, albeit somewhat obscure.

Encryption is the Key

To make the “remember me” check box actually obey your users when they check it, you need to ensure that a static machine key is added to your website’s web.config file. That’s it! Really.

<system.web>
    ...
    <machineKey
        validationKey="xxxxxxxxx"
        decryptionKey="xxx"
        validation="SHA1" decryption="AES"/>
    ...
</system.web>

Generate Random Keys

Generate your own keys by using one of the machineKey generator websites available. After using a generator, copy and paste the machineKey element inside the system.web element of your web.config.

The “remember me” option for authentication should start working as expected.

Why this Works

When a user authenticates on an ASP.NET website with forms authentication enabled, an authentication ticket is generated for that user. This ticket is then stored inside a cookie in the user’s browser. The cookie’s purpose is to allow the forms authentication system to recognize subsequent requests by the same user as valid/authenticated.

Of course, this functionality works without issue even before the solution above. When a user leaves the “remember me” box unchecked, a session cookie is stored in their browser. Checking that box, sends a persistent cookie back to the browser instead. This persistent cookie is set to expire based on the timeout value mentioned earlier (i.e. it expires approximately timeout minutes from the current date/time). The persistent cookie is also created without issue. A quick look at your cookies during a test should prove this.

So, if the persistent cookie is getting created properly, why are users being forced to login again after only short periods of inactivity? Well, the authentication ticket is encrypted before being sent to the browser as a cookie. This is done to secure the details of the ticket and prevent tampering. However, the ticket must be decrypted by the forms authentication system on each request that follows.

Process Recycling

When the ASP.NET process recycles, the website’s validation and decryption keys may be randomly re-generated. In fact, the default behavior is to auto-generated these keys per application. If the keys are changed, those tickets cannot be decrypted. When the forms authentication system fails to decrypt a ticket from the user’s cookie, it sends them along to the login page for validation. No amount of checking the “remember me” box will help this situation; specifying your own keys in web.config will.

Causes of Process Recycling

There are a number of causes for the ASP.NET process getting recycled. Here just a few.

• IIS determines certain conditions were met
• any change in the bin directory of the website
• changes to the physical path of the virtual application or website
• a sub-directory of the website is deleted
• changes to Global.asax, web.config, or machine.config
• policy changes
• the count threshold of re-compilations is exceeded (numRecompilesBeforeAppRestart on the compilation element)

If your website is hosted on a shared server, odds are the process for your application will get recycled more often than on a dedicated server. Hosts set the thresholds for recycling pretty low for shared hosing servers to account for poor programming.

Final Recommendations

I almost always recommend that one of the first things a developer does with a new ASP.NET website is generate a random machineKey and add to the web.config. This will likely save you many headaches in the future. By the way, this step is absolutely necessary for Web farms/gardens.

Well, I am finally setting out to write the next version of the web page security module. I have quite a list of features requested by its many users. The fact is, I’ve been wanting to write the new version for nearly 2 years now. I have an idea that will make this thing so much more usable that I’m beginning to doubt its efficiency. So, before I begin putting too much effort into it, I will be running some tests, like a responsible programmer.

I suspect the new method I have in mind will be a bit more CPU-intensive. The problem is, I have no idea how much more CPU I can expect the algorithm to use. I’ll see how my tests go, beginning tonight. If the metrics show an acceptable increase in CPU (I’ll have to decide what is acceptable), I will begin coding the new version this week.

Stay tuned.