¿Es sql donde las consultas en autenticación son propensas a ataques de tiempo, si se devuelven una o ninguna fila de la base de datos?

Question

¿Es sql donde las consultas en autenticación son propensas a ataques de tiempo, si se devuelven una o ninguna fila de la base de datos?

#1 de marstato (1 votos)
#2 de ste-fu (0 votos)

0

Diga que tengo este código para la autenticación.

   $me = mysql_query("SELECT * from users WHERE id='$_COOKIE[userid]' && password ='$_COOKIE[pass]'") or die (mysql_error());
   $me = mysql_fetch_array($me);

Para autenticar a un usuario en un sitio web, algo en la computadora del usuario tiene que coincidir con lo que hay en el servidor (esta pregunta no se trata de prevenir el robo de cookies, ya que todos los sitios web pueden tener cookies robadas), pero ¿hay alguna manera de usar sql donde verificar si coincide en la base de datos sin que sea propenso a un ataque de tiempo?

¿Qué sucede si alguien modifica sus cookies a un ID de usuario y contraseña diferentes para intentar averiguar la contraseña de otra persona mediante un ataque de tiempo? Si $me produce 0 resultados en lugar de 1, ¿eso cambia el tiempo promedio que se tarda en ejecutar la consulta?

En caso afirmativo, ¿cómo debo cambiar mi código, porque no puedo resolverlo? ¿Debo agregar un retraso aleatorio al código anterior, y hace una diferencia, ya que lo leí?

authentication php timing-attack

pregunta desbest 18.06.2017 - 18:54

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication php timing-attack

¿sabrá mi ISP mi conexión entre sistemas en la misma red? ¿Cómo funciona el ataque de Replay en la autenticación SSL / TLS?

score 1 · Answer 1

No te preocupes por un ataque de tiempo. La diferencia entre 0 y 1 filas es minúscula.

Sin embargo, hay una serie de otros problemas con el Código que ha publicado:

No permita que un atacante envíe suficientes solicitudes para poder explotar una diferencia de tiempo aquí. Bloquee a las personas después de un pequeño número auf fallan los intentos de autenticación
$ _COOKIE está completamente controlado por un atacante. Usted está exponiendo una vulnerabilidad de inyección SQL aquí que cualquier pentestro semiprofesional podrá explotar en cuestión de minutos
NUNCA almacene la contraseña en texto plano, en ninguna parte. No lo haga en su base de datos y, por supuesto, no lo almacene en la cookie, donde puede ser fácilmente visible para el público. En su lugar, almacene un token de permlogin para cada usuario que sea completamente aleatorio (ver CSPRNG) y grande (256 bits o más). Utilícelo para la autenticación basada en cookies
Use una sal para sus contraseñas. Seleccione el registro de usuario por ID y luego compare las contraseñas. Hacerlo también disminuirá la superficie para un ataque de tiempo

score 0 · Answer 2

Si quisieras estar seguro, entonces podrías hacerlo

'SELECT * FROM Users'

y luego enumere la lista completa en el código que verifica la contraseña en toda la lista. Eso sería suficiente tiempo constante.

Mi PHP está un poco oxidado pero algo así

$authUser = NULL;
$users = mysql_query("SELECT * from users");
$users = mysql_fetch_array($users);
foreach($users as $user){
    if ($user['id'] = $_COOKIE[userid]' && $user['password']='$_COOKIE[pass]'){
        $authUser = $user;
    }
}

if(is_null($authUser))
     // whatever

Sin embargo, sigo pensando que es un error almacenar el hash de contraseña real en una cookie. Esto significa que es imposible revocar una sesión sin cambiar la contraseña. Cualquier tipo de identificador de sesión, incluso con un vencimiento de 100 años, todavía permite borrar sesiones o cambiar el vencimiento sin cambiar la contraseña