¿Podría funcionar este tipo de sistema JWT?

Question

¿Podría funcionar este tipo de sistema JWT?

#1 de symcbean (1 votos)
#2 de Luke Park (0 votos)

1

Estoy estudiando JSON Web Tokens, y quiero intentar crear mi propio servidor de autenticación (no te preocupes, esto no se ejecutará en producción en ninguna parte). Mi entendimiento hasta ahora es el siguiente: creas una cadena JSON que contiene todos los datos que deseas, y creas un hash basado en estos datos usando un secreto, que también incluyes en el JWT. El secreto se comparte entre el servidor de autenticación y el servidor de aplicaciones. El servidor de aplicaciones al que envía sus solicitudes usa el mismo secreto para volver a calcular el hash y lo compara con el de JWT.

Ahora, si por alguna razón su servidor de aplicaciones se ve comprometido y el secreto sale a la luz, no tiene suerte. Y es posible que no desee que sus usuarios analicen sus JWT. Así que se me ocurrió esta idea:

Hacer que el servidor de autenticación encripte el JWT con una clave privada, y luego que el servidor de la aplicación lo descifre con la clave pública significa dos cosas: los clientes no pueden inspeccionar el contenido de sus JWT, y un servidor de aplicaciones comprimido significa que aún no se pueden crear archivos JWT falsos, ya que la clave privada aún no está comprometida. Descifrar con la clave pública también significa que sabe que el JWT es del servidor de autenticación. Por lo que puedo decir, el cifrado con la clave privada y el descifrado con la clave pública, si bien son inusuales, no deberían llevar a un cifrado más débil.

Mi pregunta: ¿hay algún error en mi forma de pensar que podría hacer que este tipo de sistema de autenticación no funcione o sea fácil de transigir?

cryptography asymmetric jwt

pregunta ohyeah 27.01.2017 - 19:21

fuente

2 respuestas

Lea otras preguntas en las etiquetas cryptography asymmetric jwt

Seguridad de los archivos eliminados y sus rastros Error en la conexión VNC: demasiados fallos de seguridad

score 1 · Answer 1

Lo que describe aquí es poco más que un identificador de sesión generado aleatoriamente, sin embargo, la mayoría de las cosas que lo diferencian de un identificador de sesión son una desventaja para su seguridad. La única ventaja es que está almacenando el estado en el cliente y, por lo tanto, tiene una solución escalable y tolerante a fallos. Pero requiere bastante procesamiento para descifrar un cifrado asimétrico.

Sin embargo, como el token contiene datos encriptados, usted confía en la efectividad del algoritmo y su implementación. Los usuarios estarán en posesión tanto del texto encriptado como de al menos parte del texto en claro, lo que es una gran ayuda para romper el cifrado.

Como se describe, no hay nada que proteger contra un mitm (por ejemplo, establecer un mecanismo de renegociación de ttl y clave) o un ataque xss.

Tal como está, debe ser muy cuidadoso con la disposición del secreto, por ejemplo, en copias de seguridad, discos fallidos, imágenes san, etc. Compare esto con un ID de sesión aleatorio que caduque con la sesión.

Ciertamente, dividir el par de claves (no parece ser un requisito para que cualquiera de las partes se considere "pública") agrega algún valor, especialmente si el servidor de autenticación está ejecutando una pila de software diferente y no está expuesto en Internet.

Pero personalmente, preferiría un servidor SSO que use protocolos establecidos (por ejemplo, openam) y un identificador de sesión aleatorio, opcionalmente complementado con tokens de un solo uso en el almacenamiento local para la seguridad del sombrero de hojalata.

score 0 · Answer 2

Normalmente no me gusta decir "sí, esto es seguro", pero iré tan lejos como para decir que se ve parece teóricamente seguro para mí, basado en La información facilitada. Sin embargo ...

Aparte de las cosas obvias, como el límite de la cantidad de datos que podría contener un token (suponiendo RSA) y el hecho de que todos sus tokens serían ~ 256 bytes o más (eso es un montón de datos para enviar en cada solicitud), No creo que su sistema ayude en absoluto si su servidor de aplicaciones estuviera comprometido, ¿creo que fue la idea original?

Primero, el servidor comprometido podría simplemente seguir solicitando tantos tokens como quiera desde el servidor de autenticación. Sin mencionar el hecho de que no sería necesario porque de todos modos es el que verifica los tokens. Simplemente se puede reprogramar para aceptar cualquier token o no token en absoluto.

En teoría, su sistema tiene sentido y parece seguro para mí , lo que no significa mucho. ¡Pero un servidor comprometido es un servidor comprometido al final del día!