In order to do this, a asymmetric-key system is needed, such as public-key cryptography. Googling for examples of this in PHP, there doesn’t seem to be any results of this other than the php OpenSSL extension documentation, and systems that try to reinvent the wheel with their own implementations.

Using the PHP OpenSSL extension it is fairly easy to sort out a secure system for encrypting data with one key that only can be decrypted with another.

First, you need to generate your private and public keys. You can either do this yourself with the openssl command-line application:

# generate a 1024 bit rsa private key, ask for a passphrase to encrypt it and save to file
openssl genrsa -des3 -out /path/to/privatekey 1024
 
# generate the public key for the private key and save to file
openssl rsa -in /path/to/privatekey -pubout -out /path/to/publickey

or programatically using php-openssl:

// generate a 1024 bit rsa private key, returns a php resource, save to file
$privateKey = openssl_pkey_new(array(
	'private_key_bits' => 1024,
	'private_key_type' => OPENSSL_KEYTYPE_RSA,
));
openssl_pkey_export_to_file($privateKey, '/path/to/privatekey', $passphrase);
 
// get the public key $keyDetails['key'] from the private key;
$keyDetails = openssl_pkey_get_details($privateKey);
file_put_contents('/path/to/publickey', $keyDetails['key']);

Next, you can load the public key, and encrypt the data:

$pubKey = openssl_pkey_get_public('file:///path/to/publickey');
openssl_public_encrypt($sensitiveData, $encryptedData, $pubKey);
 
// store $encryptedData ...

When you need to get the sensitive data again, you can load the private key and decrypt:

// retrieve $encryptedData from storage ...
 
// load the private key and decrypt the encrypted data
$privateKey = openssl_pkey_get_private('file:///path/to/privatekey', $passphrase);
openssl_private_decrypt($encryptedData, $sensitiveData, $privateKey);

Alternatively you can use the private key to encrypt data, sign data or seal it against multiple other public keys, but that is beyond the scope of this article.

So, I have compiled the latest PHP version, 5.2.10, and put it in my own repository for easy installation. I have compiled it for CentOS 5 i386 and x86_64, and provided the source RPMS in the repo, if anyone wants to compile it for another OS or architecture.

I have also included the same php extensions I mentioned in my other article, php-mcrypt, php-mhash, php-mssql and php-tidy

To install, first you must tell rpm to accept rpm’s signed by me:

rpm --import http://repo.webtatic.com/yum/RPM-GPG-KEY-webtatic-andy

Then add the yum repository information to yum:

cd /etc/yum.repos.d/
wget http://repo.webtatic.com/yum/webtatic.repo

Now you can upgrade php by doing:

yum --enablerepo=webtatic update php

The main reason why I chose to do this rather than use Webtatic::AuthDBI is because subversion checkouts were taking twice as long. A mod_perl authentication provider, even without performing authentication (just returning OK for any login details) seems to be the speed of the whole mod_auth_mysql without even establishing a mysql connection.

This patch seems to perform just as well as mod_auth_mysql.

Check it out here: /projects/mod_auth_mysql-auth/

Basic HTTP authentication suffers from a very easy man-in-the-middle attack, where the attacker can simply reverse the base-64 encode to get the user’s password. This is preventable if switching to HTTPS, where a man-in-the-middle is not possible.

Digest HTTP authentication however uses a complex series of MD5 operations on data provided by the server and client variables. This, depending on the server implementation, can prevent the man-in-the-middle from decyphering the password, and prevent replay attacks.

Digest HTTP authentication is relatively new, but is supported fully in all the latest browsers. Internet Explorer 6 however does not support the standard correctly, but there is an Apache server workaround to allow it.

I have written a mod_perl module which will provide a database backend to this method, called Webtatic::AuthDBI. It is similar to that of mod_auth_mysql, which only supports Basic auth.

I have published a project page for this at /projects/webtaticauthdbi/. It is free to use, and uses the same licensing terms as Perl. Installation and use instructions are on that page.

In theory, digest authentication will be more secure than cookie sessions, as once the session id is captured by the attacker, the attacker could then use that session themselves. Digest authentication always sends a different authorization header every request, so if the server can prevent replay attacks, the attacker wouldn’t be able to use the header again.

In using the installation of PHP 5.2.6 on CentOS, I noticed that there were a few modules missing from the repository that are included as part of CentOS’s extras repository. They are nowhere to be found in the testing repository.

I found an easy way to build the RPM’s by downloading both the testing php source RPM (SRPM), and the extras php-extras-5.1.6 SRPM, rewriting the php-extras spec file so it incorporated the same patches, and building it as the php-5.2.6 version.

The php-extras include the dbase, readline, mcrypt, mhash, tidy and mssql extensions. In my spec file, I have removed dbase and readline, as they have moved to php-common. I have also included the newly added extensions to php 5.2; json and filter. In future versions of CentOS, these should hopefully be updated in the extras or the base repository.

The steps that are needed:

Set up a source RPM build environment

useradd mockbuild
mkdir /usr/src/redhat
yum install rpm-build

Download and install the SRPMs, so that their build files are in the environment

wget http://mirror.centos.org/centos/5.3/extras/SRPMS/php-extras-5.1.6-15.el5.centos.1.src.rpm
wget http://dev.centos.org/centos/5/testing/SRPMS/php-5.2.6-2.el5s2.src.rpm
 
rpm -i php-extras-5.1.6-15.el5.centos.1.src.rpm
rpm -i php-5.2.6-2.el5s2.src.rpm

Save this php-extras.spec file to /usr/src/redhat/SPECS/php-extras.spec. The changes I have made reference the patches contained in the php SRPM, and have dbase and readline removed.also include the json and filter extensions to be built into RPMs as well.

Now run the build process

rpmbuild -ba /usr/src/redhat/SPECS/php-extras.spec

You will probably get an error at the start e.g.

error: Failed build dependencies:
        freetds-devel is needed by php-extras-5.2.6-1.1.i386
        libtidy-devel is needed by php-extras-5.2.6-1.1.i386

Install all of the packages mentioned, e.g.

yum install -y freetds-devel libtidy-devel
yum --disablerepo=* --enablerepo=c5-testing install php-devel

Now run the build process again, and by the end, you should have both an SRPM and the RPMs of the php extras.

You can put these in a repository or install them as the following:

rpm -i /usr/src/redhat/RPMS/i386/php-tidy-5.2.6-1.1.i386.rpm

Update 13th June 2009 – I’ve made the guide easier by using yum options to install the testing RPMs rather than using yum-priorities.

Redhat-based distributions tend to supply out of date releases of software. This isn’t technically a bad thing. They extensively test their updates before releasing out to the public, and upstream security fixes from the latest versions, meaning that they can be extremely stable when compared to some other distributions such as Debian-based Ubuntu.

However, this means that you rarely get new features added, until there is a new major release. Again this isn’t all bad, as new features add new bugs, which affect stability.

PHP 5.1.6, which is part of the base CentOS repository, was released 24-Aug-2006, almost 3 years ago. Since then, PHP 5.2 has been released, gone through 9 release builds since, and is considered stable for production environments.

Installation

There is a version of PHP (5.2.6) in CentOS’s Testing repository. You could either download each rpm and install, or set up your yum to install from the testing repository.

Install the testing repository’s GPG key:

rpm --import http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing

And download the CentOS-Testing repo file:

cd /etc/yum.repos.d
wget http://dev.centos.org/centos/5/CentOS-Testing.repo

Now you can install/update to PHP 5.2.6 by running

yum --disablerepo=* --enablerepo=c5-testing update php

Reasoning

As much as I have wanted to be using PHP 5.2, using just CentOS’s normal repositories meant not being able to use its new features.

It appears now that Zend Framework no longer supports PHP 5.1 in all of its sub-components, take for example Zend_View_Helper_Placeholder_Container_Abstract since ZF 1.7.5, and its derivative classes. This extends from ArrayObject, and it uses the php method ArrayObject::ksort(). This is not available in the version of SPL contained in Centos 5’s PHP 5.1.6. It causes a fatal error when used.

So, the question is should I write a patch for Zend Framework, which wont get incorporated into their code, or upgrade to PHP 5.2?

I chose the former initially, which fixes that problem, but I don’t know if there are any other bugs which might crop up in the library, so I’ve now chosen to update PHP.

I’ve been looking at generating random identifiers in PHP, and making sure they are random enough. Looking at the PHP function uniqid(), and its suggested better token, I don’t think this is an adiquate enough way:

$better_token = md5(uniqid(rand(), true));

Md5 is a 128 bit hash algorithm. Looking at the data inside the function, there doesn’t appear to be enough data (i.e. entrophy) for the 128 bits, so at best, the uniqueness of the resulting string will be less than the capacity of the md5.

uniqid(), this alone generates 13 hexadecimal characters, which is the equivallent of 52 bits,
rand(), generates a random integer number, which would fill 32 bits
uniqid(”, true), this appends additional entropy to the string, 9 decimal numbers and a dot, less than 20 bits of randomness

Adding these all up, 52+32+20 = 104 bits.

So what happens when you md5 a value that has 104 bits of randomness? You get at most 2^104 possible random values back in a md5 that has 2^128 values. Hashing algorithms can have multiple input values which generate the same output value, causing collisions, so the actual randomness would be less.

A better way

*nix systems (including Solaris, Linux, OSX and FreeBSD) have special device files usually /dev/random, which can generate as much randomness as required by reading in the number of bytes needed. /dev/urandom is a non-blocking version which sacrifices entrophy in order for the file to not lock.

$uniqueId = bin2hex(file_get_contents('/dev/urandom', 0, null, -1, 16));

This will return a random 32 character hexadecimal (128 bits). You shouldn’t need to md5 this.

Generating a shorter (yet just as random) string suitable for urls

The hexadecimal format consists of the numbers 0-9 and a-f, 16 symbols in total, yet there are many more acceptable acceptable characters available in a url.

You can have a shorter identifier if you encode the binary data as base 64 instead, which as its name suggests, has 64 symbols. However, the standard ascii symbols used in this encoding include + and /, which have special meaning in URLs. You can convert these to – and _ respectively to make them more compatible.

Also, base-64 encoding pads the end with = if there isn’t enough bytes in a block. These are not needed by an identifier, so can be stripped.

If the data string is already in binary, you can just do the following to convert it to base 64:

$base64encodedString = str_replace(
    array('+','/','='),
    array('-','_',''),
    base64_encode(md5($data, true)));

If however the data was in hexadecimal, you can convert it to binary using the php function pack() beforehand:

$base64encodedString = str_replace(
    array('+','/','='),
    array('-','_',''),
    base64_encode(pack('H*', md5($data))));

Doing this will shorten a 32 character hexadecimal into a 22 character base-64 encoded string.

Please note that when doing MySQL comparisons, your text field’s collate will most likely be case-insensitive. Comparing a base64 string against one in the database when the collation is case-insensitive (e.g. latin1_*_ci, utf8_*_ci) will dramatically increase the chance of collisions as 26 of the 64 characters will match the other 26 case ones, giving a significant reduction in bits.

The problem is that in order for me to be able to use that DNS server whilst being able to resolve internet domains at the same time used to require me to do two things:

• Edit /etc/resolv.conf, and change nameserver to 127.0.0.1
• Edit /etc/bind/named.conf.options, and add a forwarder to the nameserver IP that was previously in /etc/resolv.conf

Obviously this is too annoying to have to do every time the dhcp renews, wiping my /etc/resolv.conf changes. Also, if I am frequently changing networks, as I do on my laptop. I have to go and update the bind forwarders again.

In came the solution I wrote in Ubuntu 8.04 (Hardy), using the dhcp-script hook directory in /etc/dhcp3/dhclient-exit-hooks.d/, which scripts inside get called when dhcp renews, after the /etc/resolv.conf, I was able to write a script that did the above automatically.

/etc/dhcp3/dhclient-exit-hooks.d/zzzzz_bind-forwarders:

#!/bin/bash
BIND_IP=127.0.0.1
 
NAMED_FORWARDERS=/etc/bind/named.conf.forwarders
NAMED_INITD=/etc/init.d/bind9
RESOLV_CONF=/etc/resolv.conf
 
echo $new_domain_name_servers | sed -e '
iforwarders {\n
s/\([^ ]\+\)\s*/ \1;\n/g
a};' > "$NAMED_FORWARDERS"
 
"$NAMED_INITD" restart
 
sed -e "
\$anameserver $BIND_IP
/^\s*nameserver/i# moved following nameserver to bind forwarders
s/^\s*nameserver/# nameserver/" -i "$RESOLV_CONF"

This will read the dhcp announced nameserver from the parameters dhclient sends to it, create a /etc/bind/named.conf.forwarders configuration file with the dhcp nameserver in, and rewrite the /etc/resolv.conf nameserver to 127.0.0.1, and restart bind.

Now you just need to include the /etc/bind/named.conf.forwarders in your /etc/bind/named.conf.options file:

options {
        directory "/var/cache/bind";
 
        include "/etc/bind/named.conf.forwarders";
 
        auth-nxdomain no;    # conform to RFC1035
 
};

As I mentioned in the post Workaround so NetworkManager runs dhclient hooks, when I upgraded to Ubuntu 8.10 (Intrepid), this script no longer ran. Please read this article to make the script work again.

dhclient-script was previously used by dhclient so that whenever the dhcp changed, it would reconfigure the interfaces, generate the /etc/resolv.conf, and run scripts who’s intention is to modify the /etc/resolv.conf file based on the dhcp settings. These scripts are located in the folders /etc/dhcp3/dhclient-enter-hooks.d/ and /etc/dhcp3/dhclient-exit-hooks.d/.

Reading up on the problem, thanks to perlhead on the Ubuntu Forums, it appears that since NetworkManager did the same function as dhclient-script, which got in the way of NetworkManager’s plugins, so dhclient-script was disabled.

Sadly NetworkManager fails to call any hooks on dhcp renew, which is what my script needed. It only calls its hooks, which are located in /etc/NetworkManager/dispatcher.d/, when the interface is brought up or down.

I’ve made a modified dhclient-script, which when set as the dhclient script, will call the enter hooks, then call NetworkManager’s dhclient script, then call the exit hooks. This effectively gives the intended effect of allowing NetworkManager to run with the old dhcp hooks available.

To use it, modify your /etc/dhcp3/dhclient.conf and add/modify the line:

script /sbin/dhclient-script-networkmanager

And save this file /sbin/dhclient-script-networkmanager

Make sure its executable:

chmod +x /sbin/dhclient-script-networkmanager

Now restart NetworkManager to see if it has worked:

sudo /etc/init.d/NetworkManager restart

Wait for the network to reconnect again, if it hangs then it probably didn’t work. Check out your resolv.conf:

cat /etc/resolv.conf

Please let me know how it goes when running this script. I have only tested it on Ubuntu 8.10.

It can be used to distribute this source to the developers working on the project, the end-user and other projects which use the project. They each need to pick the correct Subversion folder to download from.

For example, you can track minor revisons to Wordpress MU 2.7.* by checking out http://svn.automattic.com/wordpress-mu/branches/2.7/.

Once you’ve picked the folder, you can download it using:

svn checkout http://svn.automattic.com/wordpress-mu/branches/2.7/ /var/www/wordpress/

If it is the trunk or a branch which changes, you can update it using:

svn update /var/www/wordpress/

If you want to switch to another folder (whilst retaining any modifications you’ve made/unversioned files):

svn switch http://svn.automattic.com/wordpress-mu/branches/2.8/ /var/www/wordpress/

It is important to note not all projects follow the same guidelines, and may not even create tags or branches of the project for other people. You shouldn’t for example assume that a “branches/2.7″ branch tracks the releases in tags/2.7.* without checking.

The most prevailing Subversion folder structure used by projects is a simplified CVS style, e.g.:

• http://svn.example.com/project/
  • trunk
  • branches
    • fubra
    • 2.7
    • newfeature
  • tags
    • 2.7.2

trunk

The trunk is the development version. Developers of the project checkout this version to work on, and commit to the repository. End-users and other projects wouldn’t tend to checkout this one, as it is likely unstable.

tags

When a project is in a stable and tested state, in a beta or is to be release candidate, the developers tag the project with a label, usually giving the label a version number, and a short description of its condition. e.g. RC for release candidate

Tags are meant to be fixed read-only, so they’ll never change, even with minor changes to the project. These are good for following if you want to lock to a specific build of the project.

branches

Branches are commonly used as forks in development which are intended to add new features to the project. Developers would use these.

They are also sometimes used to track minor revisions of releases, so that an end-user or other project can checkout this version and just “svn update” as minor changes are added to the repository. Examples of projects that do this are Wordpress and Zend Framework.