Gestion des mots de passe… Nouveau genre!

Parfois nous avons des épiphanies en connectant deux choses ensemble.

En voulant configurer le iPad de ma blonde, je me suis souvenu qu’avec le support Exchange, il faut changer le mot de passe sur le iPad en même temps que dans la session Windows. C’est l’inconvénient de l’avantage du SSO de Windows.

Cela m’a fait réfléchir que la notion de changement de mot n’est utilisée que dans les entreprises. Il y a peu de service « cloud » qui impose ce type de changement sur une base régulière. Imaginez si Google exigeait que vous changiez votre mot de passe au 60 jours, comme c'est le cas dans certaines entreprises. Il y aurait un tollé et un abandon progressif du service offert par Google. Surprise, surprise, les gens n’aiment pas gérer des mots de passe.

Pour revenir au iPad de ma blonde, il serait possible de se soustraire au changement imposé si le iPad supportait l’authentification par certificat… De cette façon, c'est le périphérique qui supporte l’authentification et non la personne. À ce titre, il est essentiel d’exiger que l’utilisateur change son code d’accès sur son iDevice à intervalle régulier. J’ai déjà parlé de la mitigation du risque associé aux iDevices et je vais surement en reparler dans d’autres billets. Sachez que Windows Mobile permet l’authentification par certificat et que BlackBerry repose aussi sur cette façon de faire pour épargner ses utilisateurs du changement de mot de passe associé au changement de mot de passe Windows… Mais doivent changer leur mot de passe de BlackBerry à un intervalle équivalant. L’effet est somme toute nul.

Il est peut-être bon de revenir à la raison pour laquelle on change le mot de passe. C’est pour assurer que si le mot de passe est découvert par hasard ou par force brute, que sa durée de vie soit limitée à la valeur de l’information qui est protégée.

Il y a pourtant une panoplie d’autre façon d’arriver à la même chose sans égratigner les utilisateurs. À titre d’exemple, on pourrait exiger une rotation des mots de passe au 120 jours ou 365 jours. Par contre, à chaque tentative infructueuse d’authentification, le temps restant est réduit de 30 jours. Un utilisateur normal va se tromper une ou deux fois de temps en temps. Donc sur le scénario de 120 jours, si je me trompe deux fois, le temps sera coupé de 60 jours. Un attaquant aura une fenêtre très mince pour trouver le bon mot de passe, autant l’utilisateur devra changer son mot de passe plus rapidement afin de contrer une tentative d’attaque, réussi ou non.

Dans les systèmes d’entreprises, il est facile d’accéder aux événements de sécurité et déceler des tentatives d’attaque sur un compte. Malgré que ce ne soit pas fait régulièrement, l’inspection des journaux d’événements pourrait réduire grandement la capacité à un utilisateur hostile de casser la sécurité du réseau. Dans les systèmes cloud, comme nous n’avons pas accès à cette information, il faudrait que les opérateurs mettent en place des moyens pour réduire la probabilité qu’une personne ne force la sécurité d’un compte, tout en offrant la possibilité aux utilisateurs d’être avertie lorsqu’il y a des tentatives infructueuses.

Le bénéfice d’avertir les utilisateurs, c'est que les attaques vont cesser d’être obscurcies par les opérateurs clouds et les utilisateurs auront un moyen efficace de savoir quand il est temps de changer leur mot de passe. C’est une forme de sensibilisation, s’il n’y a pas d’excès.

Le revers à ça et parce que je ne suis pas au courant de ce qui se passe dans les opérateurs clouds, il se pourrait que le volume d’information soit astronomique et inonde l’utilisateur et le désensibilise à la protection de son compte.

Avec l’augmentation de l’utilisation de ces services, il est fortement conseillé de mettre entre les mains des utilisateurs certains outils pour faciliter cette gestion. Il serait encore mieux s’il était possible d’avoir une source d’authentification unique pour un grand porte-feuille de service.