Back in December 2022, PayPal didn’t suffer a data breach, but nearly 35,000 of its customers had their accounts accessed by an unauthorized party over the course of three days. Wait a minute, I hear you say; why isn’t that a PayPal data breach, then?
It’s a tricky one, truth be told, but the account access didn’t happen as a result of any compromise of PayPal security systems. Rather, they were subject to a large-scale credential stuffing incident that enabled a third-party attacker to access them using the correct username and password combo the real customer had set.
In effect, then, this was a breach of 34,942 individual PayPal accounts rather than a breach of PayPal itself. It was also a very good example of why people need to take better care when it comes to preventing themselves from getting stuffed in almost every sense of the phrase.
What happened to PayPal customers?
PayPal confirmed on 20 December that a credential stuffing attack took place between 6 and 8 December, when access for the unauthorized parties was eliminated. This is according to the notice of security incident sent to the affected account holders in January 2023.
No unauthorized transactions were made and, PayPal wrote, no personal information was misused. Whatever that may mean. Importantly, the attackers didn’t obtain the login credentials used from any PayPal systems. This means that it was the dreaded, all too common, and so easily preventable credential stuffing attack instead.
How do credential stuffing attacks work?
A credential stuffing attack is precisely what it claims to be: attempting to access multiple high-value accounts using login credentials for a different service. A service that, of course, has already been breached and the resulting credentials stolen and distributed within criminal marketplaces. The process itself is highly automated, with one login attempt after another executed using credential pairing upon credential pairing.
Some of these bot-driven attacks are pretty sophisticated, employing rotating IP addresses and simultaneous login attempts in an attempt to circumvent rate-limiting and IP-blocking defensive measures. It’s easy to think of these as a type of brute force attack, but it’s more of a brute slamming one.
It slams the target service with actual credential pairs whereas brute force attacks have no known credentials and instead rely upon the use of random strings and common passwords. The critical difference, at least from the customer perspective, is that credential-stuffing attacks are way more successful than the no-context brute force ones.
How to avoid credential stuffing attacks
I would guess the average reader uses a password manager and isn’t in the habit of sharing login credentials between multiple accounts. The average user, however, is a different case. I checked with my password manager of choice, 1Password, and I currently have just shy of 300 unique and random passwords stored within it. Nobody could remember all of those, not even if you had an ingenious password construction method.
Unless that ingenious method isn’t quite as secure as you think. Any form of password iteration is a no-no, as is using the service name in the password string. Not only do I not need to remember my passwords, I only actually know one of them; the password manager master password. And that’s not even a password; it’s a long passphrase that a combination of muscle memory and remembering the first two words ensures it’s easy to recall when needed.
Anatomy of identity-based attacks
Helping security teams mitigate identity-based attacks
Because I’m fast approaching “old fart” status, I also have a 1Password emergency kit safely stashed away where nobody could easily find it, in case I did forget. Keeping such a thing written down isn’t as weak a security measure as you might think. The chance of someone breaking into your home and then finding it, if they did, is highly unlikely. A lot less likely than reusing the same passwords between multiple accounts. Yet that’s precisely what so many people do, and it’s why credential-stuffing attacks are not only increasingly popular but increasingly successful as well.
The mitigation is simple: use a password manager. Doing so can give you a double protective whammy, as it happens because you can also have random and unique usernames for accounts that don’t insist on your email address. If an account does, then you can simply set up unique email addresses using Gmail, for example. I’m quite a fan of using Apple’s Hide My Email feature with my iPhone, as this generates random and unique emails for logins that redirect to your actual email.
Was PayPal to blame in any way?
For what it’s worth, I’m not letting PayPal off the hook here. While technically, this wasn’t a breach, it was a security incident because such a large number of accounts were accessed. PayPal should have measures in place to shut down such a concerted credential-stuffing attack before it ever achieves the scale of success it did in this case.
Although PayPal hasn’t, at the time of writing, disclosed much detail regarding the timeline and the technical measures employed, I feel pretty confident in saying the company fell short of what I’d expect such a large player in the financial sector to achieve in terms of security.
The small matter of not sharing your passwords across sites and services apart, the easiest way to stop credential stuffers from being successful is the use of multi-factor authentication (MFA). Ironically, PayPal has such protections available, but it’s up to each customer as to whether they enable it. I’d argue that for all services, but particularly those in the financial sector, mandatory 2FA should be the norm.
What’s more, as I’ve already said, questions need to be asked as to how a large-scale attack such as this, and you have to assume that if 35,000 accounts were successfully accessed, then a much larger number of logins would have been attempted but failed, could not have been shut down more promptly. For this credential stuffing attack to continue across three days suggests to me that a review of relevant incident detection and response processes needs to be undertaken sharpish.
