Blogs

Securing a DotNetNuke Installation - Passwords

07 Oct

A while back I released a tool called Secure My Install that was designed to help people take existing DotNetNuke sites and change the way that they store passwords to use a more secure process.  Many people have used that module successfully to convert their sites, however, I never took the time to share the few small steps that are needed to simply "secure" your site as soon as you set it up so that you can avoid all of the hassle in the beginning.  In this post I'll walk through the simple process of changing your configuration to go from Encrypted Passwords to Hashed passwords and a bit of detail as to "why" you want to make the change.

Why Hashed Instead of Encrypted?

This is a pretty common question that I get from people and the short, simple answer is with regards to how the passwords can be used.  If you have Encrypted passwords, it is possible to retrieve the users current password and e-mail it to them.  It is equally as easy for any custom module to read the passwords of user accounts with a simple API call.

Hashing the passwords uses a forward-only method to store the passwords in a secure pattern, and when users login the same hashing process is used to validate the password, rather than decrypting the password and comparing it.  Additionally when hashed password resets from the core will send users a new password, which helps to reduce the risk exposed by sending passwords via e-mail in that at least you are not potentially giving away a users "common" password.

Where Is This Configured?

The configuration of the Membership system is done in the web.config, and a default DotNetNuke configuration section looks like this.

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

The property we are concerned with is the "passwordFormat" field as well as the "enablePasswordRetrieval" property.  We need to be concerned with both, as it isn't possible to 'retreive' your password when they are hashed, so failing to change both properties will result in errors.

How/When to Make the Change

Now, on the surface this looks like a really simple change, update two values, and we are done, right?  Well it isn't quite so easy as there are a number of things you need to look at, so I'll discuss the actual change and situations to consider.

The Change

For all scenarios the changes are the same, enablePasswordRetrieval should be set to false and passwordFormat should be set to "Hashed".  As with any change of this nature, be sure to take a full site and database backup, just in case it doesn't workout as planned.

New Installs - Before Installation

When working with a new install, if you make the changes noted above BEFORE you run the install wizard, you will have a portal setup from the beginning with the proper configuration.  This way is the most preferred as it is simple, quick, and doesn't expose you to any risks at all.  Once the portal is installed, simply use as you would normally.

New Installs - Limited User Base

If you have a newer installation but don't yet have a large number of users on the system you can still make the change, your existing users will be able to login to the portal, but their passwords will forever be in the "Encrypted" state.  (Per my testing).  Once you make the change, it is recommended that you create "different" users for each of these user accounts, which will keep all users secure, and all users with the same password format.  You can simply delete the old user accounts.

Now, as you can imagine this is not an ideal situation, so doing it before you install is the best option overall

Existing Installs - Large User Base

This conversion requires a lot more effort to change and coordinate.  I have written a module that does this, but am working through issues on DNN 5.5.x and later where it isn't working as it should.  Regardless, a more manual process is needed to temporarily decrypt the passwords, then one-by-one reset the user passwords back to the same thing, just hashed this time around. 

Conclusion

I hope that you find this helpful.  Keeping user information secure is a very important task, and this is just one way that we can help keep things secure.

tags: DNN Administration, DNN Install/Upgrade, Quick Tips
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.