Protecting against gmail dot trick in Discourse

Why wouldn’t he use it? I am not following. It fixes his attack problem.

In which case maybe the best place for it is marketplace ?

Better a third party breaks it than an “official” plugin?

It would never be an official plugin, just a 3 liner in my GitHub account if Jeff deems he wants it today.

It breaks email login for a bunch of legitimate accounts. Including my very email account on gmail.

Yes but I don’t think you use his site.

A certain number of civilian casualties are acceptable when you are at war. So what if 2% of users can’t sign up, when you’re being overwhelmed with thousands of fake-plus-addressed emails every day? It’s like cloudflare “I’m under attack” mode. Some legit people won’t get in. That’s the price you pay for the stricter security.

Your argument is that cloudflare “under attack” mode is not perfect therefore it should not exist :man_shrugging:

At any rate I would need to see 2 more legit reports of this being a large scale problem before moving on it.

Forgive me if something obvious escaped me, but wouldn’t it be easier to add reCAPTCHA to the registration screen?

These are usually human spammers. There are quite a lot of them now compared to 2010. Captchas do nothing against a human adversary.

「いいね!」 1

Ok…I thought this kind of “gmail dot and +” registration was mostly done by bots …

「いいね!」 3

A lot of genuine real humans use sharklasers et al (which use this) to sign up to our site because they don’t want their username attached to their real life person. It’ll depend per circumstance.

OP can set 15m read time as a trust req to posting and first 5 posts needing approving by staff with 0 edit rights and his issue I would wager disappears immediately.

「いいね!」 1

One thing I would certainly like to confirm here is that we have reasonable rate limits for account registrations.

A single IP address should only be allowed to register N accounts per day. But we need some sort of bypass / site setting here for cases where NAT causes a big pile of users to share IP.

I prefer . be normalized for google, however +somthing remain as is. So perhaps if you’re going to do this, let admins choose what they want.

「いいね!」 1

That’s already the case… the problem here is it is Mossad. They have lots and lots of IPs to use.

「いいね!」 1

I am seeing rate limiters on:

  • email login per hour
  • update activation email
  • resend activation email
  • list second factors
  • enable totp
  • admin login

Not seeing any specific rate limit on account create short of the standard built in rate limiting per IP.

Curious if @markersocial can install data explorer and list registration ip address for the swamp of users that registered. I want to know for sure they are coming from 100 IP addresses vs just 1.

「いいね!」 2

I would like to agree, but Google has this problem. At the least University where I worked you couldn’t have a class sign up for Gmail because the university has all access from a single NAT.

I suspect that a NAT whitelist would solve most real world problems, as it’s probably predictable where legitimate users are coming from.

Default to a small (or configurable) number of IPs per day seems pretty safe to me.

@sam - Regarding the IPs, confirming that i do use registration + log in IP limiting and have a large banned IP list. I can assure you that it isn’t users creating significant amounts of accounts on the same IPs, I wish it was, then it would be possible to block. The only way to block them currently is blacklisting all gmail sign ups.

@codinghorror There is a non-illegal service that will give you access to xx,xxx,xxx unique IPs for $xxx per month. So it’s easy for anyone to get heaps of IPs, not just Mossad :wink:. There are lots of other legal services also offering large pools of IPs, then there are illegal rent-a-botnet services.

「いいね!」 6

I would definitely upgrade to latest, at a minimum scripts to do this bonanza are going to be much more annoying to write given my latest challenge/honeypot changes

Also please give us regular updates here, so we can learn more

Is this still going on right now?

「いいね!」 5

Great thanks @sam and sorry I didn’t follow up on this yet.

Yes it still seems quite viable to make a lot of accounts using this trick (2.5.0.beta1).

For example, using the username+{randomstring}@gmail.com trick, someone created 748 accounts in the last 10hrs. They already have thousands of accounts on this single gmail address.

Pretty much the only way for me to be able to remove them from the admin area is manually going to each account individually to suspend and/or delete them. It’s not very viable because the guy can pretty much just press a button and make a lot more accounts. :drevil:

They pretty much seem to have an unlimited supply of IPs, so IP bans/limits are pretty much futile in this case.

Also, still consistently getting quite a lot of registrations using the gmail dot and + tricks.

Cheers!

「いいね!」 3

重複する Gmail アカウントのサポートを無効にするサイト設定の追加を支持します。技術的には、その設定を追加する作業は 15〜30 分で完了します。

「いいね!」 4

@sam さん、ありがとうございます。追加で役立つ情報を含む PM を送りました。

長年の経験から言うと、ほとんどの自動スパムボット(すべてではありませんが、圧倒的多数)は同じ「HTTP_USER_AGENT」文字列を使用しています。IPアドレスを偽装できるスパムボットの一部でも、同じ「HTTP_USER_AGENT」を使用しているか、あまりに不自然で検出が容易なものを採用していることが多いです。

その理由は、多くのボマーやスパマーが単にボットスパムソフトウェアをダウンロードして実行するだけで、実際に何をしているのか理解していないからです。もちろん例外はありますが、99%以上のスパムボットは、それほど専門知識を持たないスパマーがダウンロードして実行するスクリプトやプログラムに過ぎません(一般的に、彼らはコーディングの巨匠ではありません)。

実際、これらの「HTTP_USER_AGENT」文字列は非常に明白な場合さえあります。理論上はあらゆる対策を回避できる可能性はありますが、実際には当フォーラムでは数十年にわたり、他のフォーラムに比べてスパム問題は極めて少なくなっています。これは、メールアドレスをさまざまな基準に基づいてスコアリングし、明らかなものを拒否しているためです(モデレーションは行わず、スコアが一定の閾値【信頼レベル】を超えた場合は登録を即座に拒否します。なぜなら、スパムの大量データベースをモデレーションしたい人はいないからです)。また、多くの理由から Akismet は使用していません(何年も前から)、しかしこの話題から脱線したくはありません :slight_smile:

一方、旧vBulletinフォーラムでは、これらはすべてPHPプラグインで容易に実装でき、リアルタイムで修正し(そして善戦し)ることができます。かつてはベイズ分類器を使用こともありましたが、長年の経験を通じてより良い方法を見つけました。さらに、クッキーを使用し、クッキーポリシーを受け入れ(当社のプライバシーポリシーに従ってクッキーを許可する)クライアントからの登録のみを許可する方法も採用しています。もちろん、ユーザーが登録した後にもクッキーを読み取り、複数のログインを検出するために使用することも可能です。正直なところ、これでほとんどのスパムボットを阻止できます。これはロケット科学ではなく、一般的に「IPアドレスベースのみ」というわけでもありません。

また、参考までに、ほとんどのスパムボットはクッキーを受け入れないため、クッキーを許可しないクライアントをブロックするだけでも効果が大きいです。

「賢そう」に聞こえるかもしれませんが、私は20年以上この分野に携わり、このテーマに関する学術論文も発表し、この分野でリアルタイムのサイバー戦争を戦い、リアルタイムのサイバー防御およびスパム対策技術において20年近い実務経験があります。したがって、私が何を話しているのか理解しています。もしこのような機能がDiscourseアプリに用意されていない、計画されていない、あるいは簡単に実装できない場合でも、私の返信を過度に厳しくブロックしないでください。よろしくお願いいたします。

すべての人、特にユーザーを支援しようとする専門家に対して、包括的でありましょう。

では、Cheers。

「いいね!」 2

…30 秒後…

:wink: