Tag: Register

Problem

Consider a standard sign-up form (user enters an email address, we send a confirmation link).

Even limiting that form per IP (or even globally per hour), I’m concerned about abuse:

Our real-world reputation would be harmed if someone enters plenty of (publicly known) email addresses of companies in our geographical vicinity, leading to unsolicited welcome-mails. This could even harm our SMTP reputation (if the recipients flag those mails as spam, or could it not?).

We’d always be one step behind the attacker when blocking addresses/domains (who then could not sign up any more if they wanted to later) and might even have to deal with confused or frustrated people calling us.

Proposed mitigation

Instead of a sign-up form, the user sends an email to hello@our-company.com and then we reply with the confirmation link to that From address.

What this achieves

From a technical viewpoint, reliably spoofing emails of multiple different companies requires more technical skill than filling out a form (I’m aware of the limitations of SPF, but still.)

More importantly though, we’d be in the position to tell the victim that someone actively impersonated them. This shifts the (emotional) blame to the attacker rather than just apologizing for us “not getting our sign-up form secured properly”.

The attack would become tangible because we can present the spoofed email to the victim, rather than an abstract server log showing the POST form-request. It would even mean that the victim might have to take action to secure their email (with SPF or whatever).

My question

I think reliably spoofing emails of multiple different companies is harder than just submitting POST requests.

Is that true and is my proposed scheme sensible? I have never seen this in the wild.

Final thoughts

I was inspired to this approach when I learned that the SCTP handshake forces the client to remember the initial state (rather than the server) to avoid SYN-flooding. I assume that it is generally desirable that the client has “more work” than the server.

Someone could object that the end-user has no email-client at hand right now to send an email (inconvenience). But I think that’s OK, because the user would have to open the mail and confirm the link anyway at some point. And while talking with someone on the phone it’s even easier to say “send an email to hello@” instead of “go to this website, find the form, sign up).

I’d like to avoid captchas (plus, they don’t solve the problem).

Thank you for your time.

Answers to questions

If people mostly register using Gmail or Microsoft 365, I reckon SPF would pass most of the time, as opposed to small companies registering using their custom domain-email-setup lacking SPF.

If the SPF-check fails, I could at least limit the amount of registrations where SPF fails or I could have an employee double-check (before or after the registration). This would also give us an opportunity to tell the customer that they should improve their email setup (we’re in the safety/security business). This could even be done in an automated comment in our outgoing email.

Result

It was very hard to accept one answer, because every answer had a gold nugget in them. I took the one that A) made clear that a new attack vector opens, B) that people are used to spam and C) even on signup an employee could be notified at once.

Thank you to the others for giving good general advice.