Galette

Je ne sais pas trop à vrai dire...

Oui, dans l'absolu, la cible principale du logiciel concerne des personnes qui ne sont pas sensibilisées aux problématiques de sécurité ; mais d'un autre côté, est-ce vraiment la problématique du logiciel ?

La plupart du temps, lorsqu'un logiciel impose des règles de sécurité, c'est très souvent mal implémenté et source de désagréments pour l'utilisateur... Quel intérêt d'interdire admin/admin pour une instance utilisée en interne uniquement ; par exemple ?

À la rigueur, afficher des conseils aux utilisateurs est envisageable, mais que ce ne soit pas une obligation me semble mieux.

Johan Cwiklinski a écrit :

Je ne sais pas trop à vrai dire...

Oui, dans l'absolu, la cible principale du logiciel concerne des personnes qui ne sont pas sensibilisées aux problématiques de sécurité ; mais d'un autre côté, est-ce vraiment la problématique du logiciel ?

Je suis conscient du but du logiciel. Cependant, l'actualité montre bien que personne n'est à l'abri. Que les excuses "je n'ai rien à cacher" ou "nous n'avons rien d'intéressant pour les pirates" sont complètement fausses.

C'est pour cela qu'en tant qu'éditeur de logiciel, il est important de concevoir le logiciel avec la sécurité. Si un administrateur n'est pas qualifié pour la sécurité, c'est au logiciel de le conseiller, le prévenir par des alertes "en rouge", etc...

Le logiciel de forum PhpBB est un bon exemple, beaucoup de personne l'utilise et beaucoup de petits forums peu sécurisés et peu connus ont été piraté (source de spam, fuite d'adresses courriels) ! Tout comme galette, PhpBB n'est pas orienté sur la problématique de la sécurité !

Avoir des outils qui vérifie le minimum requis en terme de mot de passe, sécurité de la connexion (https) est indispensable pour tout logiciel qu'il soit open source ou non, petit ou gros. Des pirates ne cherche qu'une base de données d'adresses courriels valide ou juste la gloire de pirater quelque chose !

La plupart du temps, lorsqu'un logiciel impose des règles de sécurité, c'est très souvent mal implémenté et source de désagréments pour l'utilisateur... Quel intérêt d'interdire admin/admin pour une instance utilisée en interne uniquement ; par exemple ?

Imposer des règle peux effectivement avoir un effet néfaste dans le temps. C'est pourquoi il est important de se renseigner sur les recommendations courantes. Par exemple, ne pas limiter le nombre de caractères maximum mais limiter le nombre minimum. Ajouter un indicateur de fiabilité du mot de passe est une bonne idée (mais il doit être maintenu).
Bloquer (ou a minima alerter et contre indiquer fortement) l'installation du logiciel sur une version non maintenue de PHP est également une bonne chose.
Personnellement, la seule contrainte sur le mot de passe que je trouve opportune est celle de la longueur minimum.
Exemple d'autre protection possible : un utilisateur tentant de se connecter verra toujours le même message en cas d'erreur d'identification. Egalement, en cas d'échec répété, le temps de réponse augmentera voir toute les tentatives échouerons pour la session en cours. Idem pour la récupération de mot de passe...

Pour ce qui est de l'implémentation, l'origine de l'implémentation est humaine et par conséquent faillible. Comme tout ce qui est fait par l'Homme. Mais est-ce une raison pour ne rien faire ? Pour cette partie, je peux vous proposer mon aide.
Effectivement, la sécurité d'aujourd'hui n'est pas celle de demain. Est-ce pour cela que vous ne fermez pas la porte de votre maison à clé ?

Un logiciel "interne" doit avoir la même sécurité qu'un logiciel publié sur Internet. Un poste compromis sur le réseau peux servir à compromettre le serveur. Personne ne peux dire si un jour le logiciel ne sera pas publié sur internet pour plus de facilité.

À la rigueur, afficher des conseils aux utilisateurs est envisageable, mais que ce ne soit pas une obligation me semble mieux.

Il est important de trouver un bons équilibre entre sur protection et rien du tout !

Je vous conseille de suivre ce cours (gratuit) sur la sécurité si vous le pouvez : https://secnumacademie.gouv.fr

Je reste disponible pour en discuter mais également pour vous aider !

Dans l'absolu ; Galette répond déjà à certaines problématiques.

Comme je le disais, ce que je ne veux pas, c'est avoir à implmenter des règles complexes pour rendre quelque chose obligatoire. Rien n'empêche bien entendu d'orienter et de conseiller l'utilisateur, dans la mesure du possible.

Concernant l'utilisation du même couple login/password, ça ne devrait pas poser trop de soucis. En revanche, les histoires de qualité de mot de passe ; je pense qu'il vaudrait mieux se baser sur une bibliothèque existante ; un conseil en ce domaine ?

Je n'ai pas trouver de bibliothèque récente et correcte rapidement. Cependant, voici deux exemples intéressants :

Celui ci (https://github.com/jbafford/PasswordStrengthBundle/blob/master/Validator/Constraints/PasswordStrengthValidator.php) reste simple en vérifiant que le mot de passe contient certain type de caractère. Il est possible de se baser dessus pour noter le mot de passe. Plus il est long plus la note monte mais également s'il contient différent type de caractère.

Cet exemple (https://snippetrepo.com/snippets/password-strength-analyzer-with-php) est bien plus poussé car il est possible de fournir des éléments (tels que le nom/prénom de l'utilisateur) a éliminer du mot de passe pour en augmenter la force.

Les deux exemples peuvent être combiner pour réaliser une évaluation opportune du mot de passe sans pour autant le rendre contraignant.

Pour autant, il serait effectivement mieux d'utiliser une librairie déjà écrite pour peu qu'elle soit maintenue.

La dernière mise à jour du premier exemple date de 3 ans... Il ne semble plus du tout maintenu :-/
Par contre, il a visiblement être remplacé par https://github.com/rollerworks/PasswordStrengthValidator qui semble maintenu et qui se base sur une bibliothèque séparée (https://github.com/rollerworks/PasswordStrengthValidator) que je pourrai utiliser :)

D'après la documentation, il serait possible de lui passer une blacklist spécifique (et donc, un peu ce qu'on veut, comme les informations fournies par l'utilisateur, une/plusieurs liste existante, la combinaison de tout cela, ...). Il semble donc se rapprocher en termes de fonctionnalités à ton second exemple.

Je pense que je testerai la bibliothèque ; à condition qu'elle ne dépende pas de la moitié du monde connu.

J'ai bien trouvé d'autres choses, mais soit ce n'est plus maintenu, soit il s'agit d'une vérification plus "simple". J'ai également trouvé des choses en javascript ; mais je préfère une implémentation en PHP.

Le site https://wiki.skullsecurity.org/Passwords propose un certain nombre de blacklists ; il pourrait être envisageable d'en intégrer une ou deux relativement légères (je pense à la liste des 500 par exemple) ; et pourquoi pas de permettre à l'utilisateur d'en ajouter d'autres de son choix (à déposer dans un dossier spécifique).

Voilà une piste intéressante à suivre.

Johan Cwiklinski a écrit :

Je pense que je testerai la bibliothèque ; à condition qu'elle ne dépende pas de la moitié du monde connu.

Et bien entendu... C'est un truc fait pour symfony - ce qui revient à peu près au même. L'utilisation en standalone (si toutefois elle est possible) n'est pas du tout documentée, on en arrive rapidement à plein de choses qui vont de travers simplement parce que que le tout n'est pas initialisé comme escompté. Et je vois bien les problèmes arriver avec de futures mises à jour de ce côté là.

Donc, je ne me baserai définitivement pas là dessus (et je n'ai toujours rien trouvé d'autre qui soit utilisable et maintenu), il va falloir tout faire "maison" - pour des problématiques de sécurité, ça part donc relativement mal.

Le site https://wiki.skullsecurity.org/Passwords propose un certain nombre de blacklists ; il pourrait être envisageable d'en intégrer une ou deux relativement légères (je pense à la liste des 500 par exemple) ; et pourquoi pas de permettre à l'utilisateur d'en ajouter d'autres de son choix (à déposer dans un dossier spécifique).

Cela reste je pense envisageable, le POC que j'ai pour le moment (https://github.com/galette/galette/tree/feature/password_checks) ne fait que vérifier la longueur et la "complexité" du mot de passe ; je ne me suis pas encore penché ni sur les blacklist, ni sur les informations de l'adhérent.

Finalement, j'ai eu un peu de temps, et j'ai pu "terminer".

J'ai ouvert une PR pour le moment : https://github.com/galette/galette/pull/49 ainsi que la doc correspondante : https://github.com/galette/documentation/pull/8