3 ms·

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

PaoloBarbolini 1mo ago
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...
econ 1mo ago
Maybe if the number of failed logins per hour grows by 10000%
gruez 1mo ago
>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.
- JoshTriplett 1mo ago
  > 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.
  - gruez 1mo ago
    >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.
    - GoblinSlayer 1mo ago
      For credential stuffing you need only one attempt.
      - gruez 1mo ago
        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.
        GoblinSlayer 1mo ago
        They have so many accounts broken daily? Then credential stuffing attacks are not prevented.
      - olyjohn 1mo ago
        Then you don't need to automate it, and you can just manually solve the captcha and log in.
    - bellowsgulch 1mo ago
      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.
  - nisegami 1mo ago
    >How do you prevent credential stuffing attacks? Passkeys or magic links seem like the way forward here.
    - hombre_fatal 1mo ago
      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.
      - account42 1mo ago
        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.
        hombre_fatal 1mo ago
        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.
      - nisegami 1mo ago
        Isn't that essentially a manual passkey?
    - JoshTriplett 1mo ago
      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".
      - nisegami 1mo ago
        >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.
  - vablings 1mo ago
    Passkey only. No passwords no usernames just passkey
    - olyjohn 1mo ago
      At the minimum, stop using goddamn email addresses for the login.
    - Plont 1mo ago
      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.
      - vablings 1mo ago
        Two passkeys. If you lose two then yeah, you are boned don't do that. They are absolutely the superior solution
- iambenm 1mo ago
  Rate limiting
  - hombre_fatal 1mo ago
    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.
- toomuchtodo 1mo ago
  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.
  - Plont 1mo ago
    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.
    - toomuchtodo 1mo ago
      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-security/google-passkeys-update-april-2024/ 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-password-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)
dpifke 1mo ago
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/part-316/section-316.5 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.

PaoloBarbolini 1mo ago

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

econ 1mo ago

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

gruez 1mo ago

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

JoshTriplett 1mo ago
> 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.
- gruez 1mo ago
  >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.
  - GoblinSlayer 1mo ago
    For credential stuffing you need only one attempt.
    - gruez 1mo ago
      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.
      - GoblinSlayer 1mo ago
        They have so many accounts broken daily? Then credential stuffing attacks are not prevented.
    - olyjohn 1mo ago
      Then you don't need to automate it, and you can just manually solve the captcha and log in.
  - bellowsgulch 1mo ago
    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.
- nisegami 1mo ago
  >How do you prevent credential stuffing attacks? Passkeys or magic links seem like the way forward here.
  - hombre_fatal 1mo ago
    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.
    - account42 1mo ago
      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.
      - hombre_fatal 1mo ago
        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.
    - nisegami 1mo ago
      Isn't that essentially a manual passkey?
  - JoshTriplett 1mo ago
    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".
    - nisegami 1mo ago
      >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.
- vablings 1mo ago
  Passkey only. No passwords no usernames just passkey
  - olyjohn 1mo ago
    At the minimum, stop using goddamn email addresses for the login.
  - Plont 1mo ago
    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.
    - vablings 1mo ago
      Two passkeys. If you lose two then yeah, you are boned don't do that. They are absolutely the superior solution
iambenm 1mo ago
Rate limiting
- hombre_fatal 1mo ago
  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.
toomuchtodo 1mo ago
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.
- Plont 1mo ago
  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.
  - toomuchtodo 1mo ago
    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-security/google-passkeys-update-april-2024/ 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-password-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)

dpifke 1mo ago

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/part-316/section-316.5 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.