Add reCAPTCHA or similar?

[paulstraw]

Hey @rauchg, as you're aware, (sorry about that, by the way), it's pretty easy for someone to run a script that will generate a ridiculous amount of invites. The attack on slashrocket's instance of slackin caused ~14k total invitations to be sent out.

Would you be opposed to the idea of adding some sort of human verification system? I'm happy to implement this and submit a PR if you want, just wanted to make sure you were cool with it/if you had any thoughts.

[rauchg]

@paulstraw that seems like overkill? Perhaps it's better to do in-memory rate-limiting by ip just to get something going quickly?

One invite per ip max every 20 minutes?

[paulstraw]

Hmm, maybe I'm missing something, but reCAPTCHA is reasonably easy to implement, easy to use, and well-understood by end users. It seems like a more "proper" solution to my mind (it would also help prevent potential Slack spam). Is there any specific issue you see with it?

[paulstraw]

Another good point was just brought up: That would actually break the case where multiple people using the same internet connection wanted to sign up for a Slack in a short time period. In my experience, that happens fairly often in businesses etc. when news about a new relevant Slack is shared.

[rauchg]

@paulstraw let's do the rate limit, and a way to overcome it is to either wait or perform reCAPTCHA. Straight up reCAPTCHA is a net loss in terms of user experience, even if it effectively solves the problem.

[paulstraw]

Not to be a pain about this, but a rate limit still doesn't solve the potential issue of Slack spambots. reCAPTCHA is also generally very good about letting real people through without a hassle these days. Would you be okay with reCAPTCHA as an option, instead?

[rauchg]

Can you elaborate on the potential issue of Slack spambots, and how Slackin would prevent it?

[rauchg]

To be clear: what I'm trying to avoid here is hurting the initial UX of the regular person who just wants to join a Slack, by adding (a) new steps, (b) visual clutter and (c) another external script.

[paulstraw]

I totally understand and agree with wanting to keep things simple, but not at the expense of security. RE potential spam:

• We already know users can (currently) easily script the site to send out arbitrary invitations.
• Even with IP-based rate limiting, there's nothing stopping someone from using the same attack, but distributed.
• If it remains easy to generate an arbitrary number of illicit accounts, malicious users are eventually going to become savvy to that and create spambots that can automatically rejoin (which would also not necessarily be hindered by IP rate limiting). reCAPTCHA or something like it is a good first line of defense against that issue.
• Slack already has a somewhat tenuous relationship with these communities (and in fact, they emailed slashrocket with a "warning" after the Slackin incident the other night). It makes sense to do anything we reasonably can to make our end of that relationship solid.

[rauchg]

reCAPTCHA requires a signup in order to obtain an API key

It's safe to assume that a good % of people will launch Slackin without it. I still think we need built-in rate limiting, with an option to supply an API key to activate reCAPTCHA.

[paulstraw]

Slackin already requires a Heroku/Azure/other PaaS account, or manual setup….

I think this is important enough to justify adding an additional setup requirement.

[4xposed]

I do not like to add steps that disturb new users or brake the flow (like reCAPTCHA does), but I do have to agree with @paulstraw that it is what makes the most sense on this particular case.

When a script to exploit this is so simple and in a time when proxies are free and you can run the script pretty much anywhere a limit of requests based on IPs makes close to no sense.

Sure bypass reCAPTCHA is possible, but takes more effort than searching 'free proxy list' in Google.

[rauchg]

One click doesn't sound like too much effort considering the ROI of this hypothetical attack is really high: you just DM a bunch of users with links, and many will be likely to click them.

[paulstraw]

"One click" is just for humans. reCAPTCHA (theoretically, at least) prevents non-humans from ever submitting the form in the first place.

[rauchg]

I was pointing out that if the incentive is spam, you don't need full automation. If someone manually provisions the account by going through reCAPTCHA, it's still worthwhile.

That said, I'm ready to accept a PR that does the following:

• Adds an optional SLACKIN_RECAPTCHA_KEY env, and makes it available to Heroku et al
• Documents how to set up reCAPTCHA and the importance of doing so in the README

• Makes it so that the initial screen of slackin is un changed, and reCAPTCHA is only rendered as a second step:

  

[rauchg]

@paulstraw are you still interested in contributing this feature?

[paulstraw]

Yes. Not yet certain when I'll be able to get to it though.

[ghost]

Any updates on this? Has it been implemented?

[bmgdev]

looks like here: https://github.com/rauchg/slackin/pull/234

[groovecoder]

Seems like this has been implemented.