Protecting against gmail dot trick in Discourse

No lo sé @sam, esto me parece más como si necesitáramos un plugin de CAPTCHA para la creación de usuarios. No creo que “prohibir puntos y signos más” esté tratando la enfermedad subyacente; solo está abordando los síntomas del problema. :thinking:

Históricamente, la tendencia ha sido hacia spammers humanos al 100% con el tiempo. Quiero decir, llenan perfiles de usuario, suben imágenes de perfil y todo. Los spammers automatizados (excepto bamwar) no han sido realmente un gran problema en Discourse porque somos muy difíciles de automatizar al ser una aplicación completa en JavaScript. Ten en cuenta que la mayoría de tus comentarios @neounix caen en la categoría descrita en mi frase anterior: es muy difícil scriptearnos porque somos tan complejos, en comparación con un sitio web de HTML 1.0 de la era de 1999. Elevar la barra de dificultad a ese nivel elimina la mayor parte del problema, según lo que hemos observado con nuestros clientes y aquí en meta.

En fin, TL;DR: no estoy necesariamente en contra de una configuración simple de “prohibir ciertos caracteres en correos electrónicos”, supongo, pero en mi corazón no creo que nada excepto un CAPTCHA vaya a ayudar mucho en este caso. ¿Podríamos hacer ambas cosas?

5 Me gusta

Pero algunos usuarios (incluyéndome a mí) usan el + para ordenar realmente los correos electrónicos en nuestro cliente de correo.

3 Me gusta

No te preocupes, esto no estaría activado por defecto; es más bien un modo de “bloqueo por ataque” a través de la configuración del sitio.

7 Me gusta

@neounix Leyenda. Gracias por los consejos, muy apreciados; me pusiste en un viaje de caza de spam. Puse Cloudflare en modo “Estoy bajo ataque” temporalmente (lo que detuvo sus registros; estaban creando una cuenta nueva cada 1-2 minutos) y revisé los registros del firewall de Cloudflare para ver algunas IPs que estaban usando, notando que era desafiante/registraba a cada visitante. De hecho, estaban usando useragents idénticos.

Agregué una regla de firewall para desafiar a los usuarios con ese useragent y desactivé el modo “Estoy bajo ataque” en CF. No creo que muchos usuarios inocentes hayan sido desafiados por ello y detuvo por completo sus registros de spam.

Luego descubrí la función de bloqueo por número de sistema autónomo (ASN) que tiene Cloudflare y configuré reglas de firewall adicionales para bloquear una cantidad significativa de ellos, haciendo referencia a los registros del bloqueo por useragent. Seguro que conoces soluciones alternativas para esto, pero implica un costo y esfuerzo adicionales de recursos para ellos.

:content:

@codinghorror Estoy de acuerdo contigo en que los captchas serían útiles. Diría que un buen objetivo principal de prevención de spam sería aumentar los costos generales de recursos para los spammers.

Los captchas contribuirían a esto. Unos $2, más o menos, por cada mil resoluciones de reCAPTCHA (usando una API de resolución de captchas, por ejemplo, https://anti-captcha.com). Además, se requieren complejidades adicionales para sus bots.

Nota al margen: Anti-captcha tiene un complemento de navegador para resolver automáticamente tus captchas; funciona bien y es una comodidad divertida. :goodnews:

Las direcciones de correo electrónico suelen ser otro costo de recursos para la creación masiva de cuentas. Sin embargo, no es el caso cuando un solo usuario puede crear virtualmente cuentas ilimitadas por una sola dirección de Gmail. El costo de 1000 cuentas de Gmail es bastante significativo, por lo que a menudo recurren a otros proveedores menos estrictos o dominios catchall. Aun así, les costará recursos y es más fácil identificarlo como spam.

Creo que realmente es un caso de “más es más”. Ninguna defensa por sí sola será lo suficientemente fuerte; simplemente aumentar la cantidad de recursos y esfuerzo necesarios para los spammers en general son pasos en la dirección correcta. El mejor escenario posible es que sea más esfuerzo para los spammers hacer spam en los foros de Discourse que para los administradores bloquearlo y eliminar masivamente cualquier cosa que logre pasar.

@itsbhanusharma Me gusta mucho poder usar el signo + también, pero por eso no podemos tener cosas bonitas, jaja. Sería bueno tener la opción de habilitar su bloqueo, si es necesario para combatir a los spammers.

2 Me gusta

Después de pensarlo, tiendo a estar de acuerdo contigo en esto. @sam, ¿podemos priorizar esta configuración de bloqueo de correos electrónicos para la próxima semana?

5 Me gusta

Este asunto ya se había discutido bastante más arriba, en este mismo hilo.
“Prohibir” los puntos y los signos más probablemente causaría algunos problemas (al menos para algunos usuarios). La idea era almacenar una versión “canónica” del correo electrónico (una versión “limpia”) y prohibir el registro de usuarios adicionales con la misma versión canónica para Gmail (es decir, el MISMO correo electrónico, gracias a los trucos de Gmail).

Eso puede ser a lo que Sam se refiere cuando dice:

Quizás es lo que también querías decir @codinghorror, y no realmente “prohibir” . y +.
Pero estoy de acuerdo contigo en que solo “resolvería” el problema para Gmail (no para el uso de un “catchall” con un dominio, por ejemplo).

¿Realmente un CAPTCHA resolvería algo cuando tú mismo dices:

?

Suena a que hemos omitido un paso.

Forzar el uso del correo electrónico canónico es problemático, pero bloquear más de una cuenta por correo electrónico canónico por defecto es bastante razonable.

La mayoría de nosotros tenemos más de una dirección de correo electrónico si necesitamos una cuenta de prueba. No generará un problema significativo allí; si es la configuración predeterminada, no tendremos que educar a los usuarios para que la activen después de que se produzca un abuso.

1 me gusta

Los signos más (+) en los correos electrónicos, en mi opinión, pueden tratarse de manera más o menos uniforme en todos los dominios de correo sin mayores problemas.

Para correos como sp.a.mmer.king@gmail.com o s.pa.mmerking@gmail.com, en el caso de Gmail, estos son el mismo correo. Sin embargo, para algunos otros proveedores, podría no ser así y ambos correos podrían corresponder a usuarios distintos.

Creo que una buena implementación a largo plazo sería algo similar a la función de lista negra de dominios de correo.

Agregar un dominio personalizado que se desee excluir para evitar trucos de registro duplicado. Luego, permitir activar o desactivar de forma independiente el bloqueo de estos dos tipos de registros duplicados. Es decir, ofrecer opciones separadas para deshabilitar duplicados por el truco del signo + y duplicados por el truco de los puntos.

Almacenar el correo electrónico registrado tal cual (en términos del inicio de sesión del usuario y la dirección a la que se envían los correos), pero bloquear registros adicionales que se determinen como el mismo correo.

Otra opción, que haría la solución ligeramente más efectiva, sería incluir varios dominios en un único registro de dominio personalizado, de modo que se traten como el mismo dominio. Por ejemplo, gmail.com y googlemail.com. Así, se podría evitar que alguien se registre dos veces usando, por ejemplo, example@gmail.com y example@googlemail.com. Existen otros proveedores con múltiples dominios intercambiables; envié algunos ejemplos a Sam. Esto podría añadir un poco más de protección, pero, en líneas generales, el problema principal explotable son los registros mediante los trucos del signo + y de los puntos.

Alternativamente, una implementación potencialmente más sencilla sería como la anterior, pero con dos opciones para cada dominio de correo personalizado: bloquear todos los registros que contengan signos + y/o puntos. Si un usuario se registra con ese dominio usando un signo + o un punto, mostrar un error indicándole que elimine los puntos y/o los signos + de su correo (posiblemente haciéndolo automáticamente) y que lo intente de nuevo. No es perfecto, pero seguiría siendo muy efectivo.

Correcto, por eso reduciríamos todo al correo canónico para garantizar que sean únicos. Esto ya se mencionó anteriormente. No obstante, no podemos almacenar el correo canónico como su dirección de correo, ya que no es el que ellos proporcionaron.

Las listas negras de dominios ya existen, pero no podemos asumir que, solo porque un usuario también pueda ser contactado mediante una dirección de googlemail o gmail, debamos rechazar una u otra. Por eso recurrimos a un «maestro» canónico.

Hoy en día hay sitios donde los usuarios utilizan legítimamente el direccionamiento con «+» y los puntos. El objetivo no es dificultar prácticas legítimas, sino limitar los efectos secundarios injustificados, como tener dos usuarios para una misma dirección canónica.

Si se requiere proporcionar la cadena de correo electrónico sin puntos ni signos más durante el proceso de registro, del lado del cliente y con consentimiento (similar a la validación de formularios), almacenarlo como su correo de cuenta sería aceptable.

No es lo ideal ni perfecto, pero potencialmente más simple y un compromiso valioso en algunos casos donde la opción es incomodar a unos pocos usuarios o incomodar a todo un foro con spam.

Existen cuentas de Gmail cuyo correo canónico principal incluye puntos. Serían los usuarios más afectados y confundidos por la eliminación forzada de estos durante el registro.

No creo que esta fuera la mejor implementación tampoco, y definitivamente no sería una opción predeterminada amigable.

Exacto, lo que quise decir es tener un menú de opciones similar a la lista negra de dominios de correo electrónico ya existente, para ingresar qué dominios de correo deberían verse afectados y los parámetros de qué se debe o no usar para decidir si una dirección de correo es única/canónica, tal como se discute en este hilo. Potencialmente también qué dominios deberían considerarse el mismo host, por ejemplo, gmail/googlemail.

En cuanto a gmail y googlemail, creo que estamos de acuerdo. Lo mismo con los puntos y los signos más.

Básicamente, permitir que el primer registro se procese, pero impedir que el usuario pueda crear múltiples cuentas con ese mismo correo. O al menos minimizarlo dentro de lo razonable.

john@googlemail.com se registra primero → aceptado
john@gmail.com se registra después → rechazado

matthew+{cadenaleatoria}@gmail.com se registra primero → aceptado
matthew@gmail.com se registra después → rechazado
matthew@googlemail.com se registra después → rechazado
m.att.he.w@gmail.com se registra después → rechazado
matthew+{cadenaleatoria}@gmail.com se registra después → rechazado
m.a.tt.ew+{cadenaleatoria}@googlemail.com se registra después → rechazado

La diferencia entre googlemail y gmail (y otros proveedores que tienen varios dominios alternativos) es mucho menos significativa que los problemas de puntos y signos más en las direcciones. Sin embargo, sería bueno manejar esos casos también.

Ese es un cambio realmente hostil para el usuario y totalmente innecesario. La razón por la que existen estas características es identificar el origen del correo electrónico. Si me registro usando la dirección de correo electrónico stephen+meta@gmail.com, puedo configurar una regla que permita etiquetar cualquier correo enviado a esa dirección. Si meta es comprometido y mi dirección de correo electrónico comienza a recibir spam en ese alias, ahora sé dónde ocurrió la brecha. Paralizar la forma en que uso el correo electrónico no es la solución; reducir mi dirección de correo electrónico a una versión canónica para comparación logra el mismo resultado sin crear ninguna molestia para el usuario.

Correcto, y eso está vinculado al concepto de una dirección canónica. Si la característica se implementara como se discutió originalmente, realmente nos beneficiaríamos de la capacidad de asociar dominios. Cada permutación de puntos y signos más, así como cada variación de dominio, se compararía con ‘el único correo electrónico verdadero’ para esa bandeja de entrada sin causar ninguna fricción.

Siempre que no generemos ninguna molestia para los usuarios, no hay razón por la que esta característica no pueda venir activada por defecto.

Estoy de acuerdo, una solución imperfecta = imperfecta. Solo lo mencioné como una alternativa potencialmente más sencilla de implementar. Es la última parte de mi publicación, presentada como una alternativa a las sugerencias principales que hice, las cuales están de acuerdo con gran parte de las discusiones en este hilo, además de permitir los signos ‘+’ y los puntos, pero no cuentas duplicadas.

Dicho esto, el uso legítimo de ‘+’ en correos electrónicos en foros o sitios no tecnológicos es generalmente un caso marginal, según lo que he visto.

Suena realmente fantástico. :content:

Mi publicación se centraba principalmente en cómo se calculan las direcciones canónicas para diferentes dominios de correo electrónico. Por lo tanto, no se limita al uso exclusivo con Gmail/Googlemail. Básicamente, intentaba decir que podría ser una buena implementación a largo plazo ofrecer opciones a los usuarios sobre cómo calcular las direcciones canónicas en función de cada dominio.

Algunos otros proveedores permiten el signo ‘+’ pero no las permutaciones de puntos, por ejemplo. Lo que significa que las permutaciones de puntos son correos electrónicos únicos.

Una implementación exclusiva para Gmail/Googlemail sería excelente, y no veo ninguna razón por la que no pueda venir activada por defecto tampoco.

¿Podrías dar un ejemplo? Pregunto porque la mayoría de los usuarios de Gmail no conocen el truco de los puntos. Se registraron con una dirección que incluye puntos, le dan esa versión de su correo a todo el mundo y se confundirían mucho si les dijeran que “su correo” no es válido.

Rara vez encuentro personas que siquiera se den cuenta de que su alias sin los puntos también les llegará.

1 me gusta

Claro, te enviaré por mensaje privado un ejemplo que ya le envié a Sam. Solo porque no estoy seguro de si es buena idea publicarlo abiertamente en un hilo con ese título, ya que parece que aún muchos spammers no lo conocen, por suerte.

Sí, estoy de acuerdo, eso sería la principal confusión para los usuarios habituales con esa solución imperfecta.

No hay manera de que optemos por un enfoque tan complicado. No vamos a «normalizar» los correos electrónicos.

O estás en modo de bloqueo de correo electrónico, que prohíbe completamente ciertos caracteres problemáticos en una dirección de correo electrónico (según el dominio de correo electrónico codificado de forma rígida, quizás), o no lo estás.

Eso es todo. Interruptor booleano. ¿Modo de bloqueo de correo electrónico, S/N?

3 Me gusta

Por:

Esto ya está completo.

Utilice la configuración del sitio enforce_canonical_emails (por defecto: false) para activar esta protección.

Una vez activada, no permitiremos registros duplicados para personas que utilicen el truco del . en googlemail.com y gmail.com, ni el truco del + de forma global.

La corrección es muy segura y no tiene ningún impacto por defecto cuando está desactivada.

Un efecto secundario de la implementación es que pasará un registro duplicado más una vez que active la configuración, ya que no almacenamos direcciones de correo electrónico en su forma canónica en la tabla de correos de usuario a menos que active la configuración. Esto es perfectamente aceptable, ya que, en general, no he encontrado casos de este abuso específico en varios de los sitios que alojamos.

8 Me gusta

Almacenar la forma canónica en absoluto es problemático. ¿Qué formato adoptan?

La especificación está aquí:

Si la configuración del sitio no está habilitada, no ocurre nada… cero, nada.

5 Me gusta

Gracias por tus amables palabras @markersocial

Disculpa no haber respondido antes; he estado ocupado con otras tareas… apenas estoy poniéndome al día con lo meta:

Detectar spam, registros falsos, ataques DDOS, intrusiones y la conciencia situacional en el ciberespacio en general, junto con todas las demás clases similares de problemas de ciberseguridad orientados a la detección y fusión de datos de múltiples sensores, es uno de mis temas favoritos, como parece que ya sabes :slight_smile:

Habiendo estado en la primera línea y librado muchas batallas cibernéticas “prácticas” en tiempo real, déjame darte dos consejos más cuando estés bajo un ataque como este:

(1) La detección a menudo es más un arte que una ciencia pura. La razón es que cuanto más sepan los atacantes sobre tus algoritmos y técnicas de detección y mitigación, más mutarán y se adaptarán a tus defensas.

(2) Además, nunca olvides el “Bucle OODA”. Observar-Orientar-Decidir-Actuar. Quien(es) en la batalla cibernética logre(n) entrar en el bucle OODA del oponente(s), generalmente será(n) el(los) ganador(es).

Me complace leer que estás disfrutando la defensa cibernética y mirando el panorama general. Parece que tienes todo bajo control (por lo que leí rápidamente en resumen en esta discusión) y que el excelente equipo de meta también ha implementado un cambio útil para ti.

Si caes bajo un ataque y necesitas ayuda, no dudes en contactarme. Me jubilé hace mucho del mundo de la búsqueda de beneficios y de llenar mis arcas (¡gracias a Dios!), así que nunca hay una tarifa por consultarme. Ayudar a otros que tienen problemas técnicos interesantes, especialmente en el área de ciberseguridad y guerra cibernética, es una prioridad más alta para mí que acumular más riqueza.

Estoy aquí para ti si necesitas a alguien con quien compartir ideas y, por lo que he leído de tus respuestas recientes, parece que tienes las cosas bajo control.

¡Gran trabajo!

5 Me gusta

@codinghorror Mi postura aquí es que este cambio carece de sentido y debería simplemente revertirlo.

Ninguno de nuestros sitios alojados lo solicita, ni tampoco modos de bloqueo de correo electrónico extremos. En la práctica, esto no representa un problema, ya que eliminamos las cuentas inactivas y escaneamos los perfiles en busca de spam.

Un spammer puede simplemente ejecutar un servidor SMTP, lo cual es más fácil que automatizar Gmail, y de esa manera tendría acceso a un número infinito de correos electrónicos.

Además, el direccionamiento se utiliza ampliamente de manera legítima.

El problema más común relacionado con los puntos en Gmail no es el spam, sino errores tipográficos en el correo electrónico.

Supongo que el único cambio que apoyo en el núcleo es expandir la lista de correos bloqueados para incluir las versiones canónicas; al menos eso mejora la función de bloqueo de correos y resuelve la pregunta original.

Por ejemplo, si bloqueas Jane@gmail.com, también se bloquearía j.ane+1@gmail.com.

Cualquier otro cambio puede implementarse mediante plugins.

¿Te parece bien?

7 Me gusta