
  


---
title: "Seguridad en Wordpress - Limit Login Attemps - Carlos Sánchez"
description: "Limit login Attemps introduce registros falsos para que te asustes y compres la versión Premium."
author: "Carlos Sánchez"
url: https://carlossanchezdonate.com/curiosidades/critica-limit-login/
image: https://carlossanchezdonate.com/wp-content/uploads/tb-limit-login.jpg
---





# Por qué no usar Limit Login Attempts




                Limit login Attemps introduce registros falsos para que te asustes y compres la versión Premium.






![Por qué no usar Limit Login Attempts](https://carlossanchezdonate.com/wp-content/uploads/cover-limit-login.jpg)




**Autor:**

        : [Carlos Sánchez](https://carlossanchezdonate.com/sobre-mi/)





**Fecha de publicación:**

        : 2022-05-11



**Última revisión:**

        : 2026-01-30




        **Índice**
                mostrar


        1
                Seguridad estándar de WordPress
        2
                Utilización de plugins externos
        3
                Comportamiento sospechoso: ¿falsos positivos o algo más?
        3.1
                Poniendo a prueba a Limit Login Attempts en un entorno controlado
        3.1.1
                Si falla la contraseña o no entra es un código de respuesta 401
        3.1.2
                Es una capa extra de seguridad que actúa antes de WordPress
        3.1.3
                El resultado inexplicable
        4
                ¿Qué explicaciones da el fabricante?
        5
                Conclusión y recomendación
        5.1
                La alternativa: protección a nivel de servidor
        6
                Bibliografía


## Seguridad estándar de WordPress

Para acceder a la parte de administración de un WordPress por defecto basta con añadir /wp-admin en la url de la página de inicio.

Por lo general, en cualquier web de WordPress te encontrarás una interfaz similar a esta:

![Acceso a WordPress](https://carlossanchezdonate.com/wp-content/uploads/accesowp.jpg)
Entonces ocurre que en la mayor parte de plataformas de WordPress se sabe directamente [la URL para acceder](https://carlossanchezdonate.com/articulo/sintaxis-de-urls/). Como alguien con conocimientos y malas intenciones se pueda hacer con el usuario (y con plugins y temas no optimizados es bastante fácil y habitual verlos a la vista), solo necesitará la contraseña para acceder.

Por lo que hay un método sencillo y eficaz que en muchos casos permite acceder fácilmente al backend de la web. Este método se llama ataque por fuerza bruta, y consiste en emplear un bot que vaya probando infinitas variables de contraseñas hasta que dé con la adecuada (normalmente ayudándose de diccionarios y listados con las contraseñas más comunes).

## Utilización de plugins externos

Debido a estos hechos, es bastante probable que alguna vez hayamos querido recurrir a plugins que o nos relocalizan el panel de acceso, o establecen un patrón de tiempos de espera y hasta bloqueos por X intentos de acceder que se hacen en el panel.

Uno de estos plugins es **Limit Login Attempts Reloaded**, con más de 2 millones de instalaciones activas.

![Limit Login Attempts](https://carlossanchezdonate.com/wp-content/uploads/limit-login-attempts.jpg)
En principio parece un plugin bastante completo y versátil, donde si bien hay una versión premium con más configuraciones como las de evitar intentos de accesos por países, parece totalmente funcional. De hecho lo es, y si pruebas a entrar las veces que configures sin éxito, te bloquea (como debe hacer).

![Configuración Limit Login Attempts](https://carlossanchezdonate.com/wp-content/uploads/limit-login-attempts-configuracion.jpg)

## Comportamiento sospechoso: ¿falsos positivos o algo más?

En ocasiones al verlo instalado en distintos proyectos he podido observar picos inusuales de intentos de ataque en comparación con el tráfico habitual de la web, con lo conocida que es o con webs que ni siquiera están aún bien posicionadas en Google.

No obstante es posible que por medio de herramientas como Wappalyzer, BuiltWith o por [buscadores de código como publicwww](https://publicwww.com/) encuentren nuestro WordPress entre otros muchos para probar ataques de fuerza bruta por si hay suerte.

Sin embargo, investigando el tema he encontrado que **no soy el único que ha observado este comportamiento**. En los foros oficiales de WordPress.org hay múltiples reportes de usuarios con experiencias similares:

- [Fake login attempts?](https://wordpress.org/support/topic/fake-login-attempts/) - Usuario reporta que los "intentos de login" no generan emails de 2FA, sugiriendo que no son intentos reales.
- [Fake brute force login lockout attempts](https://wordpress.org/support/topic/fake-brute-force-login-lockout-attempts/) - Usuario reporta que tras desinstalar el plugin, los ataques con su username exacto cesaron inmediatamente.
- [FAKE ATTEMPTS, DONT INSTALL](https://wordpress.org/support/topic/fake-attempts-dont-install/) - Usuario reporta más ataques después de cambiar la URL de login.
- [Incredibly intrusive and annoying](https://wordpress.org/support/topic/incredibly-intrusive-and-annoying/) - Usuario reporta 25.000 "falsos positivos" en un día.

### Poniendo a prueba a Limit Login Attempts en un entorno controlado

Como podéis observar en mi página de acceso, no tengo una forma de acceder convencional. Tengo implementada una **protección a nivel de servidor con htpasswd**, que es una capa de seguridad que actúa antes de que WordPress procese ninguna petición.

Decidí hacer este tipo de implementación debido a varios factores.

#### Si falla la contraseña o no entra es un código de respuesta 401

![Código 401 en acceso WordPress](https://carlossanchezdonate.com/wp-content/uploads/acceso-401-wordpress.jpg)
Google reacciona a estos códigos de respuesta reduciendo el rastreo en estas zonas y no indexándolo. Por lo que al final no gastará Crawl Budget y tampoco corremos riesgo de que lo indexe.

#### Es una capa extra de seguridad que actúa antes de WordPress

Esto es clave para entender el problema. Cuando tienes protección htpasswd:

1. La petición llega al servidor (Apache/Nginx).
2. El servidor pide usuario y contraseña **antes de ejecutar PHP**.
3. Si falla, devuelve 401 y **WordPress nunca se entera**.
4. Si acierta, entonces pasa a WordPress.

Esto significa que **ningún plugin de WordPress debería poder detectar intentos fallidos** en este escenario, porque PHP ni siquiera se ejecuta cuando alguien falla la autenticación del servidor.

Además, tanto el usuario como la contraseña los [he generado](https://www.lastpass.com/es/features/password-generator) de más de 18 caracteres con caracteres especiales:

![Acceso protegido a WordPress](https://carlossanchezdonate.com/wp-content/uploads/access-to-wp-carlos.jpg)
Teniendo en cuenta la siguiente infografía de Hive Systems, romper este usuario y contraseña costaría más de 438 billones de años en averiguarlos. Teniendo en cuenta que necesitas combinar ambas a la vez, el número de años necesarios para romper esa seguridad es astronómico.

![Infografía Hive Systems sobre seguridad de contraseñas](https://carlossanchezdonate.com/wp-content/uploads/infografia-hivesystem-password.jpg)
Por si fuera poco, además durante este tiempo también he capado el acceso a las que no son mis IP de confianza una vez aciertas la contraseña.

#### El resultado inexplicable

Por lo que sería remotamente improbable que, con todas estas capas de protección, siguiese teniendo intentos de acceso al panel de WordPress por medio del /wp-admin.

Sin embargo, Limit Login Attempts Reloaded reportaba lo siguiente:

![Reportes sospechosos de Limit Login Attempts](https://carlossanchezdonate.com/wp-content/uploads/fail-limit-login.jpg)
Además, curiosamente intentaban acceder con el mismo nombre de usuario que tengo registrado en el WordPress (que, sin los caracteres especiales que les tengo añadidos por seguridad) y que no se puede ver en todo el front ni tengo ningún plugin que comprometa dicha información.

De hecho, ni siquiera aparecen los registros de esos supuestos usuarios que intentan acceder en los Logs que ofrece la herramienta:

![Log vacío en Limit Login Attempts](https://carlossanchezdonate.com/wp-content/uploads/log-vacio-limit-login.png)

## ¿Qué explicaciones da el fabricante?

Para ser justos, el fabricante tiene un [artículo explicando por qué los ataques podrían parecer falsos](https://www.limitloginattempts.com/blogs/could-these-failed-login-attempts-be-fake/). Sus argumentos incluyen:

- **IPs compartidas**: Tu hosting comparte IP con otros sitios que ya están siendo atacados.
- **WHOIS**: Los dominios nuevos se registran públicamente y son escaneados.
- **xmlrpc.php**: Aunque cambies la URL de login, xmlrpc.php sigue expuesto.

Estas explicaciones son técnicamente válidas para muchos casos. Sin embargo, **no explican mi escenario específico**:

- Mi /wp-admin está protegido a nivel de servidor, no de WordPress.
- El plugin no debería detectar nada porque PHP no se ejecuta en peticiones fallidas.
- Los "ataques" usaban mi username exacto, que no es público.
- Los logs del plugin estaban vacíos mientras reportaba ataques.

## Conclusión y recomendación

No puedo afirmar con certeza absoluta que este plugin genere falsos positivos intencionadamente para fomentar la compra de la versión premium. Sin embargo, la evidencia que he recopilado, junto con los múltiples reportes de otros usuarios en los foros oficiales de WordPress, genera suficientes dudas como para **recomendar precaución**.

Mi recomendación: **no depender de plugins de terceros para propósitos críticos de seguridad**. Especialmente cuando existen alternativas más robustas a nivel de servidor.

### La alternativa: protección a nivel de servidor

Si queremos añadir un plus de seguridad real, podemos proteger el directorio deseado (como /wp-admin) por medio del servidor con htpasswd. Ventajas:

- **Actúa antes de WordPress**: Los bots ni siquiera llegan a ejecutar PHP.
- **Código 401**: SEO-friendly, Google reduce el rastreo automáticamente.
- **Doble autenticación real**: Necesitas pasar servidor + WordPress.
- **Sin dependencias**: No necesitas plugins ni actualizaciones.
- **Rendimiento**: Menor carga en el servidor al no ejecutar PHP.

Haré un post paso a paso de cómo implementar esta protección correctamente tanto en [Apache](https://carlossanchezdonate.com/articulo/apache/) como en Nginx.

## Bibliografía

- [Brute Force Attacks using Kali Linux - Medium](https://pentestit.medium.com/brute-force-attacks-using-kali-linux-49e57bb89259)
- [Multiple Ways to Crack WordPress Login - Hacking Articles](https://www.hackingarticles.in/multiple-ways-to-crack-wordpress-login/)
- [Hive Systems - Password Security](https://www.hivesystems.com/blog/are-your-passwords-in-the-green)
- [WordPress.org - Fake login attempts?](https://wordpress.org/support/topic/fake-login-attempts/)
- [WordPress.org - Fake brute force login lockout attempts](https://wordpress.org/support/topic/fake-brute-force-login-lockout-attempts/)


        Si te gusta este artículo, me ayudarías un montón compartiendo mi contenido:

        Compartir:


                [![Compartir en LinkedIn](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/linkedin.svg)](https://www.linkedin.com/cws/share/?url=https://carlossanchezdonate.com/curiosidades/critica-limit-login/)



                [![Compartir en Twitter](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/tw.svg)](https://twitter.com/intent/tweet?url=https://carlossanchezdonate.com/curiosidades/critica-limit-login/)



                [![Compartir en Facebook](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/facebook.svg)](https://www.facebook.com/sharer/sharer.php?u=https://carlossanchezdonate.com/curiosidades/critica-limit-login/)



                [![Compartir en WhatsApp](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/whatsapp.svg)](whatsapp://send?text=https://carlossanchezdonate.com/curiosidades/critica-limit-login/)



                [![Compartir en Telegram](https://carlossanchezdonate.com/wp-content/themes/sanchezdonate/images/rrss/tlg.svg)](https://telegram.me/share/url?url=https://carlossanchezdonate.com/curiosidades/critica-limit-login/)





        No se te da mal el SEO Técnico

**Te falta mi máster**. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB

        [¡Accede al Máster de SEO Técnico!](/master-seo-tecnico/)



  Tal vez te interesen otros artículos:
  [Artículos de SEO](/seo-avanzado/)





                [Sitemaps](https://carlossanchezdonate.com/articulo/sitemaps/)







                [Curación de enlaces en el SEO](https://carlossanchezdonate.com/articulo/curacion-de-enlaces-en-el-seo/)







                [Texto alternativo para imágenes](https://carlossanchezdonate.com/articulo/alt-imagenes/)







                [Rich Snippets con HTML](https://carlossanchezdonate.com/articulo/rich-snippets-sin-datos-estructurados/)




                Más curiosidades que te pueden interesar







                [Hacer que un bot acepte las Cookies](https://carlossanchezdonate.com/curiosidades/bot-acepte-cookies/)







                [Gestionar la redimensión de imágenes en WordPress](https://carlossanchezdonate.com/curiosidades/imagenes-redimensionadas-wordpress/)







                [Fuentes en Devtools](https://carlossanchezdonate.com/curiosidades/fuentes-en-devtools/)
