Hello,

A security researcher has contacted us to make us aware of some weaknesses in the design of our master password system.

There is no vulnerability here per se, however he/she raises some valid concerns. Essentially it boils down to us not forcing users to choose strong passwords and a lack of strong defences for brute force password guessing attempts. We can improve on what we do, and we want to provide additional advice to our users.

We want to thank Tristan Madani for providing us with a professional and detailed threat analysis.

Basic protection

We will be addressing these concerns within the next release candidate of Composr, but to be protected please ensure your master password follows these rules:

• at least 8 characters in length
• contains at least 1 upper case character
• contains at least 1 lower case character
• contains at least 1 number
• contains at least 1 symbol

Further protection

Alternatively/additionally you can temporarily remove the $SITE_INFO['master_password']='xxx'; line from your _config.php file and only put it back when you need to log into a maintenance script such as the upgrader.

To provide additional protection beyond the master password you may want to set IP-based restrictions (or temporary access blocks) to the following scripts:

• rootkit_detection.php
• upgrader.php
• uninstall.php
• data/upgrader2.php
• config_editor.php
• code_editor.php

Follows are sample access rules for an Apache .htaccess file to provide a temporary access block:
You should test these rules are working correctly after applying them.

Future Composr improvements

Changes in the next release candidate of Composr include:

1. Forcing strong passwords during the installer, and config editor
2. Not allowing the same password for the database and master password
3. Fixing an SQL injection vulnerability that only happens if you already have master access to the maintenance scripts (so it's not a serious vulnerability, as anyone who has such access already has full maintenance access)
4. Adding a delay during authentication to reduce the impact of brute force attempts (both for regular accounts and maintenance logins)
5. Adding logging for master password access (failures now will go to the error log, and all access attempts will go into the system log)