[JimDabell]

> If you’re sending transactional emails like password resets or MFA, then the emails will have close to a 100% open rate.

So I can disable a competitor’s email functionality by triggering a whole bunch of password reset requests for all discoverable usernames?

[renewiltord]

If they support SMS 2FA they need to be prepared for this too because it costs a lot. Yeah, so people need to ensure that reset is at least a little hard to abuse. After all, it's a bad experience for their users if they receive a shit ton of reset emails anyway.

[Breza]

Can confirm that last part. I get so many Facebook reset messages, it's a bit ridiculous.

[jcrites]

That could potentially cause them problems, yeah, if you were able to do that endlessly. In practice most companies will have some kind of rate limiting in place around features like that (by IP, cookie, captcha, etc.)

[JimDabell]

IP and cookie-based rate-limiting are trivially bypassed. In fact, any kind of rate-limiting is ineffective here, especially for smaller organisations, because you only need to generate a small fraction of the traffic they normally send out. If they separate transactional mail from other types of mail (something that is frequently recommended), then how many illegitimate password reset emails do you think an attacker needs to trigger to get to, say, a 5% failure rate? Smaller organisations don’t send out an awful lot of transactional email.

[jcrites]

True, but modern CAPTCHA rate limiting is not easily bypassed, and a lot of the solutions are free.

Together with cookies, you can show the captcha only to visitors that are not already recognized in some way, giving them a limited number of actions before showing the captcha. And regardless of whether you want one on your password reset page, you almost certainly want one on your login page anyway.