Keeping User Passwords Secure in DotNetNuke 

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.

Posted by Mitchel on Friday, December 31, 2010
 

Comments

This solves password storage, but how do you secure the recovery method? By default DNN sends the password (old or the new one from above) in a plain text email to the recipient. Is there anyway to extend the security in DNN to do like other sites do and send the user a link in email to recover/reset thier password instead of emailing it in plain text?

By Robb Bryn on Monday, January 03, 2011 at 1:59 PM

Robb,

If you make the above changes the e-mail that is sent will only contain a temporary password, as DNN will no longer be able to get at the old password.

By mitchel.sellers@gmail.com on Monday, January 03, 2011 at 2:20 PM

You said the new password is a temporary password. Does this mean that the users is forced to change their password the next time they log on?

One possible abuse with this change is that any user can reset any other users password if they know their username.

So if you had the username "msellers" on my DNN site and I had "retrievePassword" set to false. I could just enter your username and generate a new password for you whenever I wanted to and there wouldn't be any way to track me.

Sending a "click this link to reset your password" email is probably the best way to handle this right now. Any idea when this functionality is coming in DNN?

By Scott Koon on Tuesday, January 04, 2011 at 10:32 PM

Scott,

Good point....

No clue about DNN changes. I've been tempted to write my own module for this, as i have in the past. BUT the only tricky part is that there isn't a "provider" way to actually swap it out.

By mitchel.sellers@gmail.com on Tuesday, January 04, 2011 at 10:34 PM

Mitch & Scott,

I think the most secure option we have right now is to implement the recommendations that Mitch highlighted, as well as setting requiresQuestionAndAnswer to true. This generates a UI for the "reset password" functionality that requires you to enter your security answer in order to reset the password. Of course if someone doesn't remember their security answer they would need to contact an admin - but as far as security goes - probably the best bet.

Ian

By Ian Robinson on Wednesday, January 05, 2011 at 11:22 PM

Ian,

I'd agree with one note. At least as far as I know, that option will cause portal creation to break, and is not something that you want to enable if you have an existing user base either.

But from a fresh start, a great recommendation as well

By mitchel.sellers@gmail.com on Wednesday, January 05, 2011 at 11:25 PM

Mitch,

Yep - you actually have to turn that option on after you create the first portal even - otherwise the installation wizard fails. Pretty sweet huh? My other issue with it is the completely gnarly passwords that get generated when you reset your password - if your user base doesn't do copy/paste in their sleep they may freak out a little bit.

Ian

By Ian Robinson on Thursday, January 06, 2011 at 9:45 AM

This leads me more and more to finding a way to roll out my implementation of this. I have built a few custom implementations that work well, but they require a core modification to swap the hyperlink.....

By mitchel.sellers@gmail.com on Thursday, January 06, 2011 at 9:48 AM

Comments from the following blog entry: Continuing the Conversation: Securing Passwords in DotNetNuke, located at: http://dnngallery.com/blog/id/247/continuing-the-conversation-securing-passwords-in-dotnetnuke

By Showcase DotNetNuke Sites at dnnGallery on Tuesday, February 01, 2011 at 7:56 PM

This issue has been brought up from time to time for a long while! Something needs to be done to bring DNN up to speed with the rest of the world in this area.
The solution of a password sent in email is just not acceptable in this era.
Thanks Mitch for this article! Certainly makes us think about the risk!

By Penny on Friday, February 04, 2011 at 1:34 PM

In new installation of version 05.06.02 (144) I tried changing from Encrypted to Hashed. At that point I could not log into the site. I would enter ad username/pw and would be returned to the home page (no error message). Only when I changed back would I get in.

What am I missing?

Thanks, Matthew

By Matthew Hile on Monday, April 18, 2011 at 1:56 PM

Once the site is setup, it is a MUCH more involved process to change. I have a module that can do it, but you have to be VERY careful!

By mitchel.sellers@gmail.com on Monday, April 18, 2011 at 1:57 PM

Hi,

I do have to say that when you enable 'requiresUniqueEmai=true' to make sure your DNN is more secure for registration there is an issue.

When you delete a user nobody, not even the same user, can register himself again with the same emailaddress because the address still exists in the dbo.aspnet_Membership table. Only when you delete the record or change the email in that record the issue is fixed.

When you use requiresUniqueEmai=true and delete a user you shuold be able to register again with that same emailaddress.

Regards,
Ely

By Ely on Wednesday, May 18, 2011 at 2:17 AM

This is a very odd design decision on behalf on DNN, particularly when the ASP.NET membership provider hashes passwords by default. It has taken someone to make a conscious decision that it's ok to symmetrically encrypt passwords then to email them around in plain text (inevitably the catalyst for the decision). Whilst it's easily changed, we all know the propensity for people to run with defaults and why there's value in convention over configuration. Hopefully we'll see a different approach in future releases.

Troy Hunt
MVP - Developer Security

By Troy Hunt on Tuesday, October 11, 2011 at 1:13 AM

Name (required)

Email (required)

Website

CAPTCHA image
Enter the code shown above:

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.

Friend of RedGate

www.datasprings.com - DotNetNuke Modules ICG Hosting

Click here for advertising information.

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.