La notion de secret
Reprenons quelques bases. En matière d'authentification, un mot de passe c'est avant tout un secret ("ce que je sais"). Le concept d'un secret, qu'il faut le garder bien au chaud, sinon, ce n'est plus vraiment un secret. On évite par exemple de coller le Post-it avec son mot de passe sur son front pour se balader dans la rue ("ce que je suis" : dans ce cas, on parle au mieux d'identification et non d'authentification). Certains le font, ils appellent ça la "sécurité biométrique", ou "identification biométrique", mais globalement, c'est surtout du marketing et on sait que c'est au mieux un complément pour une authentification à double facteur (2FA), mais certainement pas la panacée comme secret "unique" pour confier des privilèges.
Dois-je partager un secret ?
Les gestionnaires de mots de passe actuels répondent cependant généralement à ces 4 besoins : Générer, centraliser, chiffrer... et partager. La notion de partage de mot de passe est "contre-nature", mais elle demeure un besoin des organisations. Cette pratique bien que dérangeante "by design" est donc une réalité. S'il faut impérativement le faire, autant le faire correctement. Et correctement, ça commence par partager uniquement ce qui doit l'être en offrant la surface d'attaque la plus réduite possible.
La tendance sécuritaire actuelle, c'est l'approche ZeroTrust. Pour forcer un peu le trait, on pourrait expliquer cette philosophie par "ne faites pas confiance aux gens, et encore moins à leurs devices". La logique est d'accorder les permissions les plus faibles possibles, toujours dans un but de réduction de la surface d'attaque.
Dans ces conditions, on ne peut être qu'un peu dubitutatif quand on découvre des gestionnaires de passwords en mode web, multipliant les connecteurs et les API, centralisant au milieu du web des secrets que l'on destine à être partagés. Ça peut vite donner des sueurs froides à n'importe quel RSSI.
Gérer un trousseau, ce n'est pas comme bidouiller sa page perso, il est possible de se rater, comme Kaspersky, et l'impact est tout de suite à considérer comme critique sur une organisation (ou des particuliers).
Les chiens aboient et les ours Syspass... leur tour
S'il faut bien reconnaître que l'interface de Syspass est très aboutie et le site de présentation très bien fait , qu'en est-il vraiment à l'usage ?
Niveau contexte, Syspass est le projet d'une personne, en mode "très stable" depuis 2 ans. Du LAMP très classique, avec toutes les possibilités d'inteprétation offertes par PHP, avec même une abstraction qui va gérer la sécurité, avec phpseclib qui va se débrouiller avec ce qui traine sur la machine (openssl, ou bien GMP, ou bien tout en PHP).
En déployant l'application, nous avons pu analyser son architecture et son fonctionnement et avons constaté :
- que l'architecture ne correspond pas à l'état de l'art ;
- que l'UX encourage des risques de mauvaise utilisation.
Limites de l'architecture
Pour ne pas avoir à configurer le serveur http et l'hôte, l'éditeur a confié trop de tâches à PHP, comme la gestion des assets compilés.
Le code s'avère très complexe à auditer, car il semble avoir été écrit pour un environnement spécifique, en utilisant des variables de contexte non standard.
Il n'est pas possible de configurer à froid le service :
- Le fichier de configuration est signé, ce qui empèche sa modification depuis l'éxterieur, c'est un état, complémentaire à la base de données
- La seule possibilité est de configurer depuis l'interface web, lors de la première connexion.
Cette combinaison est dangereuse.
L'organisation des dossiers est peu claire, pouvant rendre trop facile l'exposition de données critiques.
Limite et dangers UX
Doublon, complexité de suivi, des risques très importants :
- Notamment si l'équipe dispose d'autres outils comme Gitlab, il risque d'y avoir des données à saisir en doublon dans plusieurs outils
- Dans ce contexte, avoir une gestion d'utilisateurs et de projets, en dehors de sa gestion de code (Gitlab) demandera une énorme rigueur et la tentation de partager un compte, ou de faire des actions en root sera énorme.
Conclusions et recommandations
Notre conseil est de favoriser les comptes individuels, les accés temporaires, et globalement de ne pas exposer aux développeurs les mots de passe, qui doivent faire partie du provisioning, et du déploiement. On observe scrupuleusement la politique de la plus faible permission possible et une définition des rôles attribuant les privilèges strictement nécessaires.
Pour des paramétrages spécifiques à un projet, il est plus efficace d'utiliser un trousseau chiffré avec la clef GPG des utilisateurs, et de le versionner avec les sources du projet, ou d'utiliser les variables protégées de Gitlab.
Pour passer à un niveau supérieur de sécurité, il faut s'orienter vers des solutions comme Hashicorp Vault , avec son code audité, qui propose un workflow rigoureux, et une intégration propre à Gitlab. Il faut aussi surveiller vaultwarden, un élégant clone de Bitwarden codé avec le mythique Rust (plutôt que l'éxotique C# de l'original).
Sortez couvert.
