Note: I am talking about hashing opposed to encryption. Many people use the terms interchangeably, however they are very different operations and should not be confused.

• Hash functions convert variable sized data into a fixed sized result. They are deterministic and one-way – the same input always hashes to the same output, which cannot be reversed. Hashes have many more useful properties, but for storing passwords the important point is they cannot be reversed.
• Encryption is the process of transforming information to make it unreadable to anyone without the decryption key. The important difference is the ability to recover the original data given the correct decryption key.

In the situation where the database in compromised and users password hashes are exposed, it is a good bet that any decryption key we have stored could also be compromised. Since we have no need to know the users actual password (we can check for a valid login by hashing their input and comparing to the stored hash) we should never use encryption for storing passwords.

Hashing the password

At first glance password hashing seems like an incredibly simple problem – just run the password through a well known hash function and job done. Most advice these days seems to suggest the use of SHA-1 or SHA-2.

Hashing

SHA-1/2 are hash functions, designed by the NSA. Like all hash functions, they are one-way, so given a database of password hashes an attacker cannot reverse them. However passwords hashed using a simple hash function are still vulnerability to reversing using rainbow tables. Rainbow tables are mappings of resulting hash -> original password for dictionaries of common passwords, etc. To combat rainbow table attacks many people suggest the use of per-user salts.

Hashing + salt

A salt is a randomly generated string which is appended to a users password before hashing. This randomly generated string prevents the use of pre-generated rainbow tables as it increases the complexity and length of the final password, and hence the size of rainbow tables required are infeasibly large – the only solution is for an attacker to attempt a brute force attack using the correct salt.

Thanks to advances in parallel computing and graphics card technology, this is now a viable solution. Various tools such as IGHASHGPU and whitepixel now exist – with whitepixel boasting as many as 33.1 billion MD5 hashed password attempts per second using just 4 AMD Radeon 5970s.

Key stretching

Key stretching refers to techniques used to increase the time it takes to test a password – and hence decreasing the number of brute force password attempts that can be made per second. Using plain hashing algorithms we are talking one millionth of a second to generate a single hash on a regular CPU, or in the order of one billionth of a second using the above mentioned GPU software. If we can increase the time taken to generate a single attempt to 10s of milliseconds then we have effectively cut the brute force attempts by 4 or 5 orders of magnitude. In the situation where a legitimate user is attempting a login, an extra 10ms is in most cases unnoticeable.

BCrypt (Blowfish encryption)

I started this post by emphasising the difference between hashing and encryption, and stating that encryption should never be used for storing passwords – so you might be asking yourself why I am now talking about encryption?

BCrypt is an algorithm for irreversibly obscuring passwords using the blowfish encryption algorithm. It is important to understand that BCrypt does not simply encrypt passwords – the process is still a one-way process, just like hashing. BCrypt works by encryption a magic string, using a key derived from the provided password. The encrypted magic string is stored in the database, but the derived key is never stored.

The blowfish algorithm is important, as the amount of work done to encrypt a string, and hence time taken, is tuned using a cost parameter. By increasing this cost factor we can increase the time taken to test a password.

BCrypt is available as of PHP 5.3+, using the crypt function.

PBKDF2

PBKDF2 (Password-Based Key Derived Function) is a function to produce derived keys by repeatedly hashing the input many times. I’m not going to attempt to explain PBKDF2 in detail, however by tuning the number of times to repeatedly hash the input the cost can be increased, in the same way as for BCrypt. PBKF2 is used by some well known protocols/systems, such as WPA/WPA2, Grub 2, and LastPass.

Generating random data with PHP

Generating random data doesn’t sound like it should be challenging, and indeed it is not – however generating cryptographically strong random data is a bit harder.

The default random number source used by PHP is not considered to be cryptographically strong – however not to worry, there are various sources of cryptographically strong random data on most systems.

PHP 5.3+, OpenSSL extension

The OpenSSL extension, included by default in PHP 5.3+, provides a source of cryptographically strong random data.

/dev/urandom

For Linux/UNIX systems, cryptographically strong random data is produced from the device unlocked random, /dev/urandom. This can be read using the regular file access functions in PHP.

Microsoft CSP (Cryptographic Service Provider)

The Microsoft Cryptographic Service Provider API provides a source of cryptographically strong random data on Microsoft Windows systems. It can be accessed using the COM interface.

Solution used in FluxBB v2

For FluxBB v2 I have produced a library which makes use of BCrypt when available on the system (PHP 5.3+), and falls back to PBKDF2 otherwise. Cryptographically strong random data is obtained using the OpenSSL extension if available, will fall back to /dev/urandom, or in the worse case PHPs built in non-cryptographically-strong functions.

In PunBB 1.3 (which we forked into FluxBB 1.3 Legacy), Rickard introduced the use of hooks and eval, to allow extensions to insert code and extend the core software. Originally this system was designed to allow small changes, but by the time the software was finished it had mutated into a full blown extension system.

Along with the disadvantages inherent from a hook system (see below), FluxBB 1.3 Legacy used a rather horrible system of PHP code within XML code, which was parsed and inserted into the database on install. The aim was that then the install files could be deleted or overwritten and the extension wouldn’t be affected until it was uninstalled/updated. However due to the fact that most extensions referenced external files (be it included php files, or css and images) this theory did not work very well.

So, going back to the beginning, what are the different solutions available for writing extensible PHP software?

Hooks

Hooks are probably the most common way used to make PHP software extensible. The idea is fairly simple; throughout the code there are “hooks”, where extensions can insert code. Below is an example hook taken from FluxBB 1.3 Legacy:

if (isset($_POST['form_sent']))
{
	($hook = get_hook('po_form_submitted')) ? eval($hook) : null;
 
	// Make sure form_user is correct

In the above example the get_hook method will look for all the code which has been registered with the hook “po_form_submitted”, combine it and return it. The code will then be executed using the eval function.

The disadvantages of the hook system should be fairly obvious…

• Blocks of code can be inserted, but only at pre defined locations within the software. This means extra thought has to be given during development as to where hooks may be required. If someone writing an extension needs a hook in a place where there isn’t one, then they are out of luck.
• Insertion of code is all very well, but what if we want to change or remove some existing code? There is no way to do this using hooks. This leads to extensions with rather “interesting” algorithms to attempt to undo or block code in the core, which can be both messy and inefficient.

Despite these rather major sounding disadvantages, I would argue hooks are good! At least much better than requiring users to change code by hand…

In the example code given above the eval function was used to execute the inserted code, but where is the code actually stored, and is this the best way to execute it? There are a few options:

• Store the code in a database or XML etc. then load and eval it when required. This probably isn’t the best solution as it involves storing code in the database or other storage that isn’t designed for code. Caching would probably also be required, loading and parsing a large XML file on every page load would not be efficient.
• Keep the code for each hook in an individual PHP file and include it when required. This option seems reasonable, but could result in having a huge amount of tiny files being included, which could be hard to organize and may not be ideal if the server isn’t running any form of opcode cache.
• Keep the code all in one PHP file and register specific functions with each hook, then call these when required. This seems like the best solution, but introducing functions introduces problems of variable scope. The underlying code would need to be written carefully in a way that appropriate variables can be passed to each hook.

Patches

A totally different approach to extending PHP software is patching it. In a similar way to how a patch file is used, the software could read instructions from an extension and physically modify the appropriate code.

@@ -58,7 +58,9 @@
 // Did someone just hit "Submit" or "Preview"?
 if (isset($_POST['form_sent']))
 {
-	// Make sure form_user is correct
+	// This is some new code
+	$username = isset($_POST['username']) ? $_POST['username'] : null;
+

This means that once the extension has been installed, there is no extension code left to worry about; the physical files have been changed and the extension installation files can be removed.

At first this may seem like a much better solution than hooks; code can be inserted/changed/deleted anywhere in any files, there is no need to litter hooks all over the place. However it has three major disadvantages:

• Often in shared hosting environments PHP will be configured to run as a certain unix user (usually “www-data” or “nobody”). For the software to be able to patch itself, all files would require to be writeable by that user. This could prove to be a major security flaw as it would allow other users on the server to modify your files. A work around for this could be to modify the files over (S)FTP instead, but then the user would need to provide their hosting login details.
• Updating the core software becomes harder. Since the files have been physically modified it is no longer a simple task to replace them with updated files. In theory core updates could be applied the same way extensions are installed (i.e. as patches), but with a modified board conflicts are fairly likely, and code that been removed by extensions is likely to just be replaced when the core is updated.
• An extension with a bug, or even a malicious extension, could render the whole software unusable by deleting sections of code or inserting invalid code. Since the actual files would have physically been overwritten there would be no way to recover from this, other than the user manually uploading a backup (if they were organized enough to have one!).

To me this seems like a rather show stopping problem, what’s the point in a one-click install system if uninstallation can require manually removing the changes. The idea of a buggy extension being able to totally destroy a working install is not acceptable!

Conclusions

What will be use in FluxBB 2.0? Only time will tell, but I’m currently leaning towards making use of hooks again, but attaching functions loaded from native PHP scripts, rather than chunks of code to be evaled.

Have any suggestions or better ideas? Please leave a comment!