Let’s first look at the performance overhead of using SSL. There are a couple of great questions on this subject on Stackoverflow, here and here. Older research seems to point to a reasonable amount of overhead, but a more recent interesting anecdote points to the opposite. In general, using current, modern hardware, there should be not a large impact on performance, however, for large and busy sites, it is always a good idea to include SSL in the load testing.
Pricing of SSL certificates should also not be an issue. If you are really on a low budget there are a number of free SSL providers available. This of course depends of the importance of the site you are working on, as you may not want to use a free certificate.
Now, for the topic of this post: how to set up a secure login for your DotNetNuke site. This walkthrough is largely based on a blog post by Troy Hunt, OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection. In this post Troy explains in great detail that it is not enough to just have a secure (SSL) login, but all subsequent requests also need to be secure, otherwise the authentication cookie can still be hijacked in certain situations (such as insecure WiFi connections).
Luckily, ASP.NET provides a very simple solution for this: modify the forms authentication setting in web.config to require SSL for authentication cookies. Once you do this, the authentication cookie will no longer be sent out over an insecure (HTTP) connection. This means that you can only log on to a site over an SSL connection, and once you change back to a non-SSL connection, you will be logged off automatically.
In order to set this up for your DotNetNuke site, you have to change this:
<authentication mode="Forms">
<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" />
< /authentication>
in this:
<authentication mode="Forms">
<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" requireSSL=”true” />
< /authentication>
This means that from now on, all authentication cookies will only be sent if the transport layer is secured. So hold of on making this change right away, as doing this will prevent you to log on!. First you will have to prepare DotNetNuke to work with an SSL only logon.
Step 1: Enable SSL for your website in IIS
I am not really going to explain that here, since this is a very common procedure in IIS. Seehere for more information about how to do that.
Step 2: Enable SSL for your site in DotNetNuke
DotNetNuke offers a comprehensive way to enable and enforce SSL per website (portal). For this task, it is enough that SSL is enabled for the site. In order to do that, go to Admin > Site Settings, to the Advanced tab, and open the SSL Settings section. In this section, check the option “SSL Enabled?”, and update the settings.
Step 3: Create a secure Login Page
By default the automatically generate login page (or popup) for DotNetNuke is not secure. In order to provide a secure login option, you will have to create a separate page, that has a Account Login module on it and that is marked as secure. Whilst you can create this page at every level, and give it any name, most logical would be to create this page at the root level and give it the name “Login”. Although DotNetNuke will handle everything automatically once you make every necessary adjustment, it gives me peace of mind knowing you are overwriting the automatic URL for the logon page.
In full, the new Login page needs these properties set:
- Page name: Login
- Root level (no parent page)
- Permissions: view permissions for all users (or for unauthenticated users)
- Secure: Secure flag must be set (this will ensure the page is only viewable using the HTTPS protocol, and DotNetNuke will automatically switch to HTTPS for this page)
- Finally, put an Account Login module on the page.
Step 4: Use the new login page
Without “telling” DotNetNuke to use this new Login page, it will keep using the automatic login option. The Login page is a so called special page which means that the location of this page is stored per Site and can be used by any other process in any module or extension. In order to change the special Login page, go to Admin > Site settings, and open the “Advanced Settings” tab, and select the Page Management section. In this section, at “Login Page” select your newly created Login page, and update the settings.
Step 5: enable RequireSSL
Open up the web.config file for your application, and change the Forms Authentication node to look like this:
<authentication mode="Forms">
<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" requireSSL=”true” />
< /authentication>
Caveat
There is one large caveat here. Since the Forms Authentication Cookie setting is done at the application level, in web.config, this solution assumes that you either have just one site configured in DotNetNuke, or that all sites can be secured with the SSL certificate that you applied to the IIS website. This means that potentially you would have to apply multiple SSL certificates to one IIS website.
SSL certificates are usually only valid for one domain, or for one domain and all its sub domains (the latter are so called Wild Card SSL certificates). Or you may be able to obtain a certificate for multiple unrelated domains (so called (UCC or SAN Certificates). The best solution though would be to run under Windows 2012, as this supports Server Name Indication (SNI), which allows you to apply multiple SSL certificates to one website (using different host headers). That is material for another blog post though!
Final remarks
I cannot begin to stress how important it is to secure your site for authenticated users. I love to read the blog posts by Troy Hunt, as he never ceases to amaze me how easy it is to infringe on the privacy of others, and how easy it is to break into other sites. Securing your site is just one small, but important step, towards the goal of a safer net.
Since there are a lot of SSL providers out there that even provide free SSL certificates, really no one should have a valid reason not start using one.
(this post is cross posted from my personal blog)