Hack.lu 2011 - OAuth and OpenID - Securing the Insecure
OAuth and OpenID – Securing the Insecure
par Khash Kiani
Les intentions d’OpenID sont louables. Le problème ne vient pas souvent du protocole mais de l’implémentation
L’auteur nous fait un récapitulatif de tout ce qui constitue l’Identité numérique d’un individu. Oauth est un paradigme centré sur l’utilisateur, c’est l’utilisateur qui contrôle les autorisations, et qui décide de déléguer des droits d’accès d’une application vers l’autre sous forme de tokens, ce qui évite de donner ses accès au site tiers. L’auteur nous fait un rappel sur le fonctionnement de OAuth.
L’auteur nous montre ensuite quelques attaques à partir d’applications malicieuses exploitant OAuth. Par exemple, une application malicieuse peut usurper l’image d’une authentification OAuth, et voler les identifiants d’un utilisateur en lui donnant un faux sentiment de sécurité. A l’aide d’une application facebook, on peut ainsi collecter des informations sur l’utilisateur et obtenir un accès sur d’autre services (ex: messagerie).
Il est aussi possible d’exploiter une mauvaise implémentation du protocole, ou de mauvais usages, par exemple un utilisateur se connectant a twitter via twitterfeed, se retrouve avec une session sans timeout, avec potentiellement des vulnérabilités, etc… et la session peut donc se retrouver volée (via un xss par exemple) et exploitée à des fins malveillantes. Pour éviter tout ces problèmes, il faut invalider la précédente session, avoir des tokens avec un token de courte durée, supprimer l’ancienne session si une nouvelle est crée, etc…
Autre exemple, en cas de changement de mot de passe, le token d’accès a twitter n’est pas révoqué pour les applications tierces, et aucun renouvellement n’est forcé 🙁 Cependant, OAuth apporte la possiblité de se détacher du paradigme du mot de passe, et évite d’avoir a les gérer sur N application. En prime, si les tokens sont révoqués de façon régulière et efficace, on évite d’avoir des applications qui s’accrochent à leur privilèges.
OpenID à pour but de simplifier l’utilisation des sites en permettant une unité de l’identité numérique d’un individu. Ici le modèle de confiance est asymétrique, un fournisseur d’identité à qui on fait confiance et qui atteste de votre identité auprès de X tiers chez qui vous voulez vous identifier.
Coté attaques, le problème fondamental, c’est que tout dépend d’un simple couple d’identifiants, mais la sécurité de ce couple d’identifiants dépend du fournisseur d’identité (yahoo par exemple). L’idée est d’exploiter des défauts dans le processus de re-initialisation du mot de passe, et de s’en servir pour usurper l’identité de la victime. 40 min plus tard, la victime à pu s’en rendre compte, et changer ses questions secrètes. Cependant, dans la procédure de recouvrement de mot de passe, il est possible de revenir à l’ancienne question secrète (FAIL!).
Coté phishing, il est plus intéressant de faire du phishing sur le process d’OpenID, car les gens ne font pas vraiment attention à l’url du fournisseur d’Identité. ainsi la personne croyant s’authentifier auprès du fournisseur d’identité, donne en fait ses identifiants à un pirate.
Coté contremesures, l’utilisation d’un secret visuel permettant d’identifier le provider est une possiblité. Sinon, les applications de type One Type Password, quoique couteux en temps utilisateur, restent relativement efficaces.
