- SecurID
-
Un token SecurID.
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. Il fonctionne sur le principe du mode one-time password (OTP ou « mot de passe jetable ») 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 Pin 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 d'avec 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é
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.
Mars 2011, le système SecurID compromis
RSA a annoncé le 17 mars 2011 qu’elle a subi une cyber-attaque sophistiquée qui a permis aux attaquants d'extraire certaines informations relatives au système SecurID. 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.
Catégories :- Cryptologie
- Authentification
- Matériel de sécurité informatique
Wikimedia Foundation. 2010.
