Blog

Dans un article précédent, Zix | AppRiver a expliqué comment les responsables de l’attaque SolarWinds avaient abusé des jetons et des certificats dans le cadre de leur chaîne d’infection. Les acteurs malveillants ont ensuite abusé de ces mêmes types d’actifs dans des campagnes supplémentaires ciblant d’autres entités. Cela a entraîné un incident de sécurité de certificat confirmé chez un fournisseur de sécurité de messagerie.

Reconnaissant ces activités malveillantes, Zix / AppRiver a estimé nécessaire de fournir à ses clients une série d’articles qui discutent des types de méthodes d’authentification concernés et de leur fonctionnement. Nous allons commencer par l’authentification basée sur des jetons.

Authentification basée sur des jetons : Un aperçu

L’authentification basée sur des jetons résout certaines des limitations de l’authentification basée sur des sessions. Dans ce dernier cas, un serveur crée une session pour un utilisateur lorsqu’il se connecte. Il stocke l’ID de session dans un cookie, qui accompagne toutes les demandes ultérieures si l’utilisateur reste connecté. Le serveur vérifie ensuite l’identité d’un utilisateur en comparant le cookie aux données de session stockées en mémoire.

Le problème ici est que l’authentification par session présente certains inconvénients. Tout d’abord, cela nécessite que le serveur stocke les sessions dans sa mémoire. Il y a aussi le problème des cookies fonctionnant sur plusieurs appareils de différents supports (tels que le Web et les mobiles).

C’est là qu’intervient l’authentification par jeton. Cette forme d’authentification implique une application fournissant un jeton signé au client lors de la validation d’un ensemble d’informations d’identification de l’utilisateur. Le client stocke ce jeton et l’envoie avec chaque demande, à quel moment le serveur vérifie le jeton et envoie des informations.

En ce sens, l’authentification basée sur un jeton diffère de l’authentification basée sur une session en ce sens qu’elle est sans état. Il ne s’agit pas de stocker des informations sur un utilisateur sur un serveur ou dans une session. Il stocke ces données dans le jeton côté client.

Avantages et défis de l’authentification par jeton

L’authentification par jeton présente de nombreux avantages. Chop-Chop note que les jetons fonctionnent également sur différents sites Web et supports, ce qui crée une opportunité pour une plus grande diversité d’utilisateurs — en particulier ceux qui utilisent des appareils mobiles. En plus de tout cela, les jetons représentent les informations d’identification d’un utilisateur dans le processus d’octroi de l’accès aux données ; une personne qui a compromis un jeton n’aurait pas automatiquement accès aux informations d’identification du compte de l’utilisateur concerné.

Cela étant dit, l’authentification basée sur des jetons n’est pas sans défis. Le groupe Devbridge note que certains jetons de session ne sont pas générés de manière sécurisée, par exemple. Cela permet à un attaquant avec un échantillon suffisamment important d’ID de session de comprendre un modèle et de deviner les jetons pour un plus grand nombre d’utilisateurs. Il y a aussi le problème des attaquants tirant parti des stockages de jetons non sécurisés, de plusieurs connexions et / ou de longs délais de validation des jetons pour voler des secrets d’authentification.

Comment utiliser en toute sécurité l’authentification basée sur des jetons

Compte tenu des risques discutés ci-dessus, voici quelques bonnes pratiques pour utiliser en toute sécurité l’authentification basée sur des jetons:

1. Générez des jetons forts. En particulier, Devbridge recommande que les jetons comportent un grand ensemble de valeurs possibles, intègrent un degré de pseudo-aléatoire et comprennent au moins 16 octets de longueur.
2. Donne aux jetons une expiration. Il est important de définir des conditions pour combien de temps un jeton reste valide, note Auth0. De toute évidence, si un utilisateur est toujours actif, le jeton peut se renouveler automatiquement. Mais il est également judicieux de permettre à un jeton d’expirer lorsque l’utilisateur se déconnecte et de le mettre fin, peu importe ce qui s’est passé après un certain laps de temps.
3. Interdire plusieurs connexions. Comme l’a noté Devbridge, il est possible d’utiliser des attributs clés pour empêcher les authentifications parallèles lorsque plusieurs personnes interagissent simultanément avec le même compte utilisateur.
4. Stockez les jetons en toute sécurité. Le stockage local n’est pas la solution ici. La communauté de développement recommande l’utilisation d’une politique de cookies appelée SameSite pour spécifier les conditions dans lesquelles un cookie peut être transmis dans une demande inter-domaines. Une politique stricte de SameSite ainsi que l’exigence selon laquelle les utilisateurs doivent disposer d’une version de navigateur prenant en charge cette fonctionnalité aideront à sécuriser les jetons de session.