¿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.