The Zola credential stuffing attack: Who’s to blame?

News came out last week that Zola had been the latest victim of a credential stuffing attack. The fancy name credential stuffing simply means that the attacker accesses a database of log-ins and passwords stolen from other sources and tries to use the same log-ins and passwords on other sites, such as Zola. Unfortunately, since passwords are reused by most users on the internet, this has become a very common problem.

Credential stuffing attacks are the easiest type of attack that wannabe hackers try to use, simply because they require very little technical knowledge. By accessing underground forums, criminals can find a list of log-ins and passwords and devise an efficient way to try these log-ins and passwords on other sites. Contrary to popular belief, it’s not hackers that perform such attacks, but so-called script kiddies. And there are a lot more script kiddies than hackers.

The customer is always right

Recent articles mentioned that Zola failed to respond to questions about why they didn’t use two-factor authentication to protect their users, suggesting that Zola is to blame for this attack, but are they?

The famous rule the customer is always right applies to web application security as well. The attack on Zola was possible only for the users who used the same log-in and password for Zola as they used on other sites. Unfortunately, many users don’t realize that using the same password in more than one place represents a serious security risk and leads to them becoming a victim of the attack. And the public perception of blame points at Zola which went from victim to villain overnight because of some of the negative publicity they received. Many organizations have gone through this shift.

This situation sounds just like blaming the manufacturer of a door lock for a break-in that happened because the homeowner did not even bother to lock his door.

What can companies do to protect users?

While the owner of the web application that hosted accounts with compromised passwords didn’t do anything wrong to become a victim of credential stuffing, they can do more in the future to protect their users. Multi-factor authentication (MFA) can make such attacks more difficult, but it will only protect users who are already more likely to use secure passwords. Companies can’t make MFA obligatory or they are apt to lose a lot of users (those who don’t want to bother using their phones every time they log-in). And if the company doesn’t make it obligatory, most users are likely to opt-out – so security managers end up in the same situation as if they didn’t have MFA at all. The least security-savvy and the most careless users will become victims of credential stuffing anyway.

Security teams can also check user passwords against known password databases (such as Have I Been Pwned) and warn them or disallow the use of such passwords. Google does this with their password check function, but even users that have this function activated often ignore it, thinking that certain sites are not important enough to bother creating unique passwords. On the other hand, enforcement of unique passwords could also lead to losing a lot of users.

A third solution to prevent password stuffing attacks: introduce rate limiting. In simple terms, the website or web application should not allow 1,000 attempts to log-in in a single minute. If the security team slows down the log-in process or introduces reCAPTCHA or a similar service if there are too many attempts in a short time, they can make almost certain that such mass attacks won’t happen. However, it’s a delicate balance between keeping users safe and not making them upset – users don’t like CAPTCHAs and throttling may block legitimate log-ins, too, especially in the case of busy web applications where it’s very difficult to differentiate between regular traffic and stuffing attempts.

The toxic culture of passwords

We live in a digital age where there are more and more resources to log-in to every single day. So it’s no wonder that users are frustrated, can’t remember all these log-ins and passwords, and keep reusing them.

The situation gets worse because many companies force people to use difficult-to-remember passwords and to change them often. This simply causes people to reuse the same passwords with different suffixes, for example, password1!, password2@, etc. Such passwords are trivial to crack and are the primary cause of credential stuffing in the first place.

Single sign-on (SSO) schemes such as the ones by Google and Facebook help a lot by allowing people to just use their social media accounts to authenticate. However, this creates another problem – if a criminal gets access to that social media account, they could get access to everything else. Some users are also worried about their privacy. In the end, SSO schemes have not lived up to their potential.

There’s no getting around that companies need to educate users and popularize password managers – applications where users can store all their passwords using one complex passphrase. However, most such apps are still developed for one platform only and make it difficult to use several devices at once. And cloud-based apps such as LastPass were known in the past to have vulnerabilities so are not considered fully secure. So we’re back to square one – users can’t remember their passwords.

It seems like there’s no good solution for now and no future for passwords. Our attempts to replace passwords, for example, biometric authentication, are not better at all – it’s trivial to fake a fingerprint or a face scan. There’s still hope that someday we come up with a better solution for everyone. For now, we just have to live with common password vulnerabilities and the fact that there are users who use “password123!” on a dozen different sites, no matter how much we try to educate them.

Zola did well!

All this media attention has not been good for Zola. Some media outlets seem to suggest that they did something wrong while in reality, they couldn’t have done much more. They could have attempted to promote (but not enforce) MFA, but that’s always a futile approach. They could have used request throttling, but it’s not a guarantee that the attack wouldn’t have happened. It all comes down to the fact that they could not control the behavior of their users, and nobody can.

We also feel that Zola’s action was a good example of how a business should react in these circumstances. Immediately upon noticing a credential stuffing attack, they forced password resets to all the users. Then, they took the systems temporarily offline to check for impact. When systems were back up, they were certain that the attacks would not continue – thanks to the password reset. And then, they started resolving individual cases for those users who reused passwords and therefore were attacked. The only other idea that we would recommend is releasing an official statement with technical details of the attack – in the name of responsible disclosure, learning from the best, such as Cloudflare.

Tomasz Andrzej Nidecki, senior cybersecurity consultant, Invicti Security