Dans cette partie, nous allons nous intéresser au renforcement de la sécurité des utilisateurs d’un site développé sous Drupal, plus particulièrement les sites gérant un grand nombre de comptes utilisateurs comme les forums, les blogs communautaires ou même certains sites de prestation en ligne.

La base : un certificat SSL

Selon le degré de sensibilité du site, mettre en place un certificat SSL et donc la possibilité de se connecter en https peut être essentiel. A ce stade, vous avez deux solutions : le faire vous-même ou vous tournez vers votre hébergeur. Si ces questions sont obscures, laissez la main à votre hébergeur qui s’en chargera. Pour autant, il n’est pas toujours pertinent de forcer la connexion en https. En effet, dans certaines entreprises ou administrations, il ne serait pas possible de se connecter sur les sites en https. Si vous forcez les connexions en https, vous perdrez du trafic. Sur ce point, tout dépend du but du site, de sa fonction et de son public.

Néanmoins, vous pouvez mélanger les deux, par exemple, laisser le choix de la connexion à l’utilisateur et forcer le https uniquement pour les connexions à l’espace d’authentification. Le module Secure Login permet ce type de configuration. Vous pouvez également utiliser Secure Pages qui vous permettra de déterminer un certain nombre de pages uniquement accessibles en https, ce qui peut être intéressant si le site est développé pour être à la fois un extranet et un site Internet.

L’authentification des utilisateurs 

Par défaut, Drupal fournit un formulaire d’inscription et de connexion relativement basique : login, mot de passe et une adresse email.

La plus grande faiblesse des sites actuels sont souvent les mots de passe des utilisateurs. En effet, lors d’une inscription – peu importe le site – un mot de passe temporaire fort, est attribué mais il doit être changé par l’utilisateur. Si le mot de passe temporaire est #18Pç7$=)98zMl@ mais que l’utilisateur le change pour mettre toto123, autant dire que ce n’est pas ce qu’il y a de mieux. Or, à partir du moment où vous mettez en place un site collectant des données personnelles – même à titre ludique et personnel – vous êtes soumis à certaines obligations sinon légales, au moins morales vis-à-vis de vos utilisateurs.

La question est simple : comment être sûr(e) que les utilisateurs ne mettent pas des mots de passe trop évidents sans pour autant passer son temps à fouiller ? On utilise Password Policy qui permet d’inclure certains paramètres dans la création des mots de passe et qui a largement fait ses preuves.

Une fois que l’on s’est assuré de la solidité des mots de passe, il reste un autre point sensible, que tous les administrateurs de forum connaissent très bien : les faux comptes utilisateurs destinés à spammer. Comment s’en débarrasser sans pour autant être obligé de valider – et donc de vérifier – tous les comptes un par un ? On peut recourir aux CAPTCHA mais la solution manque de finesse et les personnes présentant des déficiences ophtalmologiques risquent d’être découragées. On peut alors se tourner vers une solution plus amusante : Security Questions. Il s’agit d’un module qui vous permet d’ajouter des questions à un formulaire d’inscription et qui ne le valide que lorsque les personnes y ont correctement répondu. On peut également s’en servir pour s’assurer que la personne qui aurait perdu son mot de passe est bien celle qu’elle prétend être.

Enfin, on peut également utiliser Two Factor Authentification qui permet d’ajouter une couche supplémentaire d’authentification par SMS, similaire au système 3D Secure.

Quid des authentifications « déléguées* » ?

Ce que j’appelle les authentifications importées sont les possibilités de se connecter à un site en utilisant ses identifiants Google, OpenID, MSN, Twitter ou encore Facebook. Le terme utilisé n’est pas le plus correct.

Par défaut, Drupal permet à des personnes qui ont des identifiants OpenID de les utiliser pour s’identifier. D’autres modules intégrant Google, le défunt MSN ou encore Twitter ont vu le jour afin de faciliter les accès. Pour autant, à titre purement personnel, je n’y suis pas favorable. A mon sens, chaque site sur lequel on se connecte doit avoir son propre jeu de login/mot de passe. Pour des raisons de commodité, on utilise souvent le même login partout mais malheureusement, on utilise aussi très souvent le même mot de passe partout. Le problème étant que l’attaquant qui a accès à un compte Facebook – par exemple – peut aussi avoir accès à d’autres sites. Autant fermer la porte à ce type de scénarios et laisser la possibilité aux utilisateurs de prendre leurs responsabilités.

Drupal est un CMS assez complet mais comme tout système, il a besoin qu’on s’occupe de lui, qu’on le bichonne, qu’on le mette à jour et parfois, qu’on corrige certaines choses. Le prochain volet de cette thématique sera donc consacré à la pré-production et au debugging. 

* Initialement, j'avais utilisé le terme "importées" mais un internaute m'a suggéré que "déléguées" serait plus correct.