View RSS Feed


Who stole the pig?

Rate this Entry
To those who haven't already heard it will come as disapointing news that the private torrent site oink has been closed down. The raid took place a few days ago during which the servers were siezed by dutch police. Enough people have already bloged about how this is a waste of police time etc so i'm not going to bother with that angle, however no-one has yet thought about all the data about oinks users that could well be in the hands of the nefarious riaa.

Oink, like meny other private sites requires to keep certain information about upload and download ratios as well as emails, usernames and passwords. All this gives a fairly good idea of who was doing what my thoughts then led on to how this data could be stored securly without linking it to real life people in the event of the servers being siezed...

Considering a number of methods a fairly obvious answer to this would be to encrypt all the user data. There is however one issue... if all the data is encrypted how can the website use it? It needs a method of decryption, the attacker in this case will have at their disposal that method of decryption so however secure you make it they will be able to get the data eventually.

A second method then comes to mind. What if the data was automatically destroyed when the server was siezed? There are a number of ways to do this, the easiest would be to store it all in a memory based mysql table. Once the power goes out the data goes poof. There is two issues with this method. Firstly, storing a huge database in ram isn't really very efficient, secondally if there is a powercut or machine crash you lose all your data for nothing.

Its clear a solution somewhere between the two is needed. My first thought was what if the encryption key for the data was only stored on the servers memory (and in an offsite location such as the admins home (preferably on a quick erasable flash stick)) this would allow the webserver to access the data however if a powercut occured or the server was taken the data would be unacessable. This solution does have the advantage of being able to recover your data in the event of a fault, however such recovery is only possible with admin intervention (reuploading the key) so produces a large ammount of potential downtime. So it is good, yet its far from ideal in a production enviroment.

Then i came up with the following solution. The basic idea here is you split the data accross multiple tables as you would in a standard relationship database however there is no relationship between them. How can this possibly work then? Easy. Lets say you have a table with usernames in and you dont want an attacker to be able to link usernames and emails. You create the following table structure:

userid: Primary key.

emailid: primary key.
email address

you then create a table in memory with the following structure:


Which links the two together.

Again not wholely useful as in the event of a power faliure you lose all your data. So, you need to make a copy of this data to the harddrive. This should be done on a regular basis and encrypted with a key only stored in memory.

How does this help? Consider the two situations, powerfaliure and server sizure.

If there is a powerfaliure, the application that needs to link usernames to emails is going to have to live with the fact that not all usernames now have emails associated with them however new accounts can be signed up and existing users can change emails (in the second case a new email id row is associated with their userid which upon reuniting the joining table with the encrypted version on the harddrive will overwrite the old one.)

When the admin wakes up and signs in, he simply reuploads the key and merges the backed updatabase on the drive with the newer one. Keeping the newest entries for any key. Untill this happens the server is vunerable to a second faliure, however in this instance far less data will be lost.

In the second case the server being sized, the relationship between the two items of data is destroyed and they become meaning less. The quick thinking admin also uses the quick erase button on his flash key ensuring that the data cannot be recovered.

So the police have a lot of emails and usernames, still not a great situation to be in... but substantially better. The finial act of defence against this kind of attack should be insertion of fake data into the database. The only meaning full items of data in there is the relationship between items. If an item in one table has no matching item in the second it can be safly ignored by the application. However given just the tables with no relationships makes it impossible to determine which items can be ignored and effectivly makes the whole list useless.

Submit "Who stole the pig?" to Digg Submit "Who stole the pig?" to Submit "Who stole the pig?" to StumbleUpon Submit "Who stole the pig?" to Google



  1. Stephen's Avatar
    Carnage, this is an awesome entry. I am off to read your others - I hope they are just as interesting.