Last week we took a look at Landlord Credit Bureaus claims about EI3PA data security compliance and found they left us with more questions than answers. You can check out that coverage here:
NOTE: Since publishing the above post last week, Landlord Credit Bureau has removed all references to being EI3PA compliant from its website without noting the change.
Here is how their FAQ looked last week:
Here is what it looks like this week:
So were they mistaken about being EI3PA compliant or did they deliberately mislead the public about their practices? If they can’t be honest or accurate about their data security claims, how secure do you think your data is?
Today we are going to examine the first half of their published Security Policy. You can view their policy here.
The first paragraph is notable only for the fact that the writer chooses to highlight how they use SSL encryption on their site. That’s great, SSL is important in keeping data being transferred between their site and your device secure but SSL is commonplace technology. Google won’t index your website anymore unless you have a valid SSL certificate and have HTTPS enabled. It’s not the first technology I’d be invoking to assure users of my system that their highly sensitive personal information was safe.
The second paragraph is where things get interesting because specific technology and methodology is addressed a bit. First they claim that unique usernames allow them to track and audit user activity, which again is fair enough and what you’d expect. It would be interesting to know what kind of user activity is logged though and how long change logs are kept but otherwise take no issue with this part.
Hashing passwords is the practice of not storing a users actual password in a database table but instead storing an encrypted version of it. The ins and outs of it are complex if you aren’t well versed in cryptography (and I’m no expert in it) but if you want a primer on basic crypto jargon and how some of it works The Guardian has a pretty informative piece here. Let me stand on the shoulders of giants a bit and offer their explanation:
The cryptographic method deployed by Landlord Credit Bureau is called bcrypt. The Guardian piece helpfully has a section on the technology so once again I will defer to them:
My understanding of bcrypt is that it is a highly effective way to encrypt hashes as it is what is considered “computationally infeasible” to crack by brute force. This essentially means that it could take millions of years to brute force crack a single hashed value.
This sounds like a highly secure system and it is – in theory. It’s deployed all over the place protecting your passwords for all kinds of things. It turns out that how secure bcrypt is becomes highly dependent on how the individual user implements it and what kind of hardware and software tools the hacker has at their disposal.
Let’s look at two example cases.
Workplace-focused team chat app Slack was hacked in March of 2015. They used bcrypt to encrypt user passwords, as reported by TechCrunch:
In the case of the Slack hack, attackers were able to exploit the app so they could log passwords in real time as they were entered. In this case bcrypt did its job but the infrastructure around it failed. The impacts of the hack could still be felt at Slack 4 years later when they had to force password resets on 100,00 more accounts they confirmed were compromised.
So it’s clear that even when bcrypt works it depends on the rest of the applications infrastructure also being secure.
A more concerning example is the infamous Ashley Madison hack of September 2015. This time hackers were able to obtain the database for the popular adult “affair seekers” website and directly attack the user passwords, which were protected by bcrypt.
11 million plus user passwords would end up being cracked.
Once again, what we are seeing is not a specific vulnerability in bcrypt being exploited but rather attackers taking advantage of errors made in the sites programming. So far, bcrypt hasn’t been the point of failure in these examples.
So what about directly attacking a bcrypt hash? How long would it take?
To understand that we need to understand something called a Work Factor, which is a system cryptographers use to describe the amount of effort it takes to break a code.
Going by the above benchmark from 2016, a Work Factor (cost) of 5 allows a pretty standard desktop server to process 384.04 passwords per second. Using a specialized rig of 8 high-end GPUS you can achieve 115,642 hash functions a second. As you scale up, the fewer hash functions you can perform per second, creating a bottleneck for the performance of your site or application.
So how long to crack these different Work Factors?
This chart assumes you are using the same kind of high-end GPU rig. The main factor after Work is what kind of password scheme you are implementing. Ironically, we can see that passwords which would be considered PCI DSS compliant are the most vulnerable. A Work Factor 5, PCI compliant password could be cracked in a mere 5 days.
So what kind of password is the Good kind that’s taking 29 million years to crack?
The US Department of Commerce National Institute of Standards and Technology published a draft standard for digital identify management in 2017. You can read the full paper here.
Here are their findings about passwords (referred to here as Memorized Secrets):
These standards are a long way from being adopted and so most implementations of bcrypt aren’t really taking advantage of its features to provide maximum protection.
Technology deployed by attackers has come a long way since these 2015 breaches as well. Using GPUs in cracking setups has become yesterdays tech – modern crackers have moved on to clusters of Field Programmable Gate Arrays or FPGAs to take on the job and the performance gains are massive.
Scattered Secrets has published details of one such cracking device they have built using a cluster of 18 FGPAs.
Here are their benchmarking numbers for CPU and GPU based hashing:
Now here is a comparison between a single GPU and a single FPGA:
FPGAs can run 4x the hashing operations of a normal GPU. When clustered in an array of 18 FPGAs:
So that’s 2.1 million password attempts per second. All in one neat little 4U rack mountable package.
Scattered Secrets began using a cluster of 4 of these arrays to achieve 8 million plus attempts per second.
These devices dramatically alter the time considerations for brute force cracking bcrypt and other hash functions. But how effective is FPGA-based bcrypt cracking in real world scenarios?
Scattered Secrets were able to put it to the test in 2019 when the database of Dutch adult web forum Hookers.nl was leaked to the web. The site used a mix of older MD5 hashed passwords and newer bcrypt hashed passwords. In just 3 days the group was able to crack 57% of the total user passwords on the site using very basic dictionary attacks.
How did they perform against bcrypt? In 3 days they were able to crack 11,675 of the passwords protected by bcrypt – 24% of the total.
The vulnerability? Weak passwords that are easily recognized by dictionary-based cracking software. You use dictionaries to help you make educated guesses about passwords, dramatically reducing the amount of time needed to crack them. Here are the top 35 passwords used by users of Hookers.nl:
What we are seeing is that the answer to whether bcrypt is secure or not relies on factors that can have little to do with bcrypt itself. What really counts are the Work Factor and the complexity of your password. Since we know Landlord Credit Bureau doesn’t enforce any special password schemes resembling the type recommended by groups like NIST, it’s safe to assume there are plenty of accounts which would be vulnerable to this kind of attack.
Let’s assume a fairly robust Work Factor for LCB though. Ashley Madison used a work factor of 12 back in 2015 and needed to be cracked through other software exploits. How would a Work Factor 12 site stand up, even with regular PCI compliant passwords?
Back in 2016 the benchmark was 641 days to break a Work Factor 12 password using an 8xGPU cluster. It could manage just over 900 attempts per second. We’ve shown that FPGAs give about 4x the performance over GPUs so using a single FGPA we should expect to reduce that 641 days to about 160. Add 17 more FPGAs and you can see how that time is going to keep shrinking until it’s down to just a few short days. Given current technology I’d consider even Work Factor 12 to be vulnerable to brute force at this point and that capability will only increase as the technology improves.
In the case of the Landlord Credit Bureau, let’s highlight some risk factors:
- Cryptographically strong passwords not enforced on the site
- Unknown bcrypt Work Factor (anything less than 12 with their password schema should be considered easily crackable)
- No two-factor authentication
- Potential vulnerabilities in other aspects of the LCB infrastructure that could be exploited in order to reveal passwords and other data
The currently published Security Policy of the Landlord Credit Bureau doesn’t do anything to address these risk factors, nor does it reveal any kind of corporate quality system that would address things like routine vulnerability testing. Adoption of standards like PCI DSS and ISO 27001 would be very welcome first steps towards a more robust and open model for data security but as we have seen, even these standards have been found to be lacking when it comes to meeting the challenges of the modern Internet.
Next time we will take a look at the rest of the Security Policy and examine the claims being made.