¿Por qué no lo usaría? No entiendo. Soluciona su problema de ataque.
En ese caso, ¿quizás el mejor lugar para ello sea Marketplace?
¿Es mejor que lo rompa un tercero que un complemento “oficial”?
Nunca sería un complemento oficial; sería solo una línea de tres en mi cuenta de GitHub si Jeff considera que lo quiere hoy.
Rompe el inicio de sesión por correo electrónico para varias cuentas legítimas, incluida mi propia cuenta de Gmail.
Sí, pero no creo que uses su sitio.
Un cierto número de bajas civiles es aceptable cuando estás en guerra. ¿Y qué importa si el 2 % de los usuarios no puede registrarse, cuando estás siendo desbordado por miles de correos con direcciones falsificadas cada día? Es como el modo “Estoy bajo ataque” de Cloudflare: algunas personas legítimas no podrán entrar. Ese es el precio que se paga por una seguridad más estricta.
Tu argumento es que el modo “Estoy bajo ataque” de Cloudflare no es perfecto, por lo tanto no debería existir ![]()
De todas formas, necesitaría ver al menos dos informes más legítimos de que esto sea un problema a gran escala antes de actuar al respecto.
Perdona si se me ha escapado algo obvio, pero ¿no sería más fácil añadir reCAPTCHA a la pantalla de registro?
Estos suelen ser spammers humanos. Ahora hay bastantes más en comparación con 2010. Los CAPTCHA no sirven de nada contra un adversario humano.
Vale… Pensé que este tipo de registro con ‘puntos y más’ en Gmail lo hacían sobre todo los bots…
Muchas personas reales y genuinas usan servicios como sharklasers (que utilizan esto) para registrarse en nuestro sitio porque no quieren que su nombre de usuario esté vinculado a su identidad en la vida real. Dependerá de cada circunstancia.
El OP puede establecer un tiempo de lectura de 15 minutos como requisito de confianza para publicar, y que los primeros 5 mensajes necesiten aprobación del personal, sin derechos de edición. Apuesto a que su problema desaparecería inmediatamente.
Una cosa que certainly me gustaría confirmar aquí es que tenemos límites de tasa razonables para el registro de cuentas.
Una sola dirección IP solo debería poder registrar N cuentas por día. Pero necesitamos algún tipo de bypass / configuración del sitio para casos en los que el NAT haga que un gran grupo de usuarios comparta la misma IP.
Prefiero que . se normalice para Google, pero que +algo permanezca tal cual. Así que quizás, si van a hacer esto, permitan que los administradores elijan lo que deseen.
Eso ya es así… el problema aquí es que se trata del Mossad. Tienen muchas, muchas direcciones IP para usar.
Estoy viendo limitadores de tasa en:
- inicio de sesión por correo electrónico por hora
- correo electrónico de activación de actualización
- reenvío del correo electrónico de activación
- lista de segundos factores
- habilitar TOTP
- inicio de sesión de administrador
No veo ningún límite de tasa específico para la creación de cuentas, aparte del límite de tasa estándar integrado por dirección IP.
Me pregunto si @markersocial puede instalar el explorador de datos y listar las direcciones IP de registro para la multitud de usuarios que se registraron. Quiero saber con certeza si provienen de 100 direcciones IP o simplemente de 1.
Me gustaría estar de acuerdo, pero Google tiene este problema. Al menos en la universidad donde trabajé, no se podía permitir que una clase se registrara en Gmail porque la universidad tenía todo el acceso a través de una única NAT.
Sospecho que una lista blanca de NAT resolvería la mayoría de los problemas del mundo real, ya que probablemente sea predecible desde dónde provienen los usuarios legítimos.
Por defecto, un número pequeño (o configurable) de IPs por día me parece bastante seguro.
@sam - En cuanto a las direcciones IP, confirmo que utilizo la limitación de IP mediante registro e inicio de sesión, y cuento con una extensa lista de IPs bloqueadas. Puedo asegurarte que no son usuarios creando cantidades significativas de cuentas desde las mismas IPs; ojalá fuera así, porque entonces sería posible bloquearlos. La única forma de bloquearlos actualmente es prohibir todos los registros con cuentas de Gmail.
—
@codinghorror Existe un servicio no ilegal que te proporciona acceso a xx,xxx,xxx direcciones IP únicas por xxx dólares al mes. Por lo tanto, es fácil para cualquiera obtener muchas IPs, no solo el Mossad
. Hay muchos otros servicios legales que también ofrecen grandes pools de IPs; además, existen servicios ilegales de alquiler de botnets.
Definitivamente actualizaría a la última versión; como mínimo, los scripts para llevar a cabo esta bonanza serán mucho más molestos de escribir, dado mis últimos cambios de desafío/carnada.
Además, por favor bríndenos actualizaciones regulares aquí para que podamos aprender más.
¿Esto sigue ocurriendo ahora mismo?
¡Muchas gracias, @sam! Disculpa que aún no haya dado seguimiento a esto.
Sí, todavía parece muy viable crear muchas cuentas usando este truco (2.5.0.beta1).
Por ejemplo, usando el truco de username+{cadena_aleatoria}@gmail.com, alguien creó 748 cuentas en las últimas 10 horas. Ya tienen miles de cuentas asociadas a esa única dirección de Gmail.
Básicamente, la única forma que tengo de eliminarlas desde el área de administración es ir manualmente a cada cuenta individualmente para suspenderlas y/o eliminarlas. No es muy viable porque la persona puede simplemente presionar un botón y crear muchas más cuentas. ![]()
Parece que tienen un suministro prácticamente ilimitado de direcciones IP, por lo que los bloqueos o límites por IP son prácticamente inútiles en este caso.
Además, sigo recibiendo consistentemente muchas registraciones usando los trucos del punto y el signo más en Gmail.
¡Saludos!
Apoyo la adición de una configuración del sitio @codinghorror que deshabilite el soporte para cuentas de Gmail duplicadas; técnicamente, es una tarea de 15 a 30 minutos agregar la configuración.
Gracias @sam: te he enviado un mensaje privado con información adicional que podría ser útil~
Mi amplia experiencia con esto a lo largo de los años es que la mayoría de los bots de spam automatizados (no todos, pero la gran mayoría) utilizan la misma cadena ‘HTTP_USER_AGENT’. Incluso algunos de los bots de spam que pueden falsificar direcciones IP suelen usar la misma cadena ‘HTTP_USER_AGENT’ (o algo tan falso que es fácil de detectar).
La razón es que la mayoría de los bombardeadores y spammers simplemente descargan algún software de spam de bots y lo ejecutan, sin saber realmente lo que están haciendo. Sí, por supuesto que hay excepciones, pero el 99+ % de los bots de spam son solo scripts o programas ejecutados por spammers que no son realmente sofisticados y que descargan y ejecutan (en general, no son genios de la programación).
De hecho, a veces estas cadenas ‘HTTP_USER_AGENT’ son realmente obvias. Por supuesto, en teoría todo es posible de vencer, pero en la práctica, en nuestros foros a lo largo de las décadas, hemos tenido muy pocos problemas de spam (en comparación con otros foros) porque calificamos las direcciones de correo electrónico según varios criterios y rechazamos las obvias (no las moderamos; cuando la puntuación supera un cierto umbral {nivel de confianza}, simplemente rechazamos el registro, porque ¿quién quiere moderar una gran base de datos de spam? Nadie.). Además, no usamos Akismet por una serie de razones (desde hace muchos, muchos años), pero no quiero desviarme del tema ![]()
Sin embargo, en nuestros antiguos foros vB, todo esto se hace fácilmente en un plugin de PHP que es muy fácil de modificar (y luchar la buena batalla) en tiempo real. En un momento utilizamos un clasificador bayesiano, pero con el tiempo encontré mejores métodos. También hemos utilizado cookies y solo permitimos registros desde un cliente que haya aceptado la política de cookies (y permita las cookies, según nuestra política de privacidad), y por supuesto, podemos leer una cookie después de que un usuario se registra y usarla para detectar múltiples inicios de sesión. Esto detiene a la mayoría de los bots de spam, francamente. No es ciencia espacial y, francamente, no se basa generalmente “solo en la dirección IP”.
Además, por si acaso, la mayoría de los bots de spam no aceptan cookies en absoluto, por lo que simplemente bloquear los clientes que no permiten cookies ayuda mucho.
No quiero sonar demasiado “inteligente”, pero llevo más de dos décadas haciendo esto, he publicado artículos académicos sobre el tema, he librado ciberguerras en tiempo real en este ámbito y tengo más de 20 años de experiencia en defensa cibernética en tiempo real y técnicas antispam, así que sé de lo que hablo; así que, por favor, no seas demasiado duro y bloquees mi respuesta si este tipo de funcionalidad no está disponible, planificada ni es fácil de codificar en la aplicación Discourse, gracias.
Seamos inclusivos con todos, especialmente con los expertos que están dispuestos a ayudar a los usuarios.
Saludos.
… 30 segundos después …
![]()