security - decoded - Si puedes decodificar JWT, ¿cómo están seguros?
jwt desencriptar (5)
Los JWT pueden estar firmados, encriptados o ambos. Si se firma un token, pero no se cifra, todos pueden leer el contenido del token, pero cuando no conoces la clave privada, no puedes cambiarla. De lo contrario, el receptor notará que la firma ya no coincidirá.
Responde a tu comentario: no estoy seguro si entiendo tu comentario de la manera correcta. Solo para estar seguro: ¿conoces y entiendes las firmas digitales? Explicaré brevemente una variante (HMAC, que es simétrica, pero hay muchas otras).
Supongamos que Alice quiere enviar un JWT a Bob. Ambos saben algún secreto compartido. Mallory no conoce ese secreto, pero quiere interferir y cambiar el JWT. Para evitar eso, Alice calcula Hash(payload + secret) y lo agrega como firma.
Al recibir el mensaje, Bob también puede calcular Hash(payload + secret) para verificar si la firma coincide. Sin embargo, si Mallory cambia algo en el contenido, no puede calcular la firma correspondiente (que sería Hash(newContent + secret) ). Ella no conoce el secreto y no tiene forma de averiguarlo. Esto significa que si ella cambia algo, la firma ya no coincidirá y Bob simplemente ya no aceptará el JWT.
Supongamos, le envío a otra persona el mensaje {"id":1} y lo firmo con Hash(content + secret) . (+ es solo concatenación aquí). Yo uso la función SHA256 Hash, y la firma que obtengo es: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c . Ahora es tu turno: juega el papel de Mallory e intenta firmar el mensaje {"id":2} . No puedes porque no sabes qué secreto usé. Si supongo que el destinatario conoce el secreto, PUEDE calcular la firma de cualquier mensaje y verificar si es correcto.
Me encanta JWT, es muy divertido trabajar con él. Mi pregunta es, si obtengo un JWT y puedo decodificar la carga útil, ¿cómo es eso seguro? ¿No podría simplemente sacar la ficha del encabezado, decodificar y cambiar la información del usuario en la carga y devolverla con el mismo secreto codificado correcto?
Sé que deben serlo, realmente me gusta entender las tecnologías. ¿Qué me estoy perdiendo? ¡Gracias!
Los contenidos en un token web json (JWT) no son intrínsecamente seguros, pero hay una función incorporada para verificar la autenticidad del token. Un JWT es tres hashes separados por puntos. El tercero es la firma. En un sistema de clave pública / privada, el emisor firma la firma del token con una clave privada que solo puede verificarse mediante su clave pública correspondiente.
Es importante entender la distinción entre emisor y verificador. El destinatario del token es responsable de verificarlo.
Hay dos pasos fundamentales para usar JWT de forma segura en una aplicación web: 1) enviarlos a través de un canal encriptado, y 2) verificar la firma inmediatamente después de recibirla. La naturaleza asimétrica de la criptografía de clave pública hace posible la verificación de firma JWT. Una clave pública verifica que un JWT fue firmado por su clave privada correspondiente. Ninguna otra combinación de claves puede hacer esta verificación, evitando así los intentos de suplantación. Siga estos dos pasos y podemos garantizar con certeza matemática la autenticidad de un JWT.
Más lectura: ¿Cómo verifica una clave pública una firma?
Los datos dentro de JWT están firmados y encriptados, no significa que sea seguro. JWT no proporciona garantía para datos confidenciales.
los datos se cifran utilizando una clave privada que es conocida por ambas partes, es decir, el remitente y el receptor, un intruso puede frenar la clave y puede cambiar el contenido.
Según tengo entendido, JWT no brinda seguridad.
Gracias
Puede ir a jwt.io , pegar su token y leer los contenidos. Esto es discordante para mucha gente inicialmente.
La respuesta corta es que JWT no se preocupa por el cifrado. Se preocupa por la validación. Es decir, siempre puede obtener la respuesta para "¿Ha manipulado el contenido de este token"? Esto significa que la manipulación del token JWT por parte del usuario es inútil porque el servidor sabrá y no tendrá en cuenta el token. El servidor agrega una firma basada en la carga al emitir un token al cliente. Más tarde verifica la carga útil y la firma correspondiente.
La pregunta lógica es ¿cuál es la motivación para no preocuparse por los contenidos encriptados?
La razón más simple es porque asume que este es un problema resuelto en su mayor parte. Si se trata de un cliente como el navegador web, por ejemplo, puede almacenar los tokens JWT en una cookie que es
secure + httpsOnly(no puede leerse con Javascript + no se puede leer por HTTP) y habla con el servidor a través de un canal encriptado (HTTPS). Una vez que sepa que tiene un canal seguro entre el servidor y el cliente, puede intercambiar de forma segura JWT o cualquier otra cosa que desee.Esto mantiene la cosa simple. Una implementación simple facilita la adopción pero también permite que cada capa haga lo que mejor hace (deje que HTTPS maneje el cifrado).
JWT no está destinado a almacenar datos confidenciales. Una vez que el servidor recibe el token JWT y lo valida, es libre de buscar el ID de usuario en su propia base de datos para obtener información adicional para ese usuario (como permisos, dirección postal, etc.). Esto mantiene JWT pequeño en tamaño y evita la pérdida involuntaria de información porque todo el mundo sabe que no debe mantener datos confidenciales en JWT.
No es muy diferente de cómo funcionan las cookies. Las cookies a menudo contienen cargas útiles no encriptadas. Si está utilizando HTTPS, entonces todo está bien. Si no es así, es recomendable cifrar las cookies confidenciales. Si no lo hace, significará que es posible un ataque de hombre en el medio: un servidor proxy o ISP lee las cookies y luego las reproduce más adelante fingiendo ser usted. Por razones similares, JWT siempre debe intercambiarse a través de una capa segura como HTTPS.
Solo la clave privada de JWT, que está en su servidor, descifrará el JWT encriptado. Aquellos que conocen el privateKey podrán descifrar el JWT encriptado.
Oculte la clave privada en una ubicación segura en su servidor y nunca le cuente a nadie la clave privada.