BenTasker.co.uk

ExternalResources is a core plugin, it allows the system administrator to point references to some (or all) static resources to another server (on an individual basis, or all-in-one). This allows for parallel downloading of resources, giving a faster page load. Where the Google hosted JQuery libraries are used, this can greatly improve load times.

The only file not supported is info.php as the keyfile needs to reside on the same domain as the rest of PHPCredLocker.

Plugin Configuration

The configuration file contains two key options

• active - Is the plugin enabled?
• url - The main resources path to use, this allows all files (except info.php) to be automatically redirected to another URL. Each file's path will be appended onto the end

Additional configuration

It's also possible to override on a per-resource basis: To load JQuery from googlecode, set the following.

$this->js->jquery->url = 'https://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js';

Essentially, the url parameter overrides all other settings (except disabled). You can set any of the following

• url - A full url to the resource. Takes precedence over all other settings
• path - Any directories within the resources dir (for example, bootstrap CSS is bootstrap/css/)
• fname - The filename to load (.js will be appended automatically)
• forcemin - Force use of minimal code, takes one of three options - false, ".min","". The first disables the setting, the second forces the fname to be followed by .min and the final ensures that .min will never be added, regardless of the main system config

Supported Resources

Resources must be specified by internal name, the following are used in PHPCredLocker

• css->bootstrap
• css->bootstrapresponsive
• css->jquerytooltip
• js->jquery
• js->bootstrap
• js->jquerytooltip
• js->main
• js->base64

Each can be overriden in the plugin config in the manner specified above

Password storage can be a sensitive business, but no matter whether you're using PHPCredlocker or KeePassX, dedicated hardware is best. The more isolated your password storage solution, the less likely it is that unauthorised access can be obtained.

Of course, dedicated hardware can quickly become expensive. Whilst it might be ideal in terms of security, who can afford to Colo a server just to store their passwords? A VPS is a trade-off - anyone with access to the hypervisor could potentially grab your encryption keys from memory (or the back-end storage).

To try and reduce the cost, whilst maintaining the security ideal of having dedicated hardware, I set out to get PHPCredlocker running on a Raspberry Pi.

This documentation details how to build the system, a Raspberry Pi Model B+ was used, but the B should be fine too

 This documentation details how to install PHPCredLocker, but there are a few pre-requisites

• MySQL (with an empty database already created)
• PHP > 5.2 (5.3 recommended as you can use OpenSSL instead of MCrypt)
• SSL certificate installed (optional, but highly recommended)

So long as you satisfy these requirements, you should be ready to install. Grab PHPCredLocker from GitHub. 

For a little while now, I've been working on a small PHP based project designed to store passwords securely. After a lot of testing, bug-hunting and fixing, PHPCredLocker has reached version 1.

Designed to prefer security over convenience, the system takes every step it can to protect stored credentials. Depending on the version of PHP you are running, passwords will be encrypted with either OpenSSL or MCrypt. A different key is used for each credential type (think FTP password vs Joomla password) and the database has been designed to be as unhelpful as possible to any miscreant who should manage to get a database dump.

I'm not an interface designer, so the template is very basic, but PHPCredLocker has been designed so that you can adjust and override as necessary (modules and views can be overridden, and templates are easy to create).

 A minor Information Disclosure Vulnerability exists in PHPCredlocker versions earlier that 1.16.

There are a few steps you should take following installation of PHPCredLocker, though only one that you have to take. All are, however, strongly recommended;

• Create Credential Types
• Backup Encryption Keys
• Set up User Groups
• Create a non-privileged user
• Set up a Cron Job

Given the sensitivity of the data inherent in PHPCredLocker's intended purpose, security has been given priority over any other consideration. If something is convenient, but lowers security it's not generally been implemented.

A number of potential attack vectors have been identified and measures put in place to mitigate the risk of such an attack, these are

• Authentication Attempts (Brute-forcing of logins etc.)
• Database retrieval (SQL injection etc)
• User Session Hijacking
• Direct Script Access
• Cross-Site Scripting (XSS)
• User Error

This documentation details the measures put in place to mitigate each of these risks.

I occasionally receive emails from people who have come across PHPCredlocker, and the question is usually the same - "Why are you storing passwords using reversible encryption?". Most emails are polite, some not so much, but they all have one thing in common - assuming that a commonly stated fact applies to all scenarios, and failing to apply a bit of simple logic that would tell them the answer - because that's the only way the system would work.

In this post, we'll be briefly looking at some of the ways in which you can store credentials, and which of them are appropriate to use (and when), in the context of building an application (web or otherwise).

Version 1.16 of PHPCredlocker has been released and can be obtained from https://github.com/bentasker/PHPCredLocker