Present a captcha screen (or similar) before creating new accounts to prevent SPAM and bot attacks

[felipebueno]

Hi!

When I was implementing the login with magic link feature on the Stacker News app, I used a lot of e-mail aliases for tests. I noticed that for every new alias I used to log in, Stacker News would consider that to be a new account.

I think that is a problem because it'd allow a motivated attacker to easily create many accounts that could be used to send spam, "steal" all good nyms available, DoS attacks, etc.

On the other hand, this could also be a feature, allowing stackers to create multiple legitimate accounts, for legitimate reasons. When using e-mail aliases, they could pay for new accounts or have a limited number of linked accounts.

Steps to Reproduce Request a magic link using e-mail aliases multiple times (eg: myemail+sn@example.com and then myemail+21@example.com and then...).

[ekzyis]

I think that is a problem because it'd allow a motivated attacker to easily create many accounts that could be used to send spam, "steal" all good nyms available, DoS attacks, etc.

Claiming a lot of nyms is already possible with lightning logins or with nostr login (#334). When we see people using this as an attack vector, I think we can demand a small payment to "activate" an account. But so far, this didn't seem to be a problem.

But I don't see what you mean with spam or DoS attacks. Do you mean someone could easier spam by using multiple accounts? They would circumvent the fee escalation but still would have to pay for each post or comment. What did you mean with DoS attacks? Which service could be denied by creating a lot of accounts?

[felipebueno]

What did you mean with DoS attacks? Which service could be denied by creating a lot of accounts?

I don't know. Filling up the database by requesting millions of magic links using only one legit e-mail account, then make the script to "click" the links to login and activate the account, start a session for each account, than making the script to use those accounts to post free posts seems an easy starter. Maybe this would cause a DoS or, if the infrastructure scales automatically, massive bills.

[ekzyis]

Hi @felipebueno, thanks for bringing this up and sorry for the delayed response! We appreciate that you have considered this potential attack vector and notified us. We had to discuss this internally first which we did now. What follows is our conclusion:

---

We don't see how e-mail aliases are the problem here. As mentioned, creating an unlimited amount of accounts would still be possible using lightning or the upcoming nostr logins. That would probably also be easier to automate compared to the magic links. With the magic links, an attacker may be rate-limited by how many mails they can receive. With lightning or nostr, there is no such limit. It's all just between the attacker and us, no SMTP in between.

But we don't think that's a problem. In fact, we consider it to be a feature that people can create an unlimited amount of accounts without any verification by us required. This makes our site more accessible and respects privacy of users so that's a trade-off we are willing to make.

We protect our site from spam using micropayments, a trust score (which limits visibility of new accounts) and fee escalation (if you post too much too fast, it will cost you more). However, we have enabled unlimited free posts for all accounts a while ago. So anyone can already post for free as long as they don't post too fast to trigger fee escalation.

So an attacker could circumvent this fee escalation by creating multiple accounts and leverage this using automation, yes. That's an issue we do see but again, we don't see how this is solved by removing e-mail aliases. Maybe you can reconsider and rename this ticket?

Also, we think you are overestimating the impact on our infrastructure from posting free stuff. No expensive operations are triggered by this. So we also don't see how this could impact our infrastructure such that the site goes down or that the infrastructure scales up. Additionally, any attack that uses this vector is easy to detect and easy to shut down. It's easy to detect since it requires a session so the attack is identifiable by session. It's easy to shut down since we have a lot of options to chose from. Some examples:

1. Be more aggressive with fees / disable free posts. This could even be targeted to only mostly impact the attacker accounts by checking the account creation date and/or the amount they posted within a longer period of time than the current fee escalation considers.
2. Kill the session of attacker accounts
3. Ban attacker IP(s) (basic anti-DDoS procedure)
4. Ban attacker accounts (making the nym free to claim again)

We will not close this ticket for now since we are still interested in your opinion on this. Is there something we missed? Or do you agree with us now that this is not something we have to consider to be a "serious" attack vector? Maybe you can rename this ticket since as we see it, it's not inherently about e-mail aliases but more about the risks of allowing free posts?

Let us know what you think :)

[felipebueno]

Hey, @ekzyis !

Some quick notes on your answer:

sorry for the delayed response!

No problem, man!

We don't see how e-mail aliases are the problem here. As mentioned, creating an unlimited amount of accounts would still be possible using lightning or the upcoming nostr logins. That would probably also be easier to automate compared to the magic links. With the magic links, an attacker may be rate-limited by how many mails they can receive. With lightning or nostr, there is no such limit. It's all just between the attacker and us, no SMTP in between.

hmm yeah, you are right. I forgot about login with lightning and nostr. They make this kind of attack much easier.

Also, we think you are overestimating the impact on our infrastructure from posting free stuff. No expensive operations are triggered by this. So we also don't see how this could impact our infrastructure such that the site goes down or that the infrastructure scales up.

I didn't put too much thought on that yet so, yeah, I may be overestimating the impact but I can see filling up the database with rubbish having a negative impact on the infrastructure.

Additionally, any attack that uses this vector is easy to detect and easy to shut down. It's easy to detect since it requires a session so the attack is identifiable by session. It's easy to detect since it requires a session so the attack is identifiable by session.

The attack I described on https://github.com/stackernews/stacker.news/issues/355?notification_referrer_id=NT_kwDOAAOud7E3MDU2NjQ3OTQyOjI0MTI3MQ#issuecomment-1634675089 would not create only one session but N sessions so that would make it harder to parse attackers from legit new accounts.

It's easy to shut down since we have a lot of options to chose from. Some examples:

2. Kill the session of attacker accounts

I think that would be difficult to do because of the N sessions problem.

3. Ban attacker IP(s) (basic anti-DDoS procedure)

Good! It would at least slow down the attacker as he's would have to try DoS over ToR to perform some kind of low bandwidth DoS attack.

I was wondering... Asking the user to solve some kind of captcha challenge before creating the account would solve most (if not all) of the problems we listed above, wouldn't it? The problem now would be to find a captcha provider that respects privacy.

[felipebueno]

We will not close this ticket for now since we are still interested in your opinion on this. Is there something we missed? Or do you agree with us now that this is not something we have to consider to be a "serious" attack vector? Maybe you can rename this ticket since as we see it, it's not inherently about e-mail aliases but more about the risks of allowing free posts?

Yeah, I'm starting to agree that it's more an annoyance than a serious attack vector and maybe it could be solved using some kind challenge-response test (captcha or something like it).