Securing mojoPortal

Security is a wide ranging topic that requires ongoing concern and vigilance, often requiring trade offs in terms of usability and easy maintenance. My goal in mojoPortal content management system is to provide security features that allow you to make the decisions when a tradeoff is required. Depending on the nature of the site (ranging from personal web site to banking application), the level of security required varies.

Password Encryption

It is considered more secure to store passwords in the database in encrypted format but then you can't e-mail the user's password if he forgets it, instead you have to reset it but before you reset it you need to somehow verify that it is the actual user who is requesting the help. If you are trying to troubleshoot a problem that a user is having sometimes it is helpful to be able to login as the user and see what the user sees. These kind of issues make it attractive in some scenarios not to encrypt passwords in the database. In making these decisions you have to consider the security needs of the specific site, who has physical access to the db and the potential that someone could hack into the db and steal the passwords and the nature of the consequences if security is breached.

In mojoPortal you can configure on the Admin page whether passwords are stored as encrypted or not. This is not a setting that you want to change back and forth, if you start out with no encryption then change it to require encryption you will have locked out all your exisiting users until you reset their passwords. If passwords are encrypted you will have to verify that the user requesting his password be reset is the actual user then you can login as Admin and change the user's password and let him know what it is. If you configure mojoPortal to not encrypt passwords then a feature automatically becomes available for the user to request the password be sent to the e-mail address of record.

Encrypting Communication Between the Server and the Browser

SSL encryption can be used to secure some or all content sent back and forth between the browser and the server. To use SSL, you must have a server certificate installed and configured on the server. It is possible to generate your own SSL certificate or to obtain one from a trusted Certificate Authority. Obtaining and installing an SSL certificate is beyond the scope of this document but there are plenty of resources on the web to help you with this. If you have an SSL certificate installed and configured on your server, you should set the SSLIsAvailable setting in the Web.config file to true. This will automatically cause the login, register and user profile pages to use and require SSL. Additionally, you will now see an option on the Admin page to require all pages in the site to use SSL. If you check this box, SSL will be enforced on every page in the site. If you leave the checkbox un-checked, you will see a setting on each page's page settings whether to require SSL for the page. Thus you have very granular control over which pages require encryption.

Note that if your mojoPortal installation is not a root site but is instead in a subfolder to use SSL you will also need to add this to your user.config, otherwise it will redirect incorrectly when forcing SSL.

Preventing Bogus Registration

If you want to avoid bogus email addresses being used to register in your site, you can enable the "Require E-mail Confirmation for Registration" option in the Site Settings (security tab). This will send new users an e-mail message with a link to confirm their account. They will not be able to login until the account has been confirmed.

Role Based Security

For each page in a mojoPortal web site, you can configure which roles are allowed to view or edit the page. All users are members of the "Authenticated Users" group which makes it easy to configure a page that anyone who logs in can see but anonymous users cannot see. For example I could secure the Download page this way and require every user to be logged in before being able to download if I chose to do so. Instead I want to promote use of mojoPortal so I don't configure it this way and just beg people to register. To secure the files themselves, I could use the Shared Files module rather than just using links directly to the files. See the document on the Shared Files module for more information on how it secures files.

You can create additional roles and have very granular control over which roles can view or edit any specific page. See the Roles and Permissions page for more information.