Cómo implementar un límite de "intentos de acceso"

[dec]

Hola,

Gracias por la respuesta pcicom. ¿Tú usas la base de datos, verdad? El asunto estaría en no tener que usarla, pero, me temo que es necesaria. El caso es que no funcionaría usando sólo la variable de sesión. Es menester "persistir" el contador de intentos, y, ahí es donde entra la base de datos.

Se admiten otras ideas.

[dec]

Hola,

No sé qué tal parecerá, pero, estoy por implementar el asunto utilizando la tabla "options" que existe ya en Gesbit. De este modo, se añadiría una nueva opción (un nuevo registro) llamado "gbaccessretries", por ejemplo. Este registro sería con el que trabajaría la clase "GbUser", desde el formulario de autenticación y desde el de recuperación de los datos (nuevas contraseñas). Creo que, estirando un poco, una opción así puede caber en dicha tabla. ¿Y vosotros cómo lo veis esto?

PD. Sea como sea, el asunto se complica más de lo que en principio me parecía. No hay que guardar sólo el número de intentos, sino también quién (la IP) hace dichos intentos, luego, tampoco bastaría un registro de una tabla... sino una tabla con varios registros, o varios registros, en todo caso... me temo que de momento voy a recomendar usar contraseñas "fuertes" (), para limitar los ataques por fuerza bruta. Esto hay que tomárselo con mucha más calma.

[pcicom]

Empezado por dec

Hola,

Gracias por la respuesta pcicom. ¿Tú usas la base de datos, verdad? El asunto estaría en no tener que usarla, pero, me temo que es necesaria. El caso es que no funcionaría usando sólo la variable de sesión. Es menester "persistir" el contador de intentos, y, ahí es donde entra la base de datos.

Se admiten otras ideas.

Pues tambien puedes grabar los INTENTOS y las IP en un archivo de TEXTO, ya seria tu decicion solo tendrias que hacer los barridos buscando la IP y la FECHA HORA del ultimo INTENTO..

Al final de cuentas como la tabla de boqueos va a ser muy pequeña, no afecta en el performance de nada al servidor web,, SALVO que te ataquen por todos lados a tu SITIO...

[dec]

Hola,

Sí; ya tengo claro que toca usar la base de datos, mejor que un archivo de texto, aunque, en efecto, sería parecido. Pero como la base de datos existe... podría prepararse ahí lo necesario. Ahora es cuestión de ponerme con ello, si es que decido hacerlo. El caso es que este asunto no puede hacerse con sesiones, por lo dicho al principio. Y no es tan sencillo como yo lo había previsto en principio. Pero, sea como sea, dando por supuesto el uso de la base de datos, es cuestión de ponerse a ello. Gracias pcicom por tu interés.

[roman]

A ver, no quiero quitar el dedo del renglón.

El problema para usar sesiones es que herramientas como Snoopy no tienen manera de guardar las cookies que reciben, incluida la PHPSESSID de sesión, y por tanto, en cada petición, el servidor piensa que es la primera y genera una nueva sesión.

Ahora bien, ésta no es la situación de un usuario normal, y si alguien quiere usar Snoopy para algún fin lícito, tendrá que preocuparse por como preservar esa cookie y enviarla al servidor.

Entonces, el problema está con los chicos malos que intentarán confundir al servidor explotando esta particularidad.

Siendo así, ¿por qué no aprovechar esta amnesia de sesión para detectar si alguien no está jugando limpio?

La idea es generar un valor aleatorio o token al momento de presentar el formulario de login. Este valor se guarda en la sesión y se manda junto con el formulario como un campo hidden. El script que recibe los datos del formulario, verifica que exista dicho campo oculto y que su valor coincida con el que tiene guardado en la sesión.

Esto, de entrada, impide usar Snoopy para invocar directamente al script que procesa el formulario -los datos tiene que enviarse forzosamente desde el formulario que presentamos nosotros mismos. Snoopy podría "leer" ese formulario, usar el DOM para leer el campo oculto y enviarlo junto con la petición al script procesador. Esto es lo que haría alguien que quiere utilizar Snoopy u otra herramienta similar con un fin genuino. Pero si no es así, entonces la sesión no se preservará y el script que recibe los datos del formulario no reconocerá el campo escondido pues no lo tendrá guardado en la sesión, y, de esta manera, sabrá que se trata de una petición no válida.

En resumen, que les damos una cucharada de su propia medicina.

¿Cómo ven?

Claro que esto no invalida la opción de usar la base de datos, pero es una alternativa que, de hecho, se usa con frecuencia para dar mayor seguridad a nuestros formularios de login (buscar forms+tokens en google).

// Saludos

[roman]

Hola,

Creo que me enredé demasiado con los tokens.

Basta guardar una variable de sesión cualquiera en la página que muestra el formulario y preguntar por ella en el script que procesa el formulario.

Si no existe la variable, consideramos inválida la petición y abortamos. El atacante podrá hacerlo cuantas veces quiera que siempre obtendrá la misma respuesta: "petición no válida".

La única forma que tiene para no obtener dicha respuesta es preservando la sesión, y una vez hecho esto ya lo tenemos amarrado y podemos contar los intentos con una variable de sesión, que, de hecho, puede ser la misma que la otra:

login-form.php

Código PHP:

<?php
session_start();
$_SESSION['intentos'] = 0;
?>
<form method='post' action='login.php'>
    <div>
        <label for='user'>User</label>
        <input type='text' name='user' id='user'>
    </div>

    <div>
        <label for='password'>Pwd</label>
        <input type='text' name='password' id='password'>
    </div>

    <div>
        <input type='submit'>
    </div>
</form>

login.php

Código PHP:

<?php
session_start();

if (!isset($_SESSION['intentos']))
{
  die('Petición no válida');
}

/*
  Verificamos los datos de inicio
*/

...

/*
  Si son incorrectos, marcamos un intento más
*/

$_SESSION['intentos']++;

/*
  Y lo mandamos a volar si ya rebasó el máximo permitido
*/
if ($_SESSION['intentos'] > 3)
{
  die('Demasiados intentos');
}
?>

// Saludos

[dec]

Hola,

Antes de nada, te agradezco el interés Román, doblemente, por la posible solución. Digo posible, porque, aunque todavía no lo he probado tal como dices, me entran dudas sobre el uso de las sesiones, puesto que es lo que había intentado anteriormente. ¿No se supone que las variables de sesión son únicas para cada sesión? Pero, si el "script" cambia dicha variable de sesión... ¿no estamos como al principio? Pero, igual es que no he leído bien tus mensajes Román.

Echaré un vistazo, haré las pruebas oportunas, y comentaré aquí los resultados. Gracias de nuevo Román.

[roman]

Empezado por dec

Pero, si el "script" cambia dicha variable de sesión... ¿no estamos como al principio?

No podemos evitar que nos cambien la sesión. El punto aquí es que si lo hacen, nosotros lo detectamos y los mandamos a volar. Dicho de otra forma, la única manera de que puedan autenticarse en nuestro sistema es no cambiando la sesión, con lo cual tenemos un ambiente controlado.

Olvídate un poco de los tokens (son útiles pero no se requiere tanto) y fíjate en el ejemplo que puse:

1. Es imposible llamar directamente a login.php pues no habrá ninguna sesión y por tanto ninguna variable $_SESSION['intentos']

2. Esta variable se establece en login-form.php

3. Si en el paso de login-form.php a login.php cambia el ID de sesión, entonces login.php ya no reconocerá la variable intentos.

1 y 3 vienen a ser lo mismo. El caso es que ni siquiera se llega a verificar usuario y contraseña, y por tanto el atacante no tiene forma de decidir si eran datos correctos o no.

// Saludos