Que se passe-t-il si JWT est volé?

J’essaie d’implémenter une authentification sans état avec JWT pour mes API RESTful.

AFAIK, JWT est essentiellement une chaîne cryptée transmise en tant qu’en-têtes HTTP lors d’un appel REST.

Mais que se passe-t-il si une oreille indiscrète voit la demande et vole le jeton ? Ensuite, il pourra simuler une demande avec mon identité?

En fait, cette préoccupation s’applique à toutes les authentifications basées sur des jetons .

Comment prévenir cela? Un canal sécurisé comme HTTPS?

Je suis l’auteur d’une bibliothèque de noeuds qui gère l’authentification dans une certaine profondeur, express-stormpath , donc je vais vous donner quelques informations ici.

Tout d’abord, les JWT ne sont généralement PAS cryptés. Bien qu’il existe un moyen de chiffrer les JWT (voir: JWEs ), cela n’est pas très courant dans la pratique pour de nombreuses raisons.

Ensuite, toute forme d’authentification (utilisant ou non des JWT) est sujette à des attaques de type MitM (Man-In-The-Middle). Ces attaques se produisent lorsqu’un attaquant peut AFFICHER LE TRAVAIL DE VOTRE RÉSEAU lorsque vous faites des demandes sur Internet. C’est ce que votre fournisseur de services Internet peut voir, la NSA, etc.

C’est ce que SSL permet de prévenir: en chiffrant votre trafic NETWORK depuis votre ordinateur -> certains serveurs lors de l’authentification, un tiers qui surveille votre trafic réseau ne peut PAS voir vos jetons, mots de passe ou quelque chose du genre pour obtenir une copie de la clé SSL privée du serveur (improbable). C’est la raison pour laquelle SSL est OBLIGATOIRE pour toutes les formes d’authentification.

Disons, cependant, que quelqu’un est capable d’exploiter votre SSL et est capable d’afficher votre jeton: la réponse à votre question est que OUI , l’attaquant sera capable d’utiliser ce jeton pour vous emprunter et faire des requêtes à votre serveur.

Maintenant, c’est là que les protocoles entrent en jeu.

Les JWT ne sont qu’un standard pour un jeton d’authentification. Ils peuvent être utilisés à peu près n’importe quoi. La raison pour laquelle les JWT sont en quelque sorte cool est que vous pouvez y intégrer des informations supplémentaires, et vous pouvez valider que personne ne les a manipulées (signature).

CEPENDANT, les JWT elles-mêmes n’ont rien à voir avec la «sécurité». À toutes fins utiles, les JWT sont plus ou moins la même chose que les clés API: juste des chaînes aléatoires que vous utilisez pour vous authentifier sur un serveur quelque part.

Ce qui rend votre question plus intéressante est le protocole utilisé (très probablement OAuth2).

La façon dont fonctionne OAuth2, c’est qu’il a été conçu pour donner aux clients des jetons TEMPORAIRES (comme les JWT!) Pour l’authentification pour une courte période de temps seulement!

L’idée est que si votre jeton est volé, l’attaquant ne peut l’utiliser que pendant une courte période.

Avec OAuth2, vous devez vous authentifier régulièrement auprès du serveur en fournissant vos identifiants de nom d’utilisateur / mot de passe OU d’API, puis en récupérant un jeton en échange.

Parce que ce processus se produit de temps en temps, vos jetons changent fréquemment, ce qui rend plus difficile pour les attaquants de vous emprunter sans avoir à vous soucier des problèmes.

Espérons que cela aide ^^

Je sais que c’est une vieille question mais je pense que je peux laisser tomber mes 0,50 $ ici, probablement que quelqu’un peut améliorer ou fournir un argument pour refuser totalement mon approche. J’utilise des JWT dans une API RESTful sur HTTPS (ofc).

Pour que cela fonctionne, vous devez toujours émettre des jetons de courte durée (en fonction de la plupart des cas, dans mon application, je mets la revendication exp à 30 minutes, et ttl à 3 jours, de sorte que vous pouvez actualiser ce jeton ttl est toujours valide et le jeton n’a pas été mis sur liste noire )

Pour le authentication service , afin d’invalider les jetons, j’aime utiliser une couche de cache en mémoire ( redis dans mon cas) en tant que JWT blacklist / ban-list JWT blacklist en face, selon certains critères: philosophie, mais les documents stockés sont vraiment de courte durée, comme je liste noire pour le temps restant à vivre – ttl claim-)

Remarque: les jetons sur liste noire ne peuvent pas être automatiquement actualisés

  • Si user.password ou user.email a été mis à jour (requirejs la confirmation du mot de passe), auth service renvoie un jeton actualisé et invalide (liste noire) le ou les précédents, donc si votre client détecte que l’identité de l’utilisateur a été compromise, vous pouvez demander cet utilisateur pour changer son mot de passe. Si vous ne souhaitez pas utiliser la liste noire pour cela, vous pouvez (mais je ne vous encourage pas à) valider la revendication iat (publiée chez) sur le champ user.updated_at (si jwt.iat < user.updated_at alors JWT est pas valide).
  • Utilisateur délibérément déconnecté.

Enfin, vous validez le jeton normalement, comme tout le monde le fait.

Note 2: au lieu d'utiliser le jeton lui-même (qui est vraiment long) comme clé du cache, je suggère de générer et d'utiliser un jeton UUID pour la revendication jti . Ce qui est bien et je pense (pas sûr puisque cela m'est venu à l’esprit), vous pouvez utiliser ce même UUID comme jeton CSRF, en retournant un cookie secure / non-http-only avec et en implémentant correctement le X-XSRF-TOKEN tête X-XSRF-TOKEN utilisant js. De cette façon, vous évitez le travail informatique de création d’un autre jeton pour les contrôles CSRF.