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 
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 
. 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 إعجابات
شكرًا جزيلاً يا @sam، وآسف على عدم متابعتي لهذا الأمر بعد.
نعم، لا يزال يبدو من الممكن جدًا إنشاء العديد من الحسابات باستخدام هذه الحيلة (2.5.0.beta1).
على سبيل المثال، باستخدام حيلة username+{randomstring}@gmail.com، أنشأ شخص ما 748 حسابًا في آخر 10 ساعات. وقد يمتلك بالفعل آلاف الحسابات على عنوان Gmail هذا الواحد.
الطريقة الوحيدة تقريبًا التي تمكنني من إزالتها من منطقة المسؤول هي الذهاب يدويًا إلى كل حساب على حدة لتعليقه و/أو حذفه. هذا ليس عمليًا جدًا لأن الشخص يمكنه ببساطة الضغط على زر وإنشاء المزيد من الحسابات. 
يبدو أنهم يمتلكون تقريبًا إمدادًا لا نهائيًا من عناوين IP، لذا فإن حظر IP أو وضع حدود له يكون عديم الجدوى تقريبًا في هذه الحالة.
أيضًا، لا يزال هناك عدد كبير جدًا من التسجيلات باستخدام حيلتي النقطة (+) وعلامة الزائد (+) في Gmail.
مع أطيب التحيات!
3 إعجابات
أؤيد إضافة إعداد للموقع @codinghorror يُعطل دعم حسابات Gmail المكررة، تقنيًا، إضافة هذا الإعداد تستغرق من 15 إلى 30 دقيقة.
4 إعجابات
شكرًا لك يا @sam - أرسلت لك رسالة خاصة تحتوي على بعض المعلومات الإضافية التي قد تكون مفيدة~
تستند تجربتي الواسعة مع هذا الأمر على مر السنين إلى أن معظم روبوتات البريد العشوائي الآلية (وليس جميعها، لكن الغالبية العظمى) تستخدم نفس سلسلة ‘HTTP_USER_AGENT’. وحتى بعض روبوتات البريد العشوائي التي يمكنها تزوير عناوين IP غالبًا ما تستخدم نفس سلسلة ‘HTTP_USER_AGENT’ (أو تستخدم شيئًا زائفًا لدرجة يسهل اكتشافه).
السبب هو أن معظم قاذفي القنابل ومرسلي البريد العشوائي يجلبون ببساطة بعض برامج البريد العشوائي الروبوتية ويشغلونها دون أن يعرفوا حقًا ما يفعلونه. نعم، بالطبع هناك استثناءات، لكن 99%+ من روبوتات البريد العشوائي هي مجرد نصوص/برامج يشغلها مرسلو بريد عشوائي ليسوا على درجة عالية من التعقيد، والذين يقومون بتحميلها وتشغيلها (فهم ليسوا عمالقة في البرمجة، بشكل عام).
في الواقع، تكون سلاسل ‘HTTP_USER_AGENT’ هذه واضحة جدًا أحيانًا. بالطبع، من الممكن نظريًا هزيمة كل شيء، لكن عمليًا على منتدياتنا عبر العقود، واجهنا مشاكل بريد عشوائي قليلة جدًا (مقارنة بمنتديات أخرى) لأننا نقوم بتقييم عناوين البريد الإلكتروني بناءً على معايير مختلفة ونرفض تلك الواضحة (لا نقوم بمراجعتها؛ فعندما تكون الدرجة أعلى من عتبة معينة {مستوى الثقة}، نرفض التسجيل ببساطة، فمن يريد مراجعة قاعدة بيانات كبيرة من البريد العشوائي؟ لا أحد). أيضًا، لا نستخدم Akismet لسبب وجيه من الأسباب (لسنوات عديدة)، لكنني لا أريد الخروج عن الموضوع في هذا الشأن 
ومع ذلك، في منتديات vB القديمة لدينا، يتم كل ذلك بسهولة في إضافة PHP سهلة التعديل (ومكافحة الشر بجد) في الوقت الفعلي. في وقت ما استخدمنا مصنف بايزي، لكنني وجدت طرقًا أفضل على مر السنين. كما استخدمنا ملفات تعريف الارتباط (Cookies) ونسمح بالتسجيلات فقط من عميل قبل سياسة ملفات تعريف الارتباط (ويقبل ملفات تعريف الارتباط، وفقًا لسياسة الخصوصية الخاصة بنا)، وبالطبع، يمكننا قراءة ملف تعريف ارتباط بعد تسجيل مستخدم واستخدامه للكشف عن تسجيلات الدخول المتعددة. هذا يوقف معظم روبوتات البريد العشوائي، بصراحة. الأمر ليس معقدًا مثل الصواريخ، ولا يعتمد بشكل عام “فقط على عنوان IP”، بصراحة.
أيضًا، للمعلومية، لا تقبل معظم روبوتات البريد العشوائي ملفات تعريف الارتباط على الإطلاق، لذا فإن مجرد حظر العملاء الذين لا يسمحون بملفات تعريف الارتباط يساعد كثيرًا.
لا أريد أن أبدو “ذكيًا” جدًا، لكنني أقوم بهذا لأكثر من عقدين، ولدي أوراق بحثية منشورة في هذا المجال، وخضت حروب سيبرانية في الوقت الفعلي في هذا المجال، ولدي أكثر من 20 عامًا من الخبرة في الدفاع السيبراني في الوقت الفعلي وتقنيات مكافحة البريد العشوائي، لذا أعرف تمامًا ما أتحدث عنه؛ لذا أرجو ألا تكون قاسيًا وتحجب ردّي إذا لم تكن هذه الوظيفة متاحة، أو مخططة، أو قابلة للبرمجة بسهولة في تطبيق Discourse، شكرًا لك.
لنكن شموليين للجميع، وخاصة الخبراء المستعدين لمساعدة المستخدمين.
تحياتي.
إعجابَين (2)
… بعد 30 ثانية …
