Hackers account for 90% of login attempts at online retailers | Hacker News Reader

Hackers account for 90% of login attempts at online retailers

qz.com

101 pointsjsoverson64 comments

I don't buy these numbers at all. 90% seems stupid high for retail. From the report,

"[...] 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 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.

A single source of abuse can easily tilt login statistics.

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.

Why would you think 90% is high? That's only 9 in 10. Remember, attackers using dictionary attacks are going to be trying hundreds or thousands of log in attempts, and a real user is only going to try at most a handful of times.

You don't need that many attackers to easily approach 99% or higher. I'd say 90% is likely conservative for some companies.

I think 90% is high for a few reasons:

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.

1) Proxies and botnets obscure origin and make attacks appear globally distributed so basic rate limiting has little effect on these attacks.

2) Extrapolated averages on incomplete data are certainly suspect, they are meant to be taken with a grain of salt and are most applicable to people in the affected industries for them to validate against their own data. FWIW The highest percentage of malicious, automated traffic that I've seen has been 99% which, yes, is crazy and should sound unbelievable.

3) Noted, definitely. It is certainly a tough number to nail down because it is very dependent on all the things you mention. I trust our data because we've been at this the longest, were the earliest, and we see a lot of the unadulterated attack traffic that has gotten through many existing defenses so we see the stark difference on day one.

Disclaimer: I contributed to the report in question (but was not consulted or related to the posted article)

Most legitimate users will also not have to log in each time they visit, making the ratio even less surprising.

I think an important thing is that you should consider that attackers will log in at the maximum rate limit allowed. The traffic may even be greater than the rate limit, and they'll have some requests dropped by the server. But it still represents and attempted login regardless.

So, yes, even with rate limiting, you can still easily hit 99% fradulent attempts. Obviously you'd be foolish to actually process all of those, and likely the attackers would realize they were rate limited and would slow down for their own best interest, but it's not a guarantee that they actually do obey the rate limit.

A large entailer in the UK that I’ve done PCI work for 3 years ago had simmilar figures in the mid 80%, that accounts for all attempts not successful ones.

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.

Data point of one incoming. I work in ecommerce. 90% seems stupid low, based on our data.

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.

I'll add another data point, from the consumer telecoms industry. 90% feels way too high from what we had to head with, even prior to implementing rate-limiting and other defences.

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-...

I worked at a very large e-commerce player, these numbers jive with my experience. Most people have their password saved in their browser, or get it right the first time. Maybe they screw up a few times, whatever. They may even have to reset, but they are in now, and you won't see a bad attempt from them for awhile.

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.

I recently joined a website the did away with passwords, the only way to login was to enter your email address and confirm by pressing a link in the email, while this adds a pain point for customers it offloads most security implications onto the email provider.

While this will work a very large proportion of the time, and has a big benefit of offloading security as you mention, email is fundamentally asynchronous and can be affected by issues outside of your (and the email providers') control.

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.

> email is fundamentally asynchronous

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.

Passwords can already universally be recovered through email. I wish ALL sites had this feature. It's essentially a one time password, that expires.

Exactly. The only password that really matters is the one for your email. Everything else just provides additional attack vectors.

That only works for services that do not store any sensitive data and employ costumer controller encryption, if your password is used as a cryptographic tool then it’s out of the question to use such mechanism.

Then how would you be able to reset your password? All I'm saying is that any service that allows password resets shouldn't have passwords at all.

Whatsapp has figured out a solution to this problem. i.e. what is your Whatsapp password?

Your telephone number. So instead of something you know (password), they use something you have (phone).

Yeah, but be careful never to use an email that you might lose access to (which in principle, could be any email).

What's the difference? They'll just recover your passwords either way. Secure your email password, use two factor authentication. Now you're more secure than just about any website you're using.

Well, for example if you're a student and you have you@your.edu, you might lose access to that account after you graduate.

And providers like GMail can ban your account without warning or recovery options.

Same issue applies if you forget your password to any site.

How does that deal with email providers that follow all links with their virus scanner? (many corp emails...)

Usually these credentials are one-time usage.

"Click to continue" Javascript on the landing page, IME. Or a time-based limit, which seems more user-friendly: if you close the tab you can reopen it or go back to your email.

I'd guess however any service that requires account confirmation to work.

This sounds like a solved problem, though I don't really know.

Not everyone as solved it. It is an actual issue that people have.

No I mean that seeing how widespread click-to-confirm emails are I'd think there are best practices for how to implement them to avoid fake clicks. Whether those ideas are followed by everyone is another story, but all the pitfalls that people are pointing out apply in one way or another to the password system as well.

You could also remove that customer pain point by auto-verifying them without checking their email for the very first time they login, and it would expire after they close their browser or 1 hour, whatever comes first.

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.

I also do this with websites I make. It is a little inconvenient, but it's worth it, assuming the person logging in as a secure way to access their email (2 factor auth).

It is a lot inconvenient, given the various and myriad issues with guaranteeing email deliverability. Multiple hosting providers use greylisting or something like it which can delay email by minutes to hours, depending on the behavior of the sending mail server. Almost all hosting providers use one or more layers of spam filtration which can incorrectly trap or dispose of your message. Many users have additional mailbox rules set up which may accidentally match your message and route it to an unexpected folder. Relatively small mistakes with things like SPF can further complicate deliverability. You may also use some popular mail delivery service or another, which means that when that service has a bad customer that annoys enough other system administrators, the entire service gets blackballed, your messages along with it. (Hi, SendGrid.)

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.

Can you expand on your preference for SMS password resets to email password resets? As a user I prefer email, but I'm biased by the fact that I used email for a decade before I had SMS and I've had a malicious actor gain control of my phone number and receive SMS on it but never had the same with email.

Sure, it's basically just down to those problems with email deliverability. As you correctly point out, SMS isn't a perfectly secure solution either; however, I almost always receive an SMS for authentication within a few seconds to a minute, and only in a few cases have never received the message at all.

If text messages were abused to the degree that email is, and all kinds of different things were developed to try to "solve" that abuse (as has happened with email), then deliverability would suffer and it would be a coin toss for which approach to use.

Would you please elaborate how someone took over your phone & sms? This is my nightmare..

That's a bold assumption, depending on your audience.

But as others have said either way email is an attack vector because it's often used for account recovery, this way at least it's a lot clearer who is in charge of security, it's the user and the email provider (whether they like it or not).

Unfortunately, that doesn't imply that the site is secure either. An attacker could also try to brute force the link, though it's likely more secure than most passwords at least. But if the link is not expired, the attacker could still eventually get in.

The only thing that implies security is an airgapped (even that is debatable) or powered off computer.

This makes sense given how often they'd fail. When I log in it takes me one attempt. When someone is using stolen credentials they might have to make hundreds of attempts before actually logging in.

The ratio is waaaay higher for ssh login attempts.

That, and most websites remember your computers forever so you rarely ever need to log back in.

I wish. If that were the case, there would be almost zero market for 1Password, Keychain, and a dozen other solutions.

My Macy’s account was hacked just this week. I got an email that my shipping address changed, and I logged in and saw several hundred dollars worth of pending items in the shopping cart.

Any time I start an ssh server for myself on a publicly accessible IP, hackers account for roughly 100% of login attempts. The legit logins are in the noise, and dictionary attacks on username and password fill the logs. With decent passwords, it's not much concern, but nowadays, I disable password logins completely.

My experience is the same. I set up a VPN for a coworker, who used it on 3 separate weeks away, connecting in total maybe 30 times. There were several MB of logs detailing illegitimate connection attempts.

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?

I see a ton of attempts on my server that has SSH on a non-standard port. I imagine they don't all run port scans and I'd see even more on port 22.

This has to do with affiliate schemes. Payouts for them are quite solid.

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.

It's far more than affiliate schemes. Credential stuffing attacks result in account takeovers for many different types of companies and the value that can be extracted is different for each business.

Article doesn't talk about what they're doing to mitigate the problem. Well, except tell the reader to change their passwords. So are online retailers just hoping the problem goes away?

They have to balance user attention and user friction. Online retailers want your purchase to be as smooth as possible. There's some studies on how someone won't spend much time on a website if it loads slow. The same can apply to purchase decisions. They need it as impulsive as possible. So annoying things like 2 factor authentication, in their mind, might make a customer give up their purchase.

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.

Makes sense, nobody like slow pages. However, don't most people have the browser save their password? So couldn't the online retailer have some sort of exponential delay (to a limit) after so many failed attempts? Surely that would affect few real customers.

What is being delayed? Just an IP address or the entire account? Neither really work.

The only way I see this problem going away is when regular retailers start supporting software and hardware two factor authenticators.

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.

Agreed, but keep account recovery in mind.

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.

I'd like to get you started on SMS 2fa. I deal with this a lot at work and would like as much information as possible!

SMS is terribly insecure. Using it as a security system is a bad idea.

SMS verification is more for discouraging bots from making accounts by making it expensive--you need to buy a cell phone. Every SMS verification system refuses to send to VoIP type accounts for this reason.

Couple this with the fact that mobile services are also subject to credential stuffing attacks constantly and, for the services that allow you to read SMS messages online, the attackers who take over your mobile account also gain a critical piece of your 2FA protection.

Exactly that's why I have disabled my Google email recovery via phone number. Only possibilities are Auth via an existing signed-in device, Google Auth, or backup codes.

I always save that TOTP Token or QR code in my seperate keepass database, so that if my Google Auth app breaks for any reason, I can install it fresh & re-scan those QRs from keepass.

On our site, for an unknown reason almost 80% of the hacked accounts used are with @outlook, @hotmail, @live, etc domains. Does not look like they got the credentials from a massive leak. Issue with that, is that the hacker deletes our warning/advice emails. Not a funny situation to handle. Any idea about the source?

Only 90%?

Reply on news.ycombinator.com