Password hashing is an interesting subject, which I have been working on enhancing in FluxBB v2. Here I’m going to provide an introduction to storing passwords securely, and share some thoughts as well as our solution.

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.

Read More >>

For years I have been drawn by the idea of creating a MORPG. My first stab, back in 2007, involved development of an emulated server for an existing game, allowing me to concentrate on server development without any of the complications associated with client development or even storyline development.

In 2008 I undertook a project entitled “Creation of a MORPG framework using Apache MINA and jMonkeyEngine” as part of my final year at university. The aim of this project was to effectively take what I had learned and turn it into a legitimate project, and investigate the viability of the game engine jMonkeyEngine for our game client. While this project worked to an extent, and in fact won me the Best Student Project 2008/9, I decided that jMonkeyEngine was providing much more than I needed or wanted. The original plan had been to continue work on the project after university, however after my dissertation was completed the project was dropped.

This year I decided to revisit the project, and started work on a new game client – this time avoiding any existing game engines, and making direct use of OpenGL (though JOGL). In the future I may try and write some blog posts with technical details or plans, however for now I just wanted to post a few screen-shots to prove it is at least vaguely working…

This is just a quick post for anyone looking to update the BIOS for their Asus EEE 1201N. As of writing, the latest is BIOS version 0326, though a full list can be found on Asus website, or directly from their FTP server (holy crap it’s slow…).

Read More >>

In thinking about FluxBB 2.0, one of the important goals is to come up with a well designed and easy to use extension system. The days of manually digging into the code are past, people now expect to be able to install an extension with one click.

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?

Read More >>

As a follow on to my post about choosing RAID, here is a quick guide to setting up RAID-5 using mdadm. In theory this should apply to any distro that has mdadm, but I was already running Ubuntu 9.10 (just upgraded yesterday actually!).

Note: RAID-5 requires a minimum of 3 drives, and all should be the same size. It provides the ability for one drive to fail without any data loss.

Usable space = (no. of drives - 1) * size of smallest drive

In my set up I started with 3x 1.5TB drives, giving 3.0TB usable space. I have now grown it to 4x 1.5TB drives, giving 4.5TB usable space.

Read More >>

Having been virtually out of hard drive space for the past couple of months I finally decided to do something about it, and purchased 3 new 1.5TB Seagate Barracuda hard drives. I chose these because I already had one and thought 4 the same would make sense, but if you are buying all new then the 1.5TB Western Digital Caviar Green is maybe a better option; it is 5400rpm rather than 7200rpm, the performance loss shouldn’t be an issue for a basic file server, but the power saving and quieter operation may be appreciated.

I decided to create a software RAID-5 array using the 4 drives, to give a total capacity of 4.5TB with the ability to handle 1 drive failure.

Read More >>

Since I started my PhD in August I am now rapidly nearing the 3 months mark. Having spent the past couple of months doing mainly just reading to try and get up to speed on the background, I am now starting to work on writing a review paper, reviewing methods for wildcard search over structured peer-to-peer overlays.

Although not related to searching, I came across a rather interesting paper about using peer-to-peer technology in MMORPGs the other day which some day I’d love to follow up on, given the time…

Abstract – We present an approach to support massively multi-player games on peer-to-peer overlays. Our approach exploits the fact that players in MMGs display locality of interest, and therefore can form self-organizing groups based on their locations in the virtual world. To this end, we have designed scalable mechanisms to distribute the game state to the participating players and to maintain consistency in the face of node failures. The resulting system dynamically scales with the number of online players. It is more flexible and has a lower deployment cost than centralized games servers. We have implemented a simple game we call SimMud, and experimented with up to 4000 players to demonstrate the applicability of this approach.

After various ups and downs for FluxBB I feel things are finally starting to look up. I am proud to have recently taken over leadership of the project, and am looking forward to a more organized and structured future.

We have also recently announced our plans to unveil a brand new website, on a new server which I have ordered from Gandi (where I also happen to rent the VPS for this website from). On the new server I have decided to give lighttpd a try as an alternative to Apache2, I guess time will tell if this was a good idea or not.

The new website, along with looking much cleaner and professional, has much more information and many more useful features than the old (and slightly out-of-date) one.

Read More >>

Hello World! This is just a test post to test out wordpress…

If you find any problems with the skin or anything please let me know…