Hacker News Reader

Comment by prirun | Hacker News Reader

I've used vultr.com for years with no problems. Recently it wouldn't let me login without solving a Google captcha. I tried private windows, etc and ended up having to cancel my Vultr account and ask for a refund. Fortunately I only used them to spin up test VMs and didn't have any production stuff running there.

I refuse to pay a company for service and then be required to identify motorcycles and traffic lights every time I sign in. I went a few rounds with Vultr customer service and they said (paraphrasing) "It's not something we can fix, you have to talk to Google about it". Right... Google forced you to put their captcha on your web site.

View on HN

CAPTCHA for login should just be outright illegal, especially if it blocks important functionality like closing your account.

A few years ago a service for which we had just implemented a scraper for (they had no API, and the customer needed info from 1000s of accounts) added a captcha right after we had implemented the scraper.

We quickly figured out that the server didn't validate the captcha challenge code with Google. It worked for 3 years until they changed the system to send a code via email to validate your login, and limiting you to 1 session at-a-time. Now we have different problems to deal with...

Maybe if the number of failed logins per hour grows by 10000%

>CAPTCHA for login should just be outright illegal

How do you prevent credential stuffing attacks?

>especially if it blocks important functionality like closing your account.

That just falls under standard tort law, not to mention recent "click to cancel" legislation some states have been introducing.

> How do you prevent credential stuffing attacks?

CAPTCHAs don't work anymore, at this point. AI can trivially solve them.

Rate-limit the number of attempts, test accounts against known-password lists like HIBP, and support 2FA.

>CAPTCHAs don't work anymore, at this point. AI can trivially solve them.

The point is to raise the cost, not to create some impenetrable barrier. A $5 vps can make hundreds of requests per second. IP bans and rate limiting forces people to use residential proxies, which are like $5/GB. That's much more expensive, but still cheap. Not sure about the token cost of AI is like, but captcha solving service used to charge around $0.002 per solve, which increases costs even more.

For credential stuffing you need only one attempt.

No, it's a numbers game on both sides. Attackers are after hundreds or thousands of accounts, not just one. Defenders knows that exactly 0 hacks are impossible to achieve, and they're just trying to limit losses from fraud, but also costs from anti-fraud.

They have so many accounts broken daily? Then credential stuffing attacks are not prevented.

Then you don't need to automate it, and you can just manually solve the captcha and log in.

There is no raised cost anymore. Every professional doing this work has perfect alignment with regular consumer heuristics.

OS, browser, fingerprinting, networked bytes, residential address spaces.

All of it is done.

>How do you prevent credential stuffing attacks?

Passkeys or magic links seem like the way forward here.

You can also randomly generate a password for the user on the form they'd normally type one in on registration. Add a "Regen" button to give users more visceral control over it before they submit the form.

That's essentially the same as magic links because most users won't remember/save that password and will have to rely on the usually email-based reset flow.

Sure, but this subset of user was going to otherwise reuse their password and be susceptible to cred-stuffing.

The point is to stop the attack and prevent users from accidentally hosing themselves.

Isn't that essentially a manual passkey?

Please don't. I find such services obnoxious, especially when they aggressively log you back out. Chasing down a link in your email is much slower than having your password manager fill in the long unique random password and hitting "log in".

>Chasing down a link in your email is much slower than having your password manager fill in the long unique random password and hitting "log in".

That's basically a passkey without its special API.

Passkey only. No passwords no usernames just passkey

At the minimum, stop using goddamn email addresses for the login.

I'm not giving up recovery codes, nor my ability to default to locking out people who physically have my device. I usually don't allow auto-login or biometrics login either.

If a website/app goes passkey only (or, even worse, if it starts relying only on one-time email codes), I won't use it.

I know plenty of others who feel the same, though I don't know if we're numerous enough to put a dent in a company's bottom line or not. I imagine it depends on the company and its target audience.

Two passkeys. If you lose two then yeah, you are boned don't do that. They are absolutely the superior solution

Rate limiting

Attacks have been distributed for quite some time if your service has any loot worth attacking. You have to handle the case where every request comes from a unique IP address.

Passwordless and passkeys. There are no credentials to stuff. Login with magic link, email OTP, passkey, etc. Get rid of the password, rate limit what remains.

Email OTP is garbage without the option to also add a password. That just outsources the problem to the user's email service, and assures that compromising the email inbox alone is enough to immediately also compromise every service that uses passwordless, 2FA-less "magic link" or OTP login.

Email services don't even support true 2FA; many claim to, and ask for a 2FA code for web login, but connecting an email account to a client via POP or IMAP bypasses that.

I implement customer identity and access management for millions of users in financial services, based on requirements driven in part by US federal regulatory and cyber insurance requirements. What’s your experience?

> Email services don't even support true 2FA; many claim to, and ask for a 2FA code for web login, but connecting an email account to a client via POP or IMAP bypasses that.

"In less than a year, passkeys have been used to authenticate people more than 1 billion times across over 400 million Google Accounts. Passkeys are easy to use and phishing resistant, only relying on a fingerprint, face scan or a pin making them 50% faster than passwords. In fact, on a daily basis passkeys are already used for authentication on Google Accounts more often than legacy forms of 2SV, such as SMS one-time passwords (OTPs) and app based OTPs (such as Authenticator apps) combined."

https://blog.google/innovation-and-ai/technology/safety-secu... (April 2024)

Don't forget: Microsoft is killing passwords. How to set up a Microsoft passkey before August deadline. - https://mashable.com/article/microsoft-passkey-how-to-passwo... - June 20th, 2025

(All major email providers support either passkeys, or in the case of Microsoft, passwordless ["strong authentication"]; we can consider the user creating an app specific secret for an external mail client minimal risk if performed after strong authentication has occurred, as the odds are low of that secret being phished or exfiltrated once configured in their mail client of choice, for the few folks interested in such a user experience with web based email services)

But passkeys are not supported natively (i.e. without a USB key or other shenanigans) by Firefox on Linux, as there is no place to store them. I do have a USB key, but it's annoying enough that I don't like passkeys if I can avoid them (instead using long randomly-generated passwords by Firefox's builtin-in password manager).

Maybe Lennart needs to write systemd-passkeyd .

I admit this is a gap, but this use case is a rounding error at the scale of users and daily logins. If someone wants to fix this, drop a link to sponsor the time and tokens needed to enable native support. Does a Yubikey or secure authenticator work for your use cases currently?

Yes, a yubikey works for when I really need it, but it's enough friction to take out out and plug in that it's just annoying enough.

I'll talk to some industry folks and see what we can do.

I never got a response when I wrote to the FTC, requesting formal guidance as to whether having to disable NoScript (a browser security measure) to complete a CAPTCHA to unsubscribe from email spam satisfies 16 CFR § 316:

"Neither a sender nor any person acting on behalf of a sender may require that any recipient pay any fee, provide any information other than the recipient's electronic mail address and opt-out preferences, or take any other steps except sending a reply electronic mail message or visiting a single Internet Web page"

https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C...

A simple reading says, no. But I guess they don't want to put that in writing.

Ok, debian forky, 155.0.1, successfully logged into vultr.com after a year inactive, added a credit card and a little credit. I do, however, still stupidly use google authenticator for 2FA. The captcha was just a checkbox.

That said I have run into a number of unsolvable captchas lately on firefox. Had to use chromium on a healthcorp insurer site.

The captcha is not just a checkbox, it's recaptcha.

I don't mind a checkbox. I don't even mind the "proof of work" types that take 10 seconds extra. But identifying traffic-y things over and over is way too much for me. I did do one screen, thinking it would let me in, but it just gave me another.

I do use Firefox. And I couldn't cancel my account myself: had to request it via email since I couldn't login. They were good about doing it right away and said they issued a refund for the balance.

I've had this for a few months trying to log into https://console.vultr.com/...

It does it for me if I use a VPN (Mullvad) - if I don't use a VPN then I haven't noticed I get them.

But yeah, very annoying.

Most captchas are invisible as long as they like your IP and device. But they still do the fingerprinting in the background.

Reply on news.ycombinator.com