Blogs

Keeping User Passwords Secure in DotNetNuke

31 Dec

This article is being cross-posted from my business blog.

If you have been paying attention to the news in recent months you have most likely heard of a few cases where user information, such as Usernames and Passwords, have been exposed from some high visibility websites. Some of the more current leaks were with Gawker and Mozilla. For those that are unfamiliar the situation is pretty simple. These sites store user login information, usernames and passwords, that allow users access to their systems. Their systems were then breached and malicious users were able to get access to the information. Why is this something that I am blogging about in relation to DotNetNuke? Well without a bit of configuration your site could be at risk, should a malicious user get access to your system. This article will discuss a bit around how/why there is a risk and how that relates to DotNetNuke, then it will progress into an overview of the default configuration of DotNetNuke and the recommended changes to the system.

How/Why Is It A Risk

The foundational piece of risk with these exploits is the fact that the systems there were compromised stored user passwords in an encrypted fashion. Since the passwords were only encrypted it was fairly easy for the malicious users to decrypt and view the actual plain-text passwords of the user accounts. If the systems were storing information using "hashed" passwords they would be exposed to less risk as a hashing algorithm is one-way and does not allow for password retrieval.

Now, before you start to panic, this risk did require that the users get access to the servers/databases that ran the individual sites in question, but there is still a bit of question here. Do you REALLY want the ability to see what someone's password is? I know I don't want to, and I really don't want others seeing mine. Now, I'm not like some people that would demand that sites don't store passwords at all, but I am a fan of ensuring that information is properly secured.

Now the reason this is coming up on the DotNetNuke blog is that by default DotNetNuke uses a configuration that stores passwords in an Encrypted fashion which allows users to recover their passwords and can pose a risk if someone got access to the database of the site directly. The good news is that DotNetNuke does support changing this default manner and it is quite easy to do. The following sections will discuss the default configuration and the recommended changes.

Default Configuration

The out of the box configuration for DotNetNuke is not setup in the best manner to promote the security of information. The following snippet shows the default configuration of DotNetNuke. This section is found at the very bottom of the system.web node of the web.config file.

<membership 
  defaultProvider="AspNetSqlMembershipProvider" 
  userIsOnlineTimeWindow="15">
  <providers>
    <clear />
    <add name="AspNetSqlMembershipProvider" 
         type="System.Web.Security.SqlMembershipProvider" 
         connectionStringName="SiteSqlServer" 
         enablePasswordRetrieval="true" 
         enablePasswordReset="true" 
         requiresQuestionAndAnswer="false" 
         minRequiredPasswordLength="7" 
         minRequiredNonalphanumericCharacters="0" 
         requiresUniqueEmail="false" 
         passwordFormat="Encrypted" 
         applicationName="DotNetNuke" />
  </providers>
</membership>

The key elements here are the enablePasswordRetrieval and passwordFormat attributes. With enablePasswordRetrieval enabled the "Forgotten Password" functionality will return users their CURRENT password, sent via e-mail in plain text. Many users do not like this functionality. The passwordFormat option then specifies exactly how passwords are stored in the database and you can see that "Encrypted" is the default value.

Recommended Changes

To help improve the security of your installation and the data it retains we recommend that you set "enablePasswordRetrieval" to false, this will result in a new random password being sent to the user rather than their current password. The second change is to change passwordFormat to be "Hashed". The modified configuration section would look similar to the following.

<membership 
  defaultProvider="AspNetSqlMembershipProvider" 
  userIsOnlineTimeWindow="15">
  <providers>
    <clear />
    <add name="AspNetSqlMembershipProvider" 
         type="System.Web.Security.SqlMembershipProvider" 
         connectionStringName="SiteSqlServer" 
         enablePasswordRetrieval="false" 
         enablePasswordReset="true" 
         requiresQuestionAndAnswer="false" 
         minRequiredPasswordLength="7" 
         minRequiredNonalphanumericCharacters="0" 
         requiresUniqueEmail="false" 
         passwordFormat="Hashed" 
         applicationName="DotNetNuke" />
  </providers>
</membership>

We recommend making this change to all new sites as they are setup, as well as investigating changes to existing systems.

Parting Notes

With this quick fix you can improve the security of your users information as it is stored in your database and help reduce the potential for loss of data if your systems are compromised. It is important to note that the change in the web.config is a "forward only" change. So if you change this setting on an existing installation only future passwords will be stored in the new format. If you change your password it will be updated to the new format at that time. We will be working with a future post to discuss potential methods for automatically changing existing records as well. Feel free to share comments below.

tags: DNN, DNN Administration
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Connect with Mitchel

I hope the information here has been helpful. To stay connected you can also subscribe to blog updates via email, contact Mitchel about consulting services, or reach out for assistance via CodeMendor

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.