Hacker News Reader

Comment by lisper | Hacker News Reader

> Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses

Why is it not sufficient simply to throttle logins at the server?

Modern cred stuffing is done by botnets. When I see a cred stuffing attack, it's maybe 1-3 attempts per IP address spread over 100-500k IP addresses. Often you'll have a family of legitimate users behind an IP address that's cred stuffing you at the same time.

Throttling by IP address may have worked 10 years ago, unfortunately it's not an effective measure anymore.

Modern cred stuffing countermeasures include a wide variety of exotic fingerprinting, behavioral analysis, and other de-anonymization tech - not because anyone wants to destroy user privacy, but because the threat is that significant and has evolved so much in the past few years.

To be entirely honest, I'm kinda surprised Google didn't require javascript enabled to log in already.

Any advice on where to read more about these modern cred stuffing countermeasures? I'd love to learn more.

A relatively successful company in the area is Shape Security. Their marketing is a bit painful, but they invented the concept of cred stuffing. Disclaimer: I worked there for four years.

Unfortunately I don't have much reading material to provide. It's a bit of an arms war, so the latest and greatest countermeasures are typically kept secret/protected by NDA. The rabbit hole can go very deep and can differ from company to company.

The most drastic example I can think of was an unverified rumor that a certain company would "fake" log users in when presented with valid credentials from a client they considered suspicious. They would then monitor what the client did - from the client's point of view it successfully logged in and would begin normal operation. If server observed the device was acting "correctly" with the fake login token, they would fully log it in. If the client deviated from expected behavior, it would present false data to the client & ban the client based on a bunch of fancy fingerprinting.

Every once in awhile, someone will publish their methods/software; Salesforce and their SSL fingerprinting software comes to mind: https://github.com/salesforce/ja3

This is a rare paper published on the topic.

https://link.springer.com/chapter/10.1007%2F978-3-319-07536-...

Fundamentally it's a question of fingerprinting the behaviours of humans versus bots. The problem is that it's becoming increasingly difficult to distinguish them, particularly when bots are running headless chrome or similar, and real users are automating their sign-ins with password managers.

I don't do much of this sort of thing, but numerous things come to mind. Aim to identify and whitelist obviously human browsers, blacklist obviously robot browsers, and mildly inconvenience/challenge the rest.

For example, an obvious property of a real human browser is that it had been used to log in successfully in the past. Proving that is left as an exercise for the reader, though it inevitably requires some state/memory on the server side.

A company I am considering investing into: https://fingerprints.digital/

Are they looking for funding? They appear to be privately funded.

They have been at https://www.wolvessummit.com/ - they are preparing for a funding round. You can find them at other events listed on their page: https://fingerprints.digital/event/

But you don't have thousands of families logging in from thousand of different servers: in your case a max of 10 login attempts would prevent it.

Throttle based on what? IP address? This works for domestic IT departments looking to shut out automated attempts from specific ranges but at Google's scale IP based filtering could end up shutting out an entire country.

Which country uses a single IP address for all its devices/citizens?

China Telecom does something weird with NAT, not sure what exactly but I've seen it mentioned here before

All of Qatar's traffic used to be routed through 82.148.97.69, though that was back in 2006-2007. At one point it was banned from Wikipedia, which unintentionally affected the whole country.

https://simple.wikipedia.org/wiki/User_talk:82.148.97.69

> Throttle based on what?

User Id?

With credential stuffing, isn't it unlikely the perpetrator wants to make more than one or two attempts per user ID?

That's the first obvious countermeasure and will prevent hackers targeting a specific account. But there are other ways to crack passwords, one is to try the same password but iterate over user ids instead. As hackers would start with the most common password you can't throttle globally on same password attempts either because well yeah, it is by definition the most commonly used one which should have a lot of traffic.

Google can ban common passwords, or passwords that look like they’re being targeted (over the long-run).

This has nothing to do with anything but I don't know how else to get in touch with you. Could you upload your zero spam email setup guide somewhere? Your site was hacked so the link I had doesn't work:

http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/

I’m sorry, I changed the domain to QasimK.io, but neglected to set up forwarding. I will do that.

http://qasimk.io/2016/absolutely-zero-email-spam/

That would create an easy denial of service attack: if I wanted to deny you access to your account I'd spam it with bad login attempts.

Happens weekly to my Sears account.

"Credential stuffing" as I've heard it used refers to taking username/password combos from one breached site and trying them in other sites.

So for example LinkedIn has a breach, which reveals to evildoers that user 'johnsmith@example.com' uses the password 'smith1234' then they test that username and password in Amazon, Netflix, Steam and so on.

They only make one attempt per account, because they only have one leaked password per account. Hence, throttling per account isn't an option.

That's a terrible idea. Back when MSN was one of the most common instant messengers, there was a common prank that was called "freezing" where you just continuously kept trying to log into someones account and it would lock itself out for 15mins or more depending how long you kept doing it.

There was automated tools that did this too!

Reply on news.ycombinator.com