Bonnes Pratiques J.W.T.
J.W.T. comme moyen d’authentification ou d’autorisation, why not mais avec quelles conditions ?
1 – Utilisation de clés asymétriques.
2 – Taille minimum de la clé 2048 bits (4096 bits, c’est mieux).
3 – Mise en place d’une rotation automatique de clés (~ une rotation par jour).
Attention : Les J.W.T. auront donc une durée de vie inférieure à la durée de vie de la clé.
4 – Key Sharding : Utilisation de différentes clés pour différents groupes d’entité afin de limiter la casse en cas de perte de clé.
5 – Pour éviter la fuite de la clé, il faudrait utiliser un HSM (Hardware Security Module) mais c’est pas donné : https://aws.amazon.com/cloudhsm/pricing/.
Sinon, la solution du pauvre est un SoftHSM, un service dédié aux tâches crypto : https://github.com/opendnssec/SoftHSMv1.
Si l’attaquant prend le contrôle de l’application, il peut donc générer des tokens mais il faut réussir une attaque persistante (donc probablement bruyante. Cf. audit log) autrement, même si l’application est vulnérable et qu’elle dévoile ses secrets, l’attaquant ne pourra récupérer la clé que s’il trouve une vulnérabilité dans le SoftHSM et il est conceptuellement plus difficile de trouver une vulnérabilité dans une application mono-tâche dédiée à la sécurité que dans une grosse application.
6 – Mettre en place un monitoring sécurité avancé : analyse des logs etc… et déclenchement d’alertes dès détection de tokens J.W.T. invalides ou usage abusif du HSM etc… https://www.splunk.com/
On peut être cool sans utiliser J.W.T.
Donc voilà comment J.W.T. devrait être utilisé.
Ne vous laissez pas tenter naïvement par les J.W.T. Hipsters. Peut-être qu’un simple générateur de tokens : https://docs.python.org/3/library/secrets.html à 256bits avec un stockage en DB suffit.
Ca casse le côté distribué charmant de J.W.T. vu que les bases où sont stockés les tokens deviennent un Single Point of Failure.
En parlant du Single Point of Failure, comment peut-on gérer la révocation (par exemple, quand vous partager un document avec quelqu’un par erreur) ? ou plus simplement, l’invalidation du J.W.T. au logout ?
A ce moment là, il nous faudrait donc une DB pour stocker la liste des tokens valides ou invalides et il faudra donc vérifier les tokens à chaque utilisation et on retombe dans le Single Point of Failure. Si on ne le fait pas à chaque utilisation, on prend des risques… acceptables ?
Google, OpenID Connect et J.W.T.
Face aux importants risques sécurité associés au fonctionnement du mode “implicit” d’OpenID Connect. C’est à dire, un token J.W.T. on the browser, le commentaire de Google est assez clair :
https://developers.google.com/identity/protocols/OpenIDConnect
Authenticating the user involves obtaining an ID token and validating it. ID tokens are a standardized feature of OpenID Connect designed for use in sharing identity assertions on the Internet.
The most commonly used approaches for authenticating a user and obtaining an ID token are called the “server” flow and the “implicit” flow. The server flow allows the back-end server of an application to verify the identity of the person using a browser or mobile device. The implicit flow is used when a client-side application (typically a JavaScript app running in the browser) needs to access APIs directly instead of via its back-end server.
This document describes how to perform the server flow for authenticating the user. The implicit flow is significantly more complicated because of security risks in handling and using tokens on the client side. If you need to implement an implicit flow, we highly recommend using Google Sign-In.
Conclusion
Une utilisation robuste de J.W.T. est très coûteuse en terme de développement (Ex. si vous utilisez un H.S.M., il faudra “customizer” les libs J.W.T.). L’implémentation de la révocation avec J.W.T.s en fait perdre quasiment tout l’intérêt.
Si vous utilisez J.W.T. sans H.S.M., la moindre vulnérabilité permettant d’accéder à la clé (variable d’environnement, DB, filesystem, source code, un schtroumpf grincheux dans l’entreprise) va corrompre tout le système.
Ne comptez pas sur la sécurité par l’obscurité.
L’utilisation de tokens randoms générés à la demande permet d’atteindre un niveau de sécurité équivalent avec beaucoup moins d’effort à condition que la génération soit suffisamment imprédictible.
Dans tous les cas, n’hésitez pas à faire appel à de l’expertise sécurité interne ou externe 😉
La sécurité, c’est comme la User eXperience, il n’y a pas de solution magique qui répond à tous les besoins avec un module qu’on installe en un clic : `yarn add please-secure-my-app`.
Wishtack 