The shared responsibility of credential stuffing
If your account falls victim to a credential stuffing attack, whose responsibility is it ?
Drawing a parallel from the shared responsibility model of cloud service providers like AWS, credential stuffing attacks have a not so well defined responsibility model. Whose responsibility is it if your account on a hosted provider gets breached ?
Well if it was LastPass you know the answer. LastPass was compromised and attackers got hold of credentials. The responsibility for protecting your account data, is on LastPass. LastPass was compromised, so the answer is simple, not your fault.
We conclude then: If you don’t host your data, and your account gets compromised, then the responsibility is with the vendor that hosts your data. This isn’t groundbreaking it happens already in the retail banking system — in the UK — and with GDPR.
The responsibility the banks have when it comes to retail fraud, in the UK is called “The Quincecare duty”. The Quincecare duty originated from Barclays Bank plc v Quincecare, in which case the courts decided that the bank has a duty of care to refrain from executing fraudulent payments on the behalf of their customers. Here’s the definition from Thomson Reuters’ practical law:
It essentially consists of an implied term and a co-extensive duty of care owed by the bank to its customer to refrain from making or executing a payment when the bank is put on inquiry that a payment instruction from its customer may be a result of fraud.
We also have GDPR — in the EU — which introduces a duty on all organisations to report certain personal data breaches to the relevant supervisory authority, within 72 hours of becoming aware of the breach.
Our logic isn’t unfounded, and we have precedence. The vendor that hosts my data is responsible for the security of the data.
Adversaries launched a credential stuffing attack to Norton Password Manager, here’s their statement:
“Our own systems were not compromised. However, we strongly believe that an unauthorized third party knows and has utilized your username and password for your account[…]”
Quote from bleeping computer.
Your account was compromised, but it wasn’t the Norton Password Manager systems that got breached, it was your account — according to Norton.
GM has a similar stance, from malware bytes:
“Based on the investigation to date, there is no evidence that the log in information was obtained from GM itself. We believe that unauthorized parties gained access to customer login credentials that were previously compromised on other non-GM sites and then reused those credentials on the customer’s GM account.”
For what it’s worth, I’m using these incidents as examples. Companies take this stance when it comes to credential stuffing attacks. Worse, some of them don’t detect, warn or admit it.
Well let’s start with understanding what credential stuffing attacks are and how they work. I’ve written about credential stuffing attacks in the past but let me recap.
If you are using the same password in more than one website you are most likely going to fall victim to a credential stuffing attack.
Chances are someone is going to try and log in with these credentials on the an insurance provider, a bank, or Netflix. A different service that the one that your credentials — username and password — were compromised. Once logged in, the attacker knows that these credentials work for this website. That’s all it takes, a single login that can be reused in other services.
The combination of your username and password — credentials — became a commodity that will be sold in the equivalent of an underground market. The price that your credentials will be sold is based on your region, type of accounts, and markets where the credentials will be listed. Your Netflix account for example might go for just over a a dozen USD for a year.
It’s the same principle as having one key — a skeleton key — that opens all doors. If a thief gets a hold of it, they can access your car, and your house.
Eventually your accounts can be sold separately, en masse, or bundled with millions of other credentials. Sometimes the credentials are being sold under the pretense of “account sharing”.
And it’s not always invite-only forums on the “dark web”. Go to your favourite consumer-to-consumer marketplace and search for a subscription. You’ll most likely find someone “sharing” one with you, for a very low price. They just so happen to have about 50 more of these.
Back to our original question.
The vendor that hosts our data notifies their customers that the account they hold with them was breached, it was a credential stuffing attack. Who is responsible?
Following with our key metaphor from earlier, it’s reasonable to think of your credentials as your “property”. Your password is your data.
If your account gets compromised one way or the other, the vendor — should— have a duty of care to protect, warn and deter you from falling victim to a credential stuffing attack. It’s your data that gets compromised. This isn’t different to a GDPR breach notification. We shouldn’t pass the blame to the user, en masse, and by default.
And if you’re looking for a technology panacea to solve this problem, maybe PassKey is the answer. Apple, Google, and others have now agreed on a new and secure way of authenticating users to websites.
This is fundamentally a lot more secure as it stops attacks like credential stuffing and phishing on their tracks. “Hosted” PassKey has been built is such a way that even if your iCloud or a Google server that has your PassKey gets compromised, the attacker wouldn’t be able to access them.
