¿Cifrado simétrico o asimétrico para el token web JSON?

Question

¿Cifrado simétrico o asimétrico para el token web JSON?

#1 de Claude (3 votos)
#2 de Alex (1 votos)
#3 de cjk (1 votos)

8

Estamos planeando usar JSON Web Tokens (JWT) para nuestro servidor de autenticación, y actualmente estoy evaluando qué enfoque de encriptación se debe tomar para el token JWE.

Parece que hay dos opciones para administrar la clave de cifrado simétrica:

El emisor / destinatario comparte previamente una clave simétrica y encripta todos los tokens usando eso; la clave simétrica no está incluida en el mensaje.
El emisor genera una clave simétrica por token, luego cifra el token utilizando la clave pública del destinatario y lo incluye en el mensaje.

No me parece que haya ninguna ventaja de seguridad inherente de ninguno de los dos, siempre que se utilicen algoritmos lo suficientemente sólidos y tamaños de clave lo suficientemente grandes.

Parece que la principal diferencia es que, en el primer caso, el destinatario debe confiar en que el emisor no filtrará la clave compartida previamente, mientras que en el segundo caso solo el destinatario tendrá la clave de descifrado necesaria. Sin embargo, dado que la carga útil de este token JWE será un token JWS firmado, el destinatario también debe tener una sólida relación de confianza con el emisor y debe confiar en que no pierda su propia clave de firma privada, por lo que no parece ser un gran problema. problema.

Dado que la opción 1 produce un token mucho más pequeño (debido a que no tiene una clave simétrica cifrada incrustada), ¿hay alguna buena razón para preferir la opción 2?

cryptography encryption json

pregunta Greg Beech 26.03.2013 - 16:10

fuente

3 respuestas

Lea otras preguntas en las etiquetas cryptography encryption json

Javascript Malware: ¿Cómo funciona y cómo se puede mitigar? ¿Cómo puedo saber si un túnel PPTP es seguro?

score 3 · Answer 1

Yo diría que la principal ventaja de la opción 2 es que no es necesario distribuir (o actualizar en caso de que se vea comprometida) una clave previamente compartida. Si de alguna manera puede asegurarse de contar con un mecanismo seguro para transferir la clave compartida previamente (es decir, solo hay una persona con la que debe hacer esto y confía en hablar con ellos por teléfono y deletrear la clave) - Obviamente, esto tiene riesgos de seguridad (toques telefónicos, teclas escritas en el papel en el otro extremo, etc.) que necesita evaluar. Optaría por la opción 1. Sin embargo, si desea crear una interfaz API donde los clientes puedan conectarse conexiones seguras sin un intercambio de claves fuera de banda, vaya a la opción 2.

score 1 · Answer 2

Para la opción 1, tanto el emisor como el destinatario deben mantener la clave simétrica en secreto. Si su destinatario es un servicio de nube de múltiples inquilinos producido y mantenido por una parte diferente, esto puede ser demasiado riesgoso, si alguien obtiene acceso a los archivos de configuración o la base de datos, les permitirá crear tokens para hacerse pasar por alguien en el sistema.

La opción 2 establece la responsabilidad de mantener la clave en secreto en el emisor. Si usted es el destinatario, esto alivia muchas preocupaciones de responsabilidad y seguridad ya que solo tiene la clave pública. Como emisor, usted obtiene más confianza ya que es el único responsable de la seguridad de su clave de cifrado privada.

Así que realmente se reduce a cuánto confía en que el destinatario mantendrá segura la clave simétrica, y si usted es el destinatario, está dispuesto a apostar su producto y su reputación, puede mantenerlo seguro.

score 1 · Answer 3

Solo quiero poner esto aquí para las personas que lo encuentren a través de Google (actualmente, segundo resultado para buscar jwt public private vs symmetric )

La opción 2 aquí es una fuga de seguridad: si el emisor cifra un mensaje usando la clave pública del receptor, entonces sí, el receptor es la única persona que puede descifrar la información, pero con JWT la seguridad necesaria es que JWT está completamente intacto y no ha sido modificado. El cifrado con una clave pública no hace eso, cualquiera puede hacer lo mismo y hacerse pasar por el emisor .

La solución real es FIRMAR el token con la clave PRIVADA del emisor, luego cualquiera puede confirmar con la clave PÚBLICA del emisor que el emisor sí confirmó esa autoridad en el JWT.