Sur la base de cet article et de cette question , les jetons d'actualisation doivent durer longtemps et les jetons d'accès doivent être de courte durée. Je conserverais mon jeton d'actualisation pendant plus ou égal à 60 jours et mon jeton d'accès pendant 20 minutes ou plus / moins mais jamais plus d'une heure.
Mon principal problème pour comprendre l'utilisation de ces jetons est la méthode de stockage des deux jetons. Je comprends que je devrais stocker le jeton d'actualisation en tant que httpOnly rendant inaccessible via un script (attaques XSS) et stocker le jeton d'accès localement, localStorage ou sessionStorage pour une utilisation dans les appels d'API en tant que clé. Est-ce la bonne façon de procéder? Dois-je chiffrer davantage le jeton d'actualisation comme recommandé dans l'article? Tout aperçu serait très apprécié, merci pour la lecture.
3 Réponses :
Tout d'abord, vous devez comprendre que vous ne pouvez absolument rien faire pour empêcher l'extraction des jetons une fois que l'attaquant a mis la main sur l'agent utilisateur des victimes (navigateur). Aucun cryptage n'aidera. Vous auriez besoin de conserver la clé de cryptage quelque part sur le client, ce qui rend toute l'idée de cryptage IMHO inutile. Parfois, les gens sont obligés de crypter des trucs comme celui-ci parce qu'ils veulent que leurs petites sœurs n'y aient pas accès ou parce que les grandes entreprises ont des politiques stupides auxquelles vous devez vous conformer.
Je vois que vous êtes prêt à conserver le jeton d'actualisation dans un cookie. Ce n'est pas grave, assurez-vous simplement de mettre en place la bonne configuration. Cette présentation devrait aider .
Un dernier conseil. La sécurité de session ne concerne pas uniquement la sécurité de session. Vous devez également effectuer le TLS, la désinfection des données et le contrôle d'accès. Si vous oubliez TLS, aucune stratégie de stockage de jetons ne vous aidera.
Pour une meilleure sécurité + une architecture globale:
Comprendre les raisons est cependant assez profond, comme dans mes articles de blog ci-dessous:
Vous pouvez avoir des objectifs différents des miens. Heureux de répondre aux questions de suivi si cela vous aide.
Merci de répondre. J'ai une question cependant. Lorsque vous parlez de la mémoire du navigateur, faites-vous référence au stockage en tant que variable js ou à l'utilisation de localStorage / sessionStorage?
Le stockage HTML5 augmente le risque de vol d'un jeton - il est donc généralement recommandé de l'éviter. Mon exemple de code montre comment cela peut être codé, et traite également des recharges de page, etc. Voir également cette page de didacticiel .
Pour répondre directement à votre question: Non, il n'y a aucune raison de crypter un jeton d'actualisation.
La seule raison de crypter un cookie est s'il contient des informations qui doivent être protégées, comme un numéro de compte, un mot de passe, etc. Un jeton d'actualisation ne contient aucune donnée significative - c'est juste un long nombre aléatoire qui pointe vers une entrée dans magasin de données.