With websites which are often updated, the content is almost always stored in a database. The only thing which remains static is the framework to render the site.
When a hack occurs, one of two things will have to happen. Either the database will have to be rolled-back to a point in time before the hack occurred, or each and every line will need to be inspected for malicious content. The problem with rolling back is content loss, and obviously this grows depending on how far back the database has to be taken. Consider the fact that users here have found reference to leaked user accounts reaching as far back as October, and then consider the kind of content that PFK will have stored in the database - each news article they publish, reviews, editorial, not to mention forum posts. The work involved in "putting things right" is colossal.
On the flip side of that, there is no point doing a mountain of work to clean the database if you don't fix the site code which was vulnerable in the first place, and finding the vulnerabilities can take ages, especially if you have a large site framework.
I wouldn't be surprised if the hack was executed via a technique called SQL-injection. SQL-injection utilizes the normal behavior of a piece of code, and tries to manipulate it into doing things it shouldn't. It is up to server protection technologies and input validation to protect against these. Take the following as an illustration:
The user is browsing a website, and clicks on an article about planted aquaria. The article has an article ID in the database where the article is stored, so the link the browser requests is something like:
http://www.plantedaquariumsarefab.tld/a ... p?id=12345
where "12345" is the ID of the article the browser wants. Now take that same page (articles.php), and get it to spit out things it shouldn't:
http://www.plantedaquariumsarefab.tld/articles.php?id=("SELECT+*+FROM+'tbl_users')
where "tbl_users" is the table containing all the user accounts.
SQL injection is a right royal pain-in-the-ass, but with suitable server technologies (such as mod_security for Apache server and URLScan and similar for Microsoft IIS), it can be mostly mitigated against. The remainder of the protection comes from the site code, ensuring that it will not execute queries it is not supposed to, and a database architecture which prevents unauthorized access to, and modification of data.
Thus endeth the lesson on website security
😉
IT11
(Edit: fixed typo)