Ask HN: What to do about random email sign-up attacks?
I run a web app where people can sign up using their email address. Nothing unusual:
They input an email address, we send confirmation email, they click on that confirmation to continue the sign-up flow.
The challenge that I have been recently facing is that some bad actor(s) input other people emails. The bad actor cannot do anything with this since they do not have access to the email accounts. However, the problem is that those random people are now blasted with what is effectively spam. This is damaging to my service reputation because it appears like I am sending unsolicited emails.
The IPs, user-agents, etc. are all different. There is an element of sophistication to how this is executed.
It is the first time that I am dealing with this at a meaningful scale and I cannot think of what's a good way to counteract.
10 comments
[ 3.0 ms ] story [ 35.1 ms ] threadAlso adding some fraud detection on top might help (e.g. MaxMind) you can tell if the requests are coming from a proxy, hosting service, etc and block those requests or present them with additional challenges.
You could enable social sign-on (Google, Facebook, etc) and disable sign up by email.
You could rate limit sign ups based on IP address, including a captcha (though it sounds like they may work around this).
You could use a waf like cloud flare and hope it distinguishes bad actors.
You could shut off new sign-ups or turn them manual for a time (make folks submit a form and add them yourself if you can verify they are interested) to make yourself a more painful target.
Not a lot of easy options, though.
Unique username and password has worked since forever. If you need a 3rd gate, "something you have" is good enough - hardware based 2FA (not TOTP).
If I were being targeted in this manor I would flip the transaction around. I would generate a long random-like email address on my website using an email specific domain that is temporary but tied to the person logged in. To activate it they would email that address with a code from the application they received whilst signed in. On that email specific domain I would validate and enforce FCrDNS, DMARC and SPF and probably also use SpamAssassin to get a spam score from all the RBL's and RSL's, then do something with it. There is also greylisting and prompt delays that can be configured to break some bots. Oh, and if the sender does not have SPF+DMARC enforcing you could just outright reject it anyway if so desired.
In this mail-list-like model, no emails are sent from my servers. The attacker has to spoof their victim which is harder to do now with DMARC, SPF, SA, SR25 regex, etc... Their proxies and cell phone farms become their own hindrance. It can still be done to people that do not have those measures in place, but it makes for a new conversation with the abuse complaint and gives the attacker more work to do.
It's unfortunate that RSS is not in all the browsers any more.
How would you use RSS in this case?