Protecting against gmail dot trick in Discourse

لماذا لا يستخدمها؟ أنا لا أفهم. إنها تحل مشكلة هجومه.

في هذه الحالة، ربما يكون أفضل مكان لها هو #marketplace؟

من الأفضل أن يكسرها طرف ثالث بدلاً من أن يكون الأمر عبر إضافة “رسمية”؟

لن تكون أبداً إضافة رسمية، بل مجرد ثلاثة أسطر في حسابي على GitHub إذا قرر جيف أنه يريد ذلك اليوم.

إنها تكسر تسجيل الدخول عبر البريد الإلكتروني لمجموعة من الحسابات المشروعة، بما في ذلك حساب بريدي الشخصي على Gmail.

نعم، لكنني لا أعتقد أنك تستخدم موقعه.

إن عددًا معينًا من الضحايا المدنيين مقبول عندما تكون في حالة حرب. فما الضرر إذا لم يتمكن 2% من المستخدمين من التسجيل، بينما تتعرض لآلاف رسائل البريد الإلكتروني المزيفة ذات العناوين الإضافية يوميًا؟ الأمر يشبه وضع Cloudflare “أنا تحت الهجوم”. لن يتمكن بعض الأشخاص الشرعيين من الدخول. هذه هي الثمن الذي تدفعه مقابل تشديد الأمان.

حجتك هي أن وضع Cloudflare “أنا تحت الهجوم” ليس مثاليًا، وبالتالي لا ينبغي أن يوجد :man_shrugging:

على أي حال، أحتاج إلى رؤية تقريرين شرعيين آخرين يُظهران أن هذه مشكلة واسعة النطاق قبل اتخاذ أي إجراء بشأنها.

سامحني إذا كان قد فاتني شيء واضح، لكن ألا يكون من الأسهل إضافة reCAPTCHA إلى شاشة التسجيل؟

هؤلاء عادةً ما يكونون مرسلي رسائل غير مرغوب فيها من البشر. يوجد منهم عدد كبير الآن مقارنةً بعام 2010. فاختبارات كابتشا لا تجدي نفعًا ضد الخصم البشري.

إعجاب واحد (1)

حسناً… كنتُ أظن أن هذا النوع من التسجيل باستخدام “نقطة وعلامة الزائد في Gmail” يتم بشكل أساسي من قبل الروبوتات…

3 إعجابات

كثير من البشر الحقيقيين يستخدمون sharklasers وغيرها (التي تستخدم هذا) للتسجيل في موقعنا لأنهم لا يريدون ربط اسم المستخدم بشخصيتهم الحقيقية. الأمر يعتمد على كل حالة على حدة.

يمكن لـ OP تعيين وقت قراءة 15 دقيقة كشرط للثقة للنشر، مع الحاجة إلى موافقة الموظفين على أول 5 منشورات، حيث لا يمتلكون أي حقوق تعديل، وستختفي مشكلته على الأرجح فورًا.

إعجاب واحد (1)

أود بالتأكيد تأكيد أمر واحد هنا وهو أن لدينا حدودًا معقولة لمعدلات إنشاء الحسابات.

يجب أن يُسمح لعنوان IP واحد فقط بتسجيل N حسابًا في اليوم. لكننا نحتاج إلى نوع من التجاوز أو إعداد للموقع في الحالات التي يتسبب فيها NAT في تجميع عدد كبير من المستخدمين تحت عنوان IP واحد.

أفضل أن يتم توحيد النقطة . لـ Google، مع الإبقاء على +شيء كما هو. لذا، ربما إذا كنت تنوي القيام بذلك، فاسمح للمسؤولين باختيار ما يريدونه.

إعجاب واحد (1)

هذا هو الحال بالفعل… المشكلة هنا هي الموساد. لديهم عدد كبير جدًا من عناوين IP للاستخدام.

إعجاب واحد (1)

أرى معدلات حدّ على:

  • تسجيل الدخول عبر البريد الإلكتروني كل ساعة
  • إرسال بريد تفعيل الحساب
  • إعادة إرسال بريد تفعيل الحساب
  • قائمة عوامل المصادقة الثانية
  • تفعيل TOTP
  • تسجيل الدخول كمسؤول

لم ألاحظ أي حدّ محدد لإنشاء حساب، سوى حدّ المعدل القياسي المدمج حسب عنوان IP.

أود معرفة ما إذا كان @markersocial قادرًا على تثبيت مستكشف البيانات وقائمة عناوين IP المسجلة لمجموعة المستخدمين المسجلين في المستنقع. أريد التأكد من أنهم قادمون من 100 عنوان IP مختلف وليس من عنوان واحد فقط.

إعجابَين (2)

أود أن أوافق على ذلك، لكن جوجل تواجه هذه المشكلة. على أقل تقدير، في الجامعة التي عملت فيها، لم يكن بإمكانك تسجيل فصل دراسي في Gmail لأن الجامعة تملك جميع الوصول من خلال NAT واحد.

أظن أن قائمة بيضاء لـ NAT ستحل معظم المشاكل الواقعية، حيث من المحتمل أن يكون من المتوقع معرفة مصدر المستخدمين الشرعيين.

يبدو لي أن الافتراض بحد أدنى من عناوين IP (أو قابل للتهيئة) يوميًا إجراء آمن إلى حد ما.

@sam - فيما يتعلق عناوين IP، أؤكد أنني أستخدم تحديدًا لعناوين IP الخاصة بالتسجيل وتسجيل الدخول، ولدي قائمة كبيرة لعناوين IP المحظورة. يمكنني أن أضمن لك أن الأمر لا يتعلق بمستخدمين ينشئون كميات كبيرة من الحسابات على نفس عناوين IP؛ لو كان الأمر كذلك، لكان من الممكن حظرهم. الطريقة الوحيدة لحظرهم حاليًا هي حظر جميع عمليات التسجيل عبر Gmail.

@codinghorror هناك خدمة غير غير قانونية توفر لك الوصول إلى xx,xxx,xxx عنوان IP فريد مقابل xxx دولار شهريًا. لذا، من السهل على أي شخص الحصول على أعداد هائلة من عناوين IP، وليس فقط الموساد :wink:. هناك العديد من الخدمات القانونية الأخرى التي تقدم أيضًا مجموعات كبيرة من عناوين IP، بالإضافة إلى خدمات غير قانونية لاستئجار شبكات البوت.

6 إعجابات

سأقوم بالتأكيد بالترقية إلى أحدث إصدار، فحتى لو كان الأمر يقتصر على كتابة السكربتات اللازمة لهذا الحدث، فإنها ستصبح أكثر إزعاجًا نظرًا للتغييرات الأخيرة التي قمت بها في التحديات/مصائد الحوسبة.

كما يرجى تزويدنا بتحديثات منتظمة هنا حتى نتمكن من معرفة المزيد.

هل لا يزال هذا مستمرًا في الوقت الحالي؟

5 إعجابات

شكرًا جزيلاً يا @sam، وآسف على عدم متابعتي لهذا الأمر بعد.

نعم، لا يزال يبدو من الممكن جدًا إنشاء العديد من الحسابات باستخدام هذه الحيلة (2.5.0.beta1).

على سبيل المثال، باستخدام حيلة username+{randomstring}@gmail.com، أنشأ شخص ما 748 حسابًا في آخر 10 ساعات. وقد يمتلك بالفعل آلاف الحسابات على عنوان Gmail هذا الواحد.

الطريقة الوحيدة تقريبًا التي تمكنني من إزالتها من منطقة المسؤول هي الذهاب يدويًا إلى كل حساب على حدة لتعليقه و/أو حذفه. هذا ليس عمليًا جدًا لأن الشخص يمكنه ببساطة الضغط على زر وإنشاء المزيد من الحسابات. :drevil:

يبدو أنهم يمتلكون تقريبًا إمدادًا لا نهائيًا من عناوين IP، لذا فإن حظر IP أو وضع حدود له يكون عديم الجدوى تقريبًا في هذه الحالة.

أيضًا، لا يزال هناك عدد كبير جدًا من التسجيلات باستخدام حيلتي النقطة (+) وعلامة الزائد (+) في Gmail.

مع أطيب التحيات!

3 إعجابات

أؤيد إضافة إعداد للموقع @codinghorror يُعطل دعم حسابات Gmail المكررة، تقنيًا، إضافة هذا الإعداد تستغرق من 15 إلى 30 دقيقة.

4 إعجابات

شكرًا لك يا @sam - أرسلت لك رسالة خاصة تحتوي على بعض المعلومات الإضافية التي قد تكون مفيدة~

تستند تجربتي الواسعة مع هذا الأمر على مر السنين إلى أن معظم روبوتات البريد العشوائي الآلية (وليس جميعها، لكن الغالبية العظمى) تستخدم نفس سلسلة ‘HTTP_USER_AGENT’. وحتى بعض روبوتات البريد العشوائي التي يمكنها تزوير عناوين IP غالبًا ما تستخدم نفس سلسلة ‘HTTP_USER_AGENT’ (أو تستخدم شيئًا زائفًا لدرجة يسهل اكتشافه).

السبب هو أن معظم قاذفي القنابل ومرسلي البريد العشوائي يجلبون ببساطة بعض برامج البريد العشوائي الروبوتية ويشغلونها دون أن يعرفوا حقًا ما يفعلونه. نعم، بالطبع هناك استثناءات، لكن 99%+ من روبوتات البريد العشوائي هي مجرد نصوص/برامج يشغلها مرسلو بريد عشوائي ليسوا على درجة عالية من التعقيد، والذين يقومون بتحميلها وتشغيلها (فهم ليسوا عمالقة في البرمجة، بشكل عام).

في الواقع، تكون سلاسل ‘HTTP_USER_AGENT’ هذه واضحة جدًا أحيانًا. بالطبع، من الممكن نظريًا هزيمة كل شيء، لكن عمليًا على منتدياتنا عبر العقود، واجهنا مشاكل بريد عشوائي قليلة جدًا (مقارنة بمنتديات أخرى) لأننا نقوم بتقييم عناوين البريد الإلكتروني بناءً على معايير مختلفة ونرفض تلك الواضحة (لا نقوم بمراجعتها؛ فعندما تكون الدرجة أعلى من عتبة معينة {مستوى الثقة}، نرفض التسجيل ببساطة، فمن يريد مراجعة قاعدة بيانات كبيرة من البريد العشوائي؟ لا أحد). أيضًا، لا نستخدم Akismet لسبب وجيه من الأسباب (لسنوات عديدة)، لكنني لا أريد الخروج عن الموضوع في هذا الشأن :slight_smile:

ومع ذلك، في منتديات vB القديمة لدينا، يتم كل ذلك بسهولة في إضافة PHP سهلة التعديل (ومكافحة الشر بجد) في الوقت الفعلي. في وقت ما استخدمنا مصنف بايزي، لكنني وجدت طرقًا أفضل على مر السنين. كما استخدمنا ملفات تعريف الارتباط (Cookies) ونسمح بالتسجيلات فقط من عميل قبل سياسة ملفات تعريف الارتباط (ويقبل ملفات تعريف الارتباط، وفقًا لسياسة الخصوصية الخاصة بنا)، وبالطبع، يمكننا قراءة ملف تعريف ارتباط بعد تسجيل مستخدم واستخدامه للكشف عن تسجيلات الدخول المتعددة. هذا يوقف معظم روبوتات البريد العشوائي، بصراحة. الأمر ليس معقدًا مثل الصواريخ، ولا يعتمد بشكل عام “فقط على عنوان IP”، بصراحة.

أيضًا، للمعلومية، لا تقبل معظم روبوتات البريد العشوائي ملفات تعريف الارتباط على الإطلاق، لذا فإن مجرد حظر العملاء الذين لا يسمحون بملفات تعريف الارتباط يساعد كثيرًا.

لا أريد أن أبدو “ذكيًا” جدًا، لكنني أقوم بهذا لأكثر من عقدين، ولدي أوراق بحثية منشورة في هذا المجال، وخضت حروب سيبرانية في الوقت الفعلي في هذا المجال، ولدي أكثر من 20 عامًا من الخبرة في الدفاع السيبراني في الوقت الفعلي وتقنيات مكافحة البريد العشوائي، لذا أعرف تمامًا ما أتحدث عنه؛ لذا أرجو ألا تكون قاسيًا وتحجب ردّي إذا لم تكن هذه الوظيفة متاحة، أو مخططة، أو قابلة للبرمجة بسهولة في تطبيق Discourse، شكرًا لك.

لنكن شموليين للجميع، وخاصة الخبراء المستعدين لمساعدة المستخدمين.

تحياتي.

إعجابَين (2)

… بعد 30 ثانية …

:wink: