DotNetNuke Tips & Tricks

Tuesday, February 1, 2011 by Ian Robinson

Continuing the Conversation: Securing Passwords in DotNetNuke

Filed under: Tips & Tricks, DotNetNuke

A few weeks ago I came across a blog post from Mitchel Sellers about securing DotNetNuke passwords in DNN. The gist of it is as follows:

  1. You don’t want to store users passwords in a retrievable manner (store hashed value instead)
  2. DotNetNuke stores them in a retrievable manner by default
  3. You can easily change to storing the hashed value in the web.config

This is good stuff. Now nobody can actually retrieve the user’s password. Instead, a user can reset their password by entering their username. The new temporary password is sent to your email address and you can then log in using that password.

To implement you’d set the following for the AspNetSqlMembershipProvider in your web.config:

  1. enablePasswordRetrieval="false"
  2. enablePasswordReset="true"

Okay, we’re getting better. But, if you think about this situation for a second, as a commenter on Mitchel’s blog did, if you know someone’s username, you can reset their password. That doesn’t sound too good. Well, let’s take this a step further and add the notion of a security question / answer into the picture by setting requiresQuestionAndAnswer="true" in the web.config as well.

If you enable the security question functionality, you’ve just alleviated the aforementioned unwanted easy-reset issue by requiring two pieces of information to reset a password: your username and your security answer. This is about as good as we can get in DNN, which is a lot better than what ships out of the box.

There is also one more improvement to be made, and that is to remove the user's password altogether from emails sent by DNN. For some reason the password, if the various email body fields are left as their default templates, is still sent in plain text to the user. Let’s not do that if we don’t have to – which is in every case except for that of the password reset.

So, ideally when we set up a new DNN site, we take the following measures to ensure the highest security of our user’s passwords.

  1. Set up DNN file system / database/ IIS as usual
    1. Set password retrieval to false in web.config
    2. Set password to store hashed value web.config
    3. Perform dnn install as usual
  2. After DNN Install is completed (initial portal creation FAILS if this is enabled)
    1. Change enable security question / answer to true in web.config
    2. requiresQuestionAndAnswer="true"
  3. Edit the portal registration email to remove the password field from the email.
    1. Go to GlobalResources file for portal and remove four [Membership:Password] references (be sure not to remove it from the password reminder, which sends you the new random generated password)
      1. EMAIL_USER_REGISTRATION_PRIVATE_BODY.Text
      2. EMAIL_USER_REGISTRATION_PUBLIC_BODY.Text
      3. EMAIL_USER_REGISTRATION_VERIFIED_BODY.Text
      4. EMAIL_USER_UPDATED_OWN_PASSWORD_BODY.Text

Isn’t there always room for improvement? Sure. While I think this approach is preferable to the default approach, there are some items that I think aren’t exactly desirable about the end result:

  1. It generates crazy passwords (SW;.;mBD0++Fuc is a good example). Hopefully your user base is comfortable copying and pasting their password.
  2. It still sends an email with your password in plain text
  3. Doesn’t prompt you to change your password on next login

Hopefully this post gave you some additional insight into the whole “password security in DNN” conversation or at least got you thinking about it. Also, if you have any thoughts or any variations/improvements please let me know.

Comments

blog comments powered by Disqus