Buscamos en todo el mundo online para darte la solución a tu problema, en caso de alguna difcultad deja tu pregunta y contestaremos con mucho gusto, porque estamos para servirte.
Solución:
La respuesta corta es utilizar RS256, que debe entenderse como SHA 256 con RSA 2048 bits keys.
Consulte RFC 7518 JSON Web Algorithms (JWA) para conocer todos los algoritmos compatibles.
Sobre la firma de algoritmos
Hay dos algoritmos de firma principales compatibles con JWT: RSA y ECDSA.
-
RSA(como enalg:RS256) es el algoritmo de firma asimétrico clásico basado en factorización prima. Es muy bien entendido y muy apoyado. En mi opinión, no hay razón para usar nada más que RSA. Recomendado key el tamaño es de 2048 bits. -
ECDSA(como enalg:ES256) es un algoritmo asimétrico alternativo basado en curvas elípticas. Comenzó a ganar tracción en la década de 2010 como una alternativa a RSA. No es tan compatible como RSA, pero tiene algo de soporte (especialmente para SSH keys) y está creciendo. Es útil tener dos alternativas si una de ellas se rompe en el futuro. No creo que tenga sentido usar ECDSA además de ser de vanguardia, porque RSA hace el trabajo bien, mientras que las bibliotecas ECDSA no son tan frecuentes y han tenido problemas no hace mucho tiempo.
Vea la notable vulnerabilidad CVE-2020-0601 que rompe la criptografía de curvas elípticas en todos los productos y bibliotecas de Microsoft. En resumen, hubo un pequeño error en la implementación, por lo que la verificación de las cosas no verificaría nada en absoluto. Reutilizará bibliotecas aleatorias de Internet para verificar los tokens JWT en sus diversas aplicaciones en varios idiomas. Sería cauteloso si las bibliotecas pueden implementar ECDSA bien cuando Microsoft y consorte no pudieron. RSA simplemente no tiene este tipo de errores porque es más simple y las bibliotecas se han revisado durante décadas.
HS256(como enalg:HS256): Un precompartido key modo. Hay uno solo key para firmar y verificar tokens. El cliente y el servidor deben conocer EL key. No conozco ningún caso de uso para esto, así que hágase un favor e ignore los modos HSxxx por completo.
Sobre algoritmos hash
Hay tres algoritmos hash principales compatibles con JWT: SHA256, SHA384 y SHA512.
Tienen una longitud cada vez mayor para resistir los avances en la potencia informática.
SHA256 es lo suficientemente seguro, no se puede descifrar en un tiempo razonable con un centro de datos completo, no hay razón para favorecer los algoritmos más fuertes y lentos.
Tenga en cuenta que SHA1, 160 bits, nunca fue compatible con JWT porque se consideró inseguro y no a prueba de futuro en la década de 2010 cuando se planeó JWT.
Rendimiento
Cuando se trata de RSA vs ECDSA, no hay ninguna conclusión general que se pueda hacer sobre el desempeño relativo. Cualquiera puede ser más rápido que el otro.
Depende completamente de la biblioteca en uso y de la CPU específica.
Un punto de tener tokens estándar es admitir más fácilmente la autenticación en sus diferentes aplicaciones (Python, Java, C, C #, etc.) usando diferentes bibliotecas, por lo que sería realmente un error llegar a una conclusión general sobre el rendimiento. Debe ejecutar un punto de referencia para usted mismo si le importa el rendimiento.
Como referencia, la verificación de tokens es del orden de un milisegundo en términos generales (léase: es mucho más largo que un microsegundo y es mucho más corto que un segundo).
No confunda las recomendaciones de hash de contraseñas con las recomendaciones de JWT. La mayoría de las recomendaciones de cifrado que encontrará en Internet (incluido el desbordamiento de pila) están orientadas al hash de contraseñas (a menudo con una de PBKDFD2 / bcrypt / scrypt / argon), que es un caso de uso diseñado y configurado para ser lento, posiblemente hasta un total segundo para calcular un hash. Los tokens JWT deben verificarse en cada “llamada” y están destinados a ser lo suficientemente rápidos para el uso de la API.
Tamaño y robustez de la clave
Talla recomendada:
- SHA de 256 bits
- RSA con 2048 bits key
- ECDSA con curva P-256
Consulte RFC 7518 JSON Web Algorithms (JWA) para conocer todos los algoritmos compatibles.
Estos son los ajustes recomendados para la década 2020-2030. Esto puede resistir a un atacante que dedica un centro de datos para intentar descifrar el key.
Los sistemas de autenticación (que utilizan JWT) están destinados a admitir la autenticación para clientes externos en la web y para los empleados internos de una empresa. Eso necesidades para resistir este tipo de ataque.
Tenga en cuenta que todas las grandes empresas, universidades, centros de investigación e instituciones gubernamentales (#NSA) tienen redes de cómputo a su disposición, por lo que es realmente “trivial” adquirir unos pocos miles de servidores para utilizar la fuerza bruta key.
(Las recomendaciones pueden revisarse en 2030 cuando AWS / Google alquilará centros de datos completos de 60000 GPU futuras).
RFC7518 enumera los algoritmos y si son obligatorios, recomendados u opcionales para una biblioteca JWT. Esto puede ayudarlo a elegir un algoritmo que tenga implementaciones en otras bibliotecas, con fines de interoperabilidad.
Desde una perspectiva de seguridad, existen estas opciones:
- RSASSA frente a ECDSA. ECDSA usa curvas elípticas y algunas personas piensan que son más seguras que RSA. También son más rápidos y le permiten usar más pequeños keys.
- SHA256, SHA384, SHA512. Se podría decir que más es mejor, pero dado que SHA256 ya es imposible de usar por fuerza bruta, tiene poco sentido usar más bits.
- PKCS1-v1_5 frente a PSS. PSS tiene algunas ventajas de seguridad, pero es más complejo que PKCS1, lo que posiblemente haga más probables los errores de implementación.
Todas estas opciones son seguras y las diferencias son en gran parte teóricas. Probablemente recomendaría ECDSA usando P-256 y SHA-256 (alg valor del parámetro ES256 en la especificación), ya que
- que es probable que se implemente en muchas implementaciones de JWT, según el RFC,
- utiliza curvas elípticas que tienen ligeras ventajas de seguridad y rendimiento.
La otra respuesta mencionó las computadoras cuánticas. No tenemos computadoras cuánticas viables en este momento, pero si existieran, podrían romper fácilmente todos los algoritmos JWT posibles. Entonces, desde un punto de vista post-cuántico, no importa cuál elijas, ya que todos son igualmente inseguros.
Ver también:
- ¿Es RSASSA-PKCS1-v1_5 un buen esquema de firma para nuevos sistemas?
- ¿Debería usar PKCS1 v1.5 o PSS para firmas RSA?
valoraciones y reseñas
Si conservas alguna incertidumbre o disposición de innovar nuestro artículo eres capaz de realizar una ilustración y con placer lo estudiaremos.