Table des matières
Password_policy
Moins simple qu'il n'y paraît
Ce module permet d'implémenter une politique de sécurité. Les fonctionnalités de bases ainsi que les limites sont bien expliquées, tant dans la page du module que dans la documentation qui n'est autre que le fichier README.txt situé à la racine du répertoire du module.
L'utilisation paraît limpide mais on, déchante lorsqu'on veut configurer le module. On se heurte à des formulations d'une invraisemblable opacité1). Voici donc, l'explication des points les plus obscurs.
Principe général d'expiration des mots de passe
On peut définir plusieurs politiques de mots de passe, chacune ayant une durée d'expiration différente. La question posée est : que se passe-t-il si je modifie une politique de sécurité ? Le module propose deux options :
- La durée de validité des mots de passe des utilisatrices concernées n'est pas modifiée. Elles ne devront appliquer la nouvelle politique que lorsque leur mot de passe arrivera naturellement à expiration.
- Les utilisatrices concernées voient leur mot de passe expirer immédiatement. Elles devront donc changer leur mot de passe lors de leur prochaine connexion2). Ce faisant, elles devront se conformer à la nouvelle version de la politique de sécurité.
En gros, la première option dit : la politique de sécurité s'appliquera lorsqu'elle doit s'appliquer, au regard de l'ancienneté des mots de passe existants. Le seconde option dit : la politique de sécurité s'appliquera dès qu'une utilisatrice concernée tente de se connecter.
On regrettera qu'en cas de choix de la deuxième option, un courriel ne soit pas envoyé aux utilisatrices concernées.
Caractères obligatoires
Pour une politique donnée, il est possible de définir quels type de caractères devront être utilisés et combien de caractères de chaque type. Jusque là, tout va bien.
Le problème vient ce que le module distingue : les lettres, les chiffres, les caractères alphanumériques et les signes de ponctuation, les lettres minuscules et les lettres capitales. Déjà, ce n'est pas très distinctif. Par exemple “a” est à la fois une lettre, un caractère alphanumérique et une lettre minuscule. Comment la décrire ?
En pratique, cela permet de faire des configurations très fines mais quelques exemples n'auraient pas été superflus. On peut ainsi signifier qu'un mot de passe doit comporter au moins 3 lettres, au moins 1 minuscule et au moins 1 capitale. Dans ce cas, l'utilisatrice aura le choix d'utiliser au moins 2 minuscules et 1 majuscule ou au moins 2 majuscules et 1 minuscule.
Une dernière option vient encore compliquer la compréhension : le nombre de types de caractères. On peut imposer que le mot de passe comprenne au moins 1, 2 3 ou 4 des types de caractères suivants : minuscules, majuscules, chiffre, ponctuation. Jusque là, tout va bien. Mais quelles sont les règles de préseance si je n'exige que 2 types et que j'indique, par ailleurs, que le mot de passe doit contenir au minimum une majuscule, au minimum une majuscule et au minimum 2 chiffres ? La documentation est totalement muette sur ce point. Il ne vous reste la rétro-spécification par essai-erreur
Quelques pièges et oublis
Texte des courriels d'annonce d'expiration
Le texte du message d'annonce est en anglais mais il n'est pas pris en charge par le module d' internationalisation. Il faut donc modifier le texte dans la de configuration elle-même3).
Activation de la politique de sécurité
Une politique n'est active que si on a pensé à cocher la case ad hoc !
Tests de rendu des messages
Ne serait-ce que pour s'assurer que les jetons (tokens) sont correctement interprétés, on fera des tests d'envoi de messages. Evitez les messageries comme Gmail4) qui ont le chic pour classer ce type de message dans un classeur improbable. Cela vous évitera de perdre du temps en vous demandant - à tort - pourquoi le mail n'a pas été envoyé…