Fisher Hargreaves Proctor Suffer Security Breach
Property Professionals Fisher Hargreaves Proctor have e-mailed clients and customers alike to warn that their site has suffered a security breach. Unidentified miscreants managed to gain access to the FHP user database. These details were then publicly posted on the internet.
The FHP website is maintained and run by Reach Marketing, who were (according to the e-mail) instructed to take down the site hosting the compromised credentials. This suggests that the attackers hosted the details with Reach Marketing, so it's quite possible that the attack was the result of a weakness in RM's website management system.
This, however, is conjecture as I can find nothing to suggest that Reach Marketing actually host websites. I'll be sending an e-mail to try and find out exactly what has happened.
FHP for their part have generated new random passwords for all their users and apologised for the inconvenience.
However, even with the few facts available, it begs one question - Why was this allowed to happen?
Security breaches happen, and I'm not holding either FHP or RM responsible for the breach itself. What concerns me is that the attackers were able to retrieve passwords. There's no apparent reason why FHP would need to store passwords in plaintext, they don't need to log into external services on the users behalf. Indeed, the FHP password appears to do nothing more than grant access to the site. So why wasn't it stored as a hash?
I'll say it again
I've said it before, and at risk of wasting my breath I'll say it again - any developer who stores plaintext passwords unnecessarily should be fired. Quite frankly, the number of serious breaches that could be avoided through sensible password control is getting ridiculous. There's no reasonable justification for storing a password in plaintext, except in a few specific circumstances, and to do so is a sign of laziness.
For the record, I don't think it was FHP who made this mistake. The impression I get is that Reach Marketing designed and built the website, and that the fault lies with them. I doubt anything will come of it, but I've emailed FHP explaining why storing passwords in plaintext is bad, and that they should consider hiring a competent developer!
Alternatives
The preferred method of 'storing' passwords is by using a hash. This is simple to do, and can be done in one of three forms;
- Unsalted Hash
- Salted Hash
- Random Salted Hash
The former is more susceptible to cracking through the use of Rainbow Tables, but is still a marked step up from storing in plaintext. The second at least requires the attacker to generate rainbow tables specific to your system.
The use of Random Salted Hashes requires a little more processing power, but certainly not so much as to be inaccessible to 99% of users.
Let's take a look at the difference's in the way that passwords can be stored;
Plain Text
| Username | Password |
| Mike | MySecretPa55 |
| Bob | P455w0rd |
So although both users have chosen reasonable secure passwords, if we can gain access to the database we can view both their username and password at a glance. This is not good!
Unsalted Hash
On a linux system, we can generate each hash by simply running the command;
echo "PASSWORD" | sha1sum
(replace PASSWORD with the users password)
| Username | Password |
| Mike | c9fd5dcdb02480b3ba6ab0f6823b4d209e8dcfd1 |
| Bob | d7f564b13cb5d14fd5d0b59023067e0c23bf68c5 |
Already, our system is looking far more secure. Given the power of modern computers, however, this is not nearly as impenetrable as it appears to the human eye. An attacker will probably have generated what is know as 'Rainbow Tables'. These (simply put) consist of a database of phrases and the corresponding hash, containing every word in the dictionary and then some (which is why users are advised to use random combinations of letters and numbers).
Because we haven't salted our hash, the attacker can use the same Rainbow Tables as he did for Company A (who also didn't salt their hashes).
Salted Hash
In order to salt the hash, we simply need to add a few characters to the users password (this is known as the salt). This would be the same system wide, so as an example lets add FHP to the front of the users password. So let's run the following command for each of the user's passwords;
echo FHPPASSWORD | sha1sum
(again replace PASSWORD with the user's password)
| Username | Password |
| Mike | bb4d9320373b5132a391e9ef683568c415b27a38 |
| Bob | 82a5a6907931b5f4d8ab9b45825ae5a378c8188e |
Note how much the hashes differ to those generated as an unsalted hash. Now, if an attacker wants to decrypt our passwords he will need to generate a set of Rainbow Tables using FHP as the salt (assuming of course, that he is able to find out what the salt is). Even assuming our attacker knows the salt and is dedicated enough to do so, it may take many hours to generate the Rainbow Table let alone crack the passwords. Up until reasonable recently this was considered "computationally secure". With the wide availability of high performance systems, however, this is probably no longer the case.
Random Salted Hash
This is my preferred method of storing passwords, but it does require us to add an additional field to the table - as below. The point in the Random Salted Hash method is that each entry has a unique salt. So although an attacker could generate new Rainbow Tables, he would have to do so for each and every hash he wants to crack. This is of little benefit if the attacker is targeting a specific user, but does at least lend your other users some protection.
If the attacker, however, was hoping to steal credentials for every user on your system, they are going to have their work cut out.
As with the above example, we'll place the salt at the beginning of the password;
echo SALTPASSWORD | sha1sum
| Username | Password | Salt |
| Mike | b73e717fc416adcf40c0b44f4489715c3b4e2df4 | ABGD |
| Bob | 270d0349aa8e202cdc4209813e589fd9577bc4b7 |
BDAS |
So our attacker would now need to generate a set of Rainbow Tables for each and every user on the system. He would, however, know exactly what the salt is as it's stored in the database alongside the hash. Personally, I believe that this is a reasonable tradeoff in comparison to hoping that a single salt will be sufficient to protect all your users.
User Log-In
What use is hashing a password if you can't verify against it when the user tries to log-in? Although the value in the table clearly differs to the users password, validating it couldn't be easier - simply run it through the same command that generated the hash in the first place.
Obviously you'd use a CGI script or similar to do this processing, but it's the same basic procedure as if you were entering the commands manually.
FHP Email
The e-mail FHP sent out is as follows, it's nice to see an apology and especially nice that they actually bothered to warn their customers;
Dear B Tasker
We have been made aware that our website has been hacked. We will therefore be separately sending you a randomly generated new password. Please feel free to change this when you logon to the FHP Website [REDACTED]
As a result your login details were lifted from our site and placed on a public site.
As soon as we became aware of this we instructed Reach Marketing who built and host our site to close down the destination of the hacked information. This has been done.
It is unlikely but possible that the details that you placed on the website may have been saved by persons unknown to us.
Clearly this is an illustration of the world we live in today and we apologise for any inconvenience caused to you.
If you have any queries please contact [REDACTED] or [REDACTED]
Kind regards
Hopefully Fisher Hargreaves Proctor have learnt from the experience and are taking steps to ensure a re-occurrence. They've certainly been quite lucky in that the breach remains largely unreported, certainly makes me wonder whether they've bothered to report the incident to the Information Commissioners Office.
Update
More information on the breach can be found in this later post.
