security - wp_create_nonce - wp_nonce_field
Necesito ayuda para entender Nonce (2)
El propósito de un nonce es hacer que cada solicitud sea única para que un atacante no pueda reproducir una solicitud en un contexto diferente. No importa si el atacante obtiene el nonce: de hecho, el punto es que dado que los datos incluyen un nonce, no será útil para el atacante.
AÑADIDO :
Un nonce es generado aleatoriamente por la parte que lo introduce en la conversación. Es crucial que un atacante no pueda influir en la elección del destino y, a veces, que el atacante no pueda predecir esa elección. Es bastante típico que cada una de las partes genere al menos una vez en una ejecución de un protocolo distribuido.
Hay protocolos donde un nonce se mantiene en secreto. Una clave de sesión puede ser tanto un nonce (es decir, elegido aleatoriamente por un participante) como un secreto (es decir, no se transmite directamente por cable). De hecho, en un protocolo bien diseñado, una clave de sesión a menudo se deriva de dos nonces, una vez que vienen de cada parte. Pero ser secreto no es una propiedad definitoria de los nonces.
Tomemos como ejemplo el protocolo de autenticación en la página de wikipedia . La secuencia normal de operaciones es:
- El cliente inicia una conexión con el servidor.
- El servidor genera y envía una
snonce
respaldo de nonce al cliente. - El cliente genera otro
cnonce
nonce, y lo envía más un hash de sus credenciales, el servidor nonce y el cliente nonce (hash(snonce + cnonce + password)
) al servidor. - El servidor valida el hash y acepta o rechaza el inicio de sesión.
Supongamos que Mallory (un atacante) puede observar todo el tráfico y enviar sus propios mensajes. Si obtiene el nonce después del paso 2, puede enviar sus propias credenciales al servidor. Esto podría ayudarla a causar una denegación de servicio, pero puede hacerlo de todos modos si puede inyectar tráfico. Sin las credenciales del cliente, ella no puede hacerse pasar por el cliente.
Supongamos que Mallory se apodera del paquete enviado por el cliente en el paso 3. Dado que las credenciales y el nonce están bloqueados, no puede modificar el paquete, solo puede enviarlo de nuevo como un todo. Nuevamente, dependiendo de cómo el servidor implementa el protocolo, ella podría causar una denegación de servicio, pero no más. (Tenga en cuenta que este protocolo requiere que el servidor realice un seguimiento de qué nonce está asociado con qué cliente y responde a ese cliente en el paso 4). La operación de hashing en el paso 3 es lo que evita que Mallory obtenga datos que no debe obtener (el cliente contraseña).
Para ver por qué el servidor no está allí, supongamos que falta. Entonces Mallory podría obtener un paquete que contiene hash(cnonce + passoword)
, y podría reenviarlo más tarde en una conexión por separado y, de ese modo, hacerse pasar por el cliente.
El cliente no cumple un propósito similar, aunque esto no es evidente en el protocolo simplificado descrito aquí; en un protocolo completo, el "token" incluiría un hash de datos que contienen esta fuente, y participaría en la prevención de que Mallory se haga pasar por el servidor.
El cliente no sirve también para evitar un ataque de adivinación de contraseña. Supongamos que Mallory intercepta la respuesta del servidor en el paso 2 y sustituye su propio servidor. Si el cliente respondiera con hash(snonce + password)
, esto haría más fácil para Mallory ejecutar un ataque masivo de adivinación de contraseñas: podría precomputar el hash(snonce + x)
para muchas contraseñas "fácilmente adivinables" x
, y ejecutar su ataque en muchos clientes con la esperanza de que uno tiene una contraseña débil. Aquí el cliente nonce actúa como un salt para la contraseña hash.
El cliente no contribuye también a proteger al cliente de un servidor mal implementado. Supongamos que el servidor no generó un nonce aleatorio sino una constante que Mallory podría encontrar fácilmente observando el tráfico. Entonces Mallory podría realizar el ataque de adivinación descrito en el párrafo anterior de forma pasiva. Por lo tanto, el cliente no le brinda al cliente una protección adicional, incluso si el servidor no implementa el protocolo correctamente. De manera similar, el servidor nonce le brinda al servidor cierta protección contra un cliente que no generó su nonce correctamente, nuevamente, al exigir que Mallory ataque al cliente activamente si ella quiere ejecutar un ataque de adivinación de contraseña. Este es un escenario común: el nonce de cada parte ofrece a esa parte algo de protección incluso si otra parte se desvía del protocolo.
Tengo una pregunta sobre nonce . Entiendo que es para prevenir los ataques de repetición, pero ¿qué sucede si el hacker de alguna manera obtuvo el nonce y lo usa antes que el usuario?
Si el pirata informático obtiene el nonce y lo usa antes que el usuario, el pirata informático gana. La idea de que el nonce es que en algunas situaciones es difícil para el pirata informático robar un nonce (por lo general, XSRF, el nonce está protegido por la misma política de origen). Por lo tanto, el nonce no puede proteger a su usuario si el hacker puede robar un nonce válido.