SecurID
Pour les articles homonymes, voir SID.
SecurID est un système de token, ou authentifieur, produit par la société RSA Security et destiné à proposer une authentification forte à son utilisateur dans le cadre de l'accès à un système d'information.
Présentation
[modifier | modifier le code]Il fonctionne sur le principe du mode one-time password (OTP ou mot de passe à usage unique) sur la base d'un secret partagé (seed). La majorité des tokens SecurID affichent un code à 6 chiffres (le « TokenCode ») changeant généralement toutes les minutes. L'utilisateur ajoute un Code PIN personnel au TokenCode lu sur l'authentifieur SecurID. Le tout est appelé un PassCode (soit PassCode = PIN Code TokenCode). Lors d'une authentification, le serveur d'authentification forte calcule le TokenCode à partir de son horloge (temps UTC) et ajoute le PIN Code de sa base de données puis compare avec celui fourni par l'utilisateur. Si le PassCode correspond, l'authentification est réussie. Il arrive que l'horloge du SecurID se désynchronise par rapport à celle du serveur d'authentification. Par ailleurs, le Token expire au bout d'un certain temps (3 à 5 ans selon les modèles).
Ce système de Token, de type OTP, est utilisé pour les applications Web (par exemple le eBanking) et les technologies de type VPN (IPSEC, SSL), SSH, Citrix. En France, l'Éducation Nationale a généralisé son usage dans la population enseignante, notamment dans le cadre de Sconet (saisie des notes notamment).
Sécurité
[modifier | modifier le code]L'utilisation d'un OTP protège la solution RSA SecurID contre les attaques par rejeu : un attaquant qui aurait réussi à récupérer un OTP (par exemple à l'aide d'un keylogger) n'est pas en mesure de s'authentifier.
Par ailleurs, plusieurs attaques affectant le RSA SecurID peuvent être envisagées :
- Exploitation de l'absence d'authentification du serveur
La solution RSA SecurID n'implémente aucun mécanisme d'authentification du serveur. Un attaquant peut alors imaginer un scénario dans lequel l'utilisateur entre son OTP dans une page créée par l'attaquant, mais dont l'aspect ressemble à celui du site original. L'attaquant est ainsi en mesure de récupérer un jeton non consommé, ce qui lui permet de s'authentifier sur le site original.
Pour pallier un tel scénario, il est nécessaire de réaliser une authentification du serveur. Ceci peut se faire à l'aide du protocole SSL, qui utilise un certificat numérique. Ce fichier doit être signé par une Autorité de Certification (AC) de confiance, qui garantira à l'utilisateur l'identité du serveur.
- Attaque s'appuyant sur une vulnérabilité de type Cross-site scripting (XSS)
Une attaque plus évoluée que la précédente consisterait à exploiter une vulnérabilité de type Cross-site scripting. Une possibilité serait d'injecter un formulaire qui s'afficherait sur le navigateur de l'utilisateur. Ceci présente l'avantage que le code s'exécute sur le poste de l'utilisateur, qui est connecté sur le serveur considéré comme étant de confiance.
Vulnérabilités
[modifier | modifier le code]RSA a annoncé le qu’elle a subi une cyber-attaque sophistiquée qui a permis aux attaquants d'extraire certaines informations relatives au système SecurID[1]. Selon RSA, les informations extraites pourraient, potentiellement, être utilisées dans le cadre d'une attaque plus globale permettant de réduire l'efficacité du système SecurID. Toutefois, RSA a précisé qu’il n’est pas possible d’accomplir avec succès une attaque directe sur l’un de leurs clients utilisant ce système.
Galerie
[modifier | modifier le code]-
modèle SID600 d'avant 2008 -
modèle SID800 avec USB
Voir aussi
[modifier | modifier le code]Notes et références
[modifier | modifier le code]- Références
- L'authentification forte des tokens SecurID est-elle compromise ?, Le Monde Informatique, 22 mars 2011
