Nous utilisons fréquemment les réseaux sociaux tant pour un usage privé que professionnel. Afin de permettre un usage simple et le partage d’informations, des protocoles de sécurité ont été développé basés sur Oauth 2 et OpenID Connect. Cette simplicité d’utilisation et d’intégration a permis un essor rapide des réseaux sociaux . Nous déposons sur ces réseaux des informations privées dont la sécurité d’accès dépend des méthodes d’authentification et des jetons qui les représentent. La plupart des jetons générés sont des jetons qui sont sensibles à des attaques de type « man in the middle » (MIM) ou « credential replay » (rejeu de jetons).
Ces jetons sont générés au porteur et celui qui en a la possession peut en faire usage pour accéder à un service. Il s’agit littéralement d’une clé qu’il est possible de prêter et tout aussi bien se faire dérober par les moyens évoqués précédemment. Il n’y a pas de preuves que l’on puisse fournir qui permettent de déterminer que ce jeton appartient bien à l’utilisateur. De ce fait, si une personne malveillante peut obtenir un jeton valide lui appartenant, elle peut utiliser son identité pour accéder aux services comme les réseaux sociaux pour lesquelles le jeton est autorisé.
Face à ce problème de preuve de possession, plusieurs groupes de travail ont réfléchi pour proposer des solutions qui ont été référencées dans des spécifications, la plupart dans des RFC éditées par l’IETF.
Ping Identity a participé à l’une d’entre elle : le token binding. Cette spécification permet aux serveurs HTTP de lier de manière cryptographique les cookies et autres jetons de sécurité à une clé générée par le client (couple de clés publique et privée). Le protocole TLS a été étendu avec l’option « token binding » ce qui permet de l’intégrer dans les navigateurs.
Lorsque le « token binding » est négociée dans le dialogue TLS, le client envoie un message « token binding » codé dans une en-tête de chaque requête HTTP, ce qui prouve la possession d'un ou de plusieurs clés privées détenues par le client.
Afin d’associer la clé publique transmise à la connexion TLS, on utilise des données cryptographique de la liaison TLS appelé EKM [RFC 5705] dans un message signé. Un serveur HTTP émettant des cookies ou d'autres jetons de sécurité (jeton OAuth 2) peut les associer à l'ID de jeton, ce qui garantit que ces jetons ne peuvent pas être utilisés avec succès sur une connexion TLS différente ou par un client différent de celui auquel ils ont été émis.
Ainsi, l’extension de protocole « token binding » permet d’améliorer les mécanismes d’authentification et de session existants, tout en étant transparent pour les utilisateurs sans nécessiter la distribution de nouvelles clés ou certificats.
La réussite de ce protocole passe par une large adoption tant pour les navigateurs que pour les serveurs et frameworks web. À ce jour la plupart des navigateurs récents supportent « token binding » malgré le retrait de ce protocole de Chrome dont Google a été un des précurseurs. Dans le même temps, Mozilla a exprimé sa volonté d’introduire ce standard dans Firefox. Microsoft s’est engagée à le prendre en charge tant dans Edge que Internet Explorer. Par ailleurs, Apache et Nginx, OpenSSL ainsi que Java disposent d’extensions « Token Binding ». Enfin, il est intégré à .Net et IIS 8.
« Token Binding » apparaît comme une solution innovante, sans rupture et transparente pour l’utilisateur, qui permet d’atténuer les vols de jetons et les attaques par rejeu de session. Son adoption dépend de sa mise à disposition par les éditeurs et de son déploiement car à ce jour les spécifications ont été finalisées. Pour plus d’information, nous vous proposons de passer en revue la présentation vidéo de Brian Campbell sur Token Binding, Distinguished Engineer de Ping Identity donnée lors de la dernière édition de Identiverse.
