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.
This post has been cross-posted from my Personal Blog