"[...] we rely on data from the Shape Network. Across the US, Shape’s customers represent: [..] 40% of Mobile Retail (by in-store payments)."
"We estimated the number of credential stuffing attacks using the total number of credential stuffing attacks observed on Shape’s US customers and the total proportion of the US industry our customers represent."
I'm really wracking my brain how they're measuring their marketshare of retail. Mobile retail as measured by in-store payments? Can someone explain that to me?
Bottom line, this data comes from a company whose value proposition is that they sit between your company's servers and your clients and filters bad requests for you.
Bottom line, this data comes from a company in a unique position to see all inbound logins on a large number of e-commerce web sites that random HN cynic can't.
FTFY.
In a recent compromise that I assisted on, the attacker tried 9,000 different credentials before landing on something that worked. This is on a relatively small site that has maybe 100 legitimate logins per day. On larger, more attractive sites, the ratio would only increase as you'd have multiple concurrent attackers trying everything in their combos lists.
We've since built out a small pile of software to detect and prevent this and similar kinds of abuse. It's not yet SOP for small ecommerce sites, but it should be.
...or just use Shopify and let them deal with it.
You don't need that many attackers to easily approach 99% or higher. I'd say 90% is likely conservative for some companies.
1) Rate limiting of login attempts takes a bite out of the large numbers you're talking about. If we are only looking at retail companies without rate limiting, well, duh, I guess >90% makes sense, but I expect a large portion of the global e-commerce retail segment _does_ employ rate limiting of logins.
2) The report lists, "Averages derived from customers’ login traffic before Shape Enterprise Defense was deployed on login applications" - so this is absolutely a biased sample. These are clients that signed up for help stopping this problem.
3) It bugs me how ambiguous the report is about how they aggregate to 90%. I worry it's a simple [total fraudulent logins] / [total login attempts] across all their client retailers, which will be heavily biased by the retailers that don't have login limiting, and doesn't really describe the situation. A much better number I'd like is the median percentage of fraudulent logins attempts across retailers.
Another anecdote is that even non-compromised accounts that were not regularly used had on average 4 failed attempts before a successful login with password recovery used in more than 50% of these cases, to the point where the majority of all login attempts were failed attempts.
The “compromised” accounts were identified by using information form fraud detection services and accounts that did not complete a password recovery after multiple failed attempts as well as a few other indicators.
While I understand your skepticism you need to understand just how common this issue is.
When hackers/fraudsters get any set of credentials from a leak or phishing they try it on 100’s if not 1000’s of sites multiply it by the number of fraudsters and hacking groups that sell login details in bulk and it’s essentially the spam of the internet world.
A couple years ago we were seeing a dozen or so successful login requests per minute against a background of ~40 unsuccessful requests per second.
We were forced to implement rate-limiting on logins, which has resulted in more than a few customer service headaches. But it's now the reality of online retail.
We ended up tracking actors as they switched up their techniques to evade us and our defences, and ended up learning a lot about credential stuffing, the tools involved and some of the motives behind them attacking lesser-known websites. We ended up blogging about our findings, should anyone else have to deal with this cat and mouse fun: https://breachinsider.com/blog/2017/credential-stuffing-how-...
Then you have Mr. Hacker, who is just going to spam the crap out of you until you actively stop him. If he is not so smart, he will go all in and try to brute force you from a single box as fast as he can. Smarter guys will rate limit themselves, even smarter guys will use botnets and VPNs. At this point time is on their side, they can just spray and pray, and even diversify their attempts by not just focusing on amazon.com, but hitting amazon, then target, then ebay, etc... you can now still be making whatever number of attempts per second, but fly under the radar (hopefully) of rate limiters and such.
Rate limiters and other counter measures help, but the point is that the bad guys are going to just keep trying and trying, while typical user flow is at most a few attempts. These attacks are almost always from overseas, particularly Russia, and so they have little fear of consequences.
Another point that UX designers might make is that this solution necessarily takes users away from your site to complete login, and that can introduce a place for users to drop off. I'm not sure it's that significant, but I've heard it used as an argument.
Yes, but this affects your recovery attempts as well, today email is basically instantaneous for most people.
> this solution necessarily takes users away from your site to complete login
This is probably the biggest reason to avoid this solution, but I still like it over other options.
Usually these credentials are one-time usage.
This sounds like a solved problem, though I don't really know.
It's really no less secure than allowing someone to sign up with an email / password and let them in without first confirming their email address.
DigitalOcean's two-factor authentication used email, and email only, which several times caused us some headaches when there was an urgent issue and our person-in-charge couldn't access the account.
I've had a system administrator role for multiple companies over almost 15 years now. I've yet to see a perfectly reliable email system.
Doing password resets over email is one thing (though I think SMS is still better). At that point, the individual no longer has access to their account anyway, and you're dealing with a much smaller number of impacted users. It's much worse to throw up your hands and say, "I don't want to deal with passwords, let's use email", especially now that there are so many good password-handling libraries for so many different development environments and numerous articles on proper password handling.
It makes me curious what's really going over the wires and airwaves we love to hate for their low capacity and high cost. How much of that traffic is junk?
Clickfraud people, I think, count on the the fact that for huge e-retailers, it takes months to take action, and they can cashout affiliate payouts faster then they react.
So things are insecure because that's what customers want to satisfy their relatively low attention spans and impatience. And the retailers optimize for that.
I use Google Authenticator on any website that supports it and it does not impact the customer experience at all and it really improves security.
Account recovery is a major pain point for any site that supports TOTP 2FA. If you're not using a TOTP application that supports cloud backup (like Authy), when you lose or replace your mobile device the existing TOTP tokens are useless as they can't be recovered. This results in some type of account recovery process to reintroduce the 2FA tokens. Often these recovery processes introduce additional security issues that are equivalent to not supporting 2FA at all, or they might require costly human intervention.
Don't get me started on SMS 2FA.
