¿Hay algún beneficio de usar JWT sin estado sobre hash SHA256 para tokens de API?

4

¿Tiene sentido usar JWT sin estado (sin almacenamiento persistente) sobre SHA256 simple?

Escenario de ejemplo:

  1. El usuario inicia sesión

  2. El token de usuario se genera de la siguiente manera:
    a. JWT.encode (ID de usuario, 'secreto')
    o
    segundo. SHA256 (userId + 'secreto')

  3. La aplicación del cliente envía la solicitud con el ID de usuario y el token

  4. La solicitud se verifica a través de:
    a. JWT.decode (token, 'secreto'), luego verifica que JWT.userId resultante se compara con el userId de solicitud
    o
    segundo. SHA256 (userId + 'secreto'), luego verifica que el hash resultante se compara con el token de solicitud

JWT permite la caducidad del token, sin embargo, más allá de eso, no veo ningún beneficio.

    
pregunta SyBer 07.05.2015 - 22:19
fuente

1 respuesta

3
  

¿Tiene sentido usar JWT sin estado (sin almacenamiento persistente)   sobre SHA256 simple?

Lo que esencialmente estás haciendo con "SHA256 simple" es firmar los datos y enviar los datos + la firma por separado. JWT codifica la firma y los datos juntos, pero en ambos casos básicamente estás firmando los datos que envían la firma + datos.

En esencia, tanto a como b hacen básicamente lo mismo.

Habiendo dicho eso, hay varias razones por las que JWT es superior al método que has propuesto.

Uso de HMAC

HMAC resuelve algunas debilidades de simplemente hash datos + una clave secreta:

  

Por ejemplo, uno podría asumir la misma seguridad que HMAC proporciona   podría lograrse con MAC = H (clave ∥ mensaje). Sin embargo, este método   sufre de un defecto grave: con la mayoría de las funciones hash, es fácil   adjuntar datos al mensaje sin conocer la clave y obtener otra   MAC válido ("ataque de extensión de longitud"). La alternativa, anexando el   La tecla que usa MAC = H (mensaje ∥ tecla), tiene el problema de que una   El atacante que puede encontrar una colisión en la función hash (sin clave) tiene una   colisión en el MAC (como dos mensajes m1 y m2 que producen el mismo hash   proporcionará la misma condición de inicio a la función hash antes de la   la clave adjunta está en hash, por lo que el hash final será el mismo).

enlace

Compatibilidad con la criptografía de clave pública

Para generar el MAC utilizando SHA256 solo, es necesario que ambas partes conozcan el secreto de texto sin formato.

Esto es difícil de mantener de forma segura como:

a. El secreto debe almacenarse y recuperarse en formato de texto plano, por lo que ninguna de las partes puede almacenar el secreto como un hash salado. Esto es particularmente un problema para el lado de verificación / servidor en una aplicación web que podría necesitar almacenar secretos para miles de usuarios.

b. Las partes deben comunicar el secreto compartido de alguna manera

JWT admite RSA, que es un sistema de cifrado de clave pública. Por lo tanto, la parte firmante debe asegurar su clave privada, pero la parte verificadora (es decir, generalmente el servidor) solo tiene que conocer la clave pública. La clave pública es información pública, por lo que no necesita ser almacenada de forma segura.

Las claves públicas también son más fáciles de compartir, ya que no es necesario comunicar nada que pueda usarse para firmar mensajes (aunque un atacante podría sustituirlo por su propia clave pública), a diferencia del método sin RSA donde el secreto debe ser comunicado.

    
respondido por el thexacre 08.05.2015 - 01:56
fuente

Lea otras preguntas en las etiquetas