Project

General

Profile

Evolution #1039

[Security] Superadmin password

Added by Jean-Baptiste Nahan about 2 years ago. Updated almost 2 years ago.

Status:
In Progress
Priority:
Normal
Category:
Sécurité
Target version:
-
Start date:
07/31/2017
Due date:
% Done:

0%

Estimated time:
Vote:

Description

Bonjour,

Je viens de réaliser une installation du logiciel et je suis surpris du manque de conseil de sécurité lors de la création du compte admin.

En effet, imposer un nom d'utilisateur différent d'"admin" (et dérivé) et un mot de passe différent du login (voir également différent du top 50 des mots de passe les plus utilisé) me semble la base en plus d'une aide sur la page pour le choix du mot de passe.

Sur un tel logiciel, c'est difficile de demandé aux admin de gérer la sécurité. C'est donc au logiciel d'en proposer le minimum.

History

#1

Updated by Johan Cwiklinski about 2 years ago

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.

#2

Updated by Johan Cwiklinski about 2 years ago

  • Category set to Sécurité
#3

Updated by Jean-Baptiste Nahan about 2 years ago

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 !

#4

Updated by Johan Cwiklinski about 2 years ago

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 ?

#5

Updated by Jean-Baptiste Nahan about 2 years ago

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.

#6

Updated by Johan Cwiklinski about 2 years ago

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).

#7

Updated by Johan Cwiklinski about 2 years ago

  • Tracker changed from Anomalie to Evolution
  • Status changed from Nouveau to In Progress
  • Assignee set to Johan Cwiklinski
#8

Updated by Jean-Baptiste Nahan almost 2 years ago

Voilà une piste intéressante à suivre.

Also available in: Atom PDF