PHP bin2hex ¿es vulnerable a un ataque de tiempo?

Question

PHP bin2hex ¿es vulnerable a un ataque de tiempo?

#1 de Scott Arciszewski (7 votos)

7

He leído en algunos lugares [1] [2] [3] del deseo de hacer que el tiempo bin2hex de PHP sea constante.

¿En qué situaciones sería vulnerable bin2hex a un ataque de tiempo?

¿Este código de abajo para manejar un token CSRF es vulnerable a un ataque de tiempo?

// generate a CSRF token, n is some large number
$token = bin2hex(openssl_random_pseudo_bytes(n));
// ... store $token on in the PHP session and render form with CSRF token
// ... on form submission compare the form's CSRF token to the session token
hash_equals($sessionToken, $formToken);

csrf php timing-attack

pregunta Rob Olmos 19.06.2015 - 07:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas csrf php timing-attack

¿Cómo agregar la fijación de certificados para un dominio determinado a mi navegador web? ¿Se requiere una maestría en infosec para ingresar al campo de seguridad?

score 7 · Answer 1

¿En qué escenarios sería bin2hex vulnerable a un ataque de tiempo?

El ataque de tiempo discutido en la lista de correo y en la publicación del blog es un ataque de tiempo de caché, que fue demostrado por Daniel J. Bernstein contra la implementación de AES here (PDF).

Para que bin2hex() sea vulnerable a un ataque de tiempo, se deben cumplir las siguientes condiciones:

Internamente, indiza o ramifica según el secreto que intentamos proteger (por ejemplo, la clave HMAC). La implementación de PHP does se basa en un índice lo que potencialmente podría ser un secreto .
El atacante debe poder alterar el estado de la memoria caché del procesador de alguna manera. (por ejemplo, alquilar una máquina virtual vecina en la misma máquina baremetal con su proveedor de nube y ejecutar una estrategia similar a FLUSH + RELOAD .)
El atacante puede emitir rápidamente muchas solicitudes válidas desde una posición de red privilegiada con una mínima fluctuación de la red (sorprendentemente trivial en estos días).
La clave que queremos proteger se reutiliza. (Caso general; algunos tokens CSRF no se reutilizan).

La factibilidad de un ataque de este tipo aún es desconocida, pero en realidad no es tan difícil. Los métodos previamente vinculados se derivaron de CodesInChaos .

¿Este código de abajo para manejar un token CSRF es vulnerable a un ataque de sincronización?

No lo sé. El bin2hex() puede ser una preocupación muy pequeña, pero no una para la que pueda demostrar una vulnerabilidad práctica. Tal vez alguien en Crypto Stack Exchange pueda?

Actualización: hay una Lib para eso

Si utiliza paragonie / constant_time_encoding (que no existía cuando hizo esta pregunta), no debería filtrar ninguna información a través del tiempo de caché.

<?php
use \ParagonIE\ConstantTime\Hex;

$rawBinary = random_bytes(32);
$data = Hex::encode($rawBinary);
$decoded = Hex::decode($data);

Esta biblioteca cubre todos los esquemas de codificación RFC 4648:

Hex.
Base32
Base32Hex
Base64
Base64UrlSafe
Base64DotSlash
Base64DotSlashOrdered

Los dos últimos son compatibles con crypt(3) .