Hacker News Reader

Comment by DownGoat | Hacker News Reader

> Why make me solve a Captcha to see static content?

Fair point, I usually run into this when using Tor, or VPN when accessing content behind Cloudflare, and or similar services. This is some anti abuse stuff, but is often overly agressive with giving you captchas.

> Why make me solve a Captcha to log in when I've already completed one to register?

So attackers cannot password spray. This is typically after attackers has gotten access to the latest database breach, and are just blindly trying username/password combinations.

> Why make me solve a Captcha to pay utility bills? Is there some underground group of deviants going around surreptitiously paying other people's utility bills?

Sound like a strange place to have a captcha indeed. What information is needed in the form to submit it? Does it validate stuff that an attacker might want to scrape? I guess they added it for a reason.

View on HN

> I guess they added it for a reason.

This is not necessarily a reasonable assumption. People often do things because they heard it was a good practice, or because it solves a problem they don't actually have, but think they might, or arbitrarily without giving it much thought.

So attackers cannot password spray. This is typically after attackers has gotten access to the latest database breach, and are just blindly trying username/password combinations.

A simple ratelimit takes care of that. Plus, it's not like attackers would be easily defeated by a CAPTCHA anyway --- there are services selling batches of valid tokens, likely generated by actual humans or very close emulations thereof, for ReCAPTCHA.

Rate limit by what? IP? Botnet traffic will originate at random IPs.

By the account. 3 failed login attempts in a row, and you disallow further logins for 30 seconds.

This should waste less time than reCAPTCHAs. I know it's not 1:1 in terms of pros/cons, but it gets a good subset of the advantages without the key disadvantages mentioned above.

So I can lock you out of your account with 3 attempts from any IP address?

For a minute usually. Prevents flooding. Not a bad approach unless the account is constantly hit. In those cases two factor auth makes sense.

This is obviously a bad idea. It costs nothing for an attacker to send 3 http requests, every minute, every hour, all day. They could lock your account basically forever. IP filtering and locking accounts are terrible ways of preventing password spraying.

First, that's a bit user-hostile (and suddenly a DoS-vector; I can prevent a site's users from logging in by continuously firing bad password attempts).

Secondly, botnets can, and presumably do, randomize which accounts they try, too.

So rate-limiting is "user-hostile", but permanently hell-banning someone because their network is considered "seedy" is user-friendly?

Incidentally, you still need rate-limiting if you use Google's CAPTCHA. If you don't rate-limit CAPTCHA endpoint, an attacker can DDoS you (especially if your server-side captcha component uses low-performance single-threaded HTTP client). Furthermore, an attacker within the same AS as their target can purposefully screw over their account by performing attacks on Google's services until the reputation of the network hits rock bottom.

reCAPTCHA is a rate-limiting measure. Google handles all the heavy-lifting and attacker protection for you, and the slow fade you see in the video is that rate-limiting in action. But if you get a clean CAPTCHA result back from them, then that client is very unlikely to be an automated attacker. It's super easy and scales really well.

Conveniently, normal users with typical browser configurations get nothing but the animated checkbox. For nearly everyone, the whole experience is simple and easy. The only people who get inconvenienced are the low-grade privacy enthusiasts who think that preventing tracking is the path to Internet safety. Ironically, "tracking" is literally the mechanism by which legitimate users can be distinguished from attackers, so down that road lies a sort of self-inflicted hell for which the only sensible solution is to stop hitting yourself.

so down that road lies a sort of self-inflicted hell for which the only sensible solution is to stop hitting yourself.

"Be a good little sheeple and do what Big Brother Google says." Fuck no.

> By the account. 3 failed login attempts in a row, and you disallow further logins for 30 seconds.

...congratulations, I just locked out all of your users. Have a nice day.

How did you get the email addresses of all my users, which are used as login name?

From that messed up email from support that leaked them. Or I assumed that you'll have a big cross-section with some other site that leaked.

This is not theory, this is hard-earned experience. Locking-out people is bad, the most that's acceptable is rate limiting to a once every few seconds.

CAPTCHA is not a fool proof, it is just the first layer in of defence in the signup/login form. CAPTCHAS increases the cost of password spraying, attackers can't simply fire up Hydra. They'll need additional tools and services which costs money.

Captcha solving service also has other costs than just the money it costs. It adds time costs and additional resource usage on the machines it is running on. A quick look at a service[1] shows that the average response for a challenge was 40 seconds (this value changed a lot when refreshing the page). The attacker has now gone from the 200ms range per attempt to several seconds, slowing the down a lot. This gives defenders additional time to respond, it is also a useful metric for detecting malicious logins.

[1] https://anti-captcha.com/mainpage

> > Why make me solve a Captcha to pay utility bills? Is there some underground group of deviants going around surreptitiously paying other people's utility bills?

> Sound like a strange place to have a captcha indeed. What information is needed in the form to submit it? Does it validate stuff that an attacker might want to scrape? I guess they added it for a reason.

Ive seen captchas on payment forms to prevent credit card checking. You can take a dump of CC details and try them all out on a site and get back the valid ones. I'd assume they charge $1 to the CC to test it before allowing you to continue and then you could cancel your order before they charge the full amount. However, assuming you have to be logged in to pay your bill that seems less reasonable.

I've even seen people beat captcha in bulk to get to a payment form. My best guess is something along the lines of mechanical turk or a room full of low wage workers doing it manually. I think the payoff of verifying stolen cards is worth enough to justify some kind of workaround.

If you host a payment form that informs the user about whether payment was accepted, you're a target.

In the past, I used curl to get some billing info, add the money to a dedicated virtual prepaid card, then pay the bill, then send an email to a gmail (+paidinvoice) label. These day, at least for my bills, they have pre-approved withdraw directly from the bank. However I guess this is not widely deployed.

If other people did this, but ended up doing it from an insecure machine and lost the credentials / got hacked, I can see why at least some orgs might want to prevent people from doing this. This is a classic over reaction, but a plausible scenario.

> If other people did this, but ended up doing it from an insecure machine and lost the credentials / got hacked, I can see why at least some orgs might want to prevent people from doing this.

The measure is not really about protecting the user that is using the payment form, it is meant to "protect" the system that is validating the payment data. The payment form may be a target for attacker which has gotten a large batch of credit cards from somewhere else, and wants to validate the data. They then regularly exploit such forms, or other naive payment system to check if the credit card data is valid.

CandyJapan owner wrote some blog posts about the subject.

https://www.candyjapan.com/behind-the-scenes/how-i-got-credi...

https://www.candyjapan.com/behind-the-scenes/candy-japan-hit...

https://www.candyjapan.com/behind-the-scenes/fraudulent-tran...

My electric company requires one to login - but only after a the browser session expires and I have to login again anyway.

> So attackers cannot password spray.

My password's not crackable, so it's annoying to be lumped in to that. I'd happily use a service-generated password to avoid login hassles.

I imagine what you are proposing then is to record the entropy on the password when you first register and for accounts with sufficient password entropy to not ask for a captcha after few failed attempts.

With that, the site gives away whether the account has a low entropy password or not.

> I imagine what you are proposing then is to record the entropy on the password

Or just generate secure high-entropy passwords and force users to use them.

Making users look up SMS codes before each login is acceptable. Making them solve obnoxious, long, privacy-hostile riddles is acceptable. But forcing them to use pre-generated secure passwords?! That can't possibly work. They will revolt!

> With that, the site gives away whether the account has a low entropy password or not.

Sure, why not? Way more than half of passwords are low-entropy, so that doesn't meaningfully help them focus attacks.

And they still have to keep solving captchas to make those attempts.

Reply on news.ycombinator.com