Forum Programmation.web de la place des mots de passe dans un site web

Posté par  . Licence CC By‑SA.
Étiquettes :
1
31
mar.
2021

Bonjour à tous
pour mon asso, je reprend la gestion du site web car la personne qui gérait ca est partie.

évidemment il n'a pas laissé tous les mots de passe en partant, et j'ai du fouillé un peu.

J'ai trouvé des mots de passe dans le code du site (genre config.php ou settings.php)
mais pour un sous site, j'ai trouvé ca en variable d'environnement apache.

Je me suis dit que c'était pas mal le coup des variables d'environnement car ca rend la mise à jour du code du site indépendant de la plateforme (test/prod)

mais n'est ce pas risqué d'exposer par les variables d'environnement ?

le htpasswd sont par exemple en dehors de l'arborescence web, et stocke les mots de passe en md5 et pas en clair
mais quid des logins/pass pour la base de données par exemple.

quelles seraient les bonnes pratiques pour cela ?
un volume chiffré ? mais il faut le déchiffrer au démarrage de la machine, et apres c'est visible en clair sur la machine…

  • # plusieurs solutions

    Posté par  . Évalué à 2.

    Salut.
    J'ai l'impression que tu souhaites faire plusieurs choses, a toi de voir ce que tu veux mettre en priorité :

    • rendre le code indépendant de la plateforme : les var d'env sont une bonne solution, mais elles peuvent être exposées assez facilement en PHP (il suffit d'un phpinfo() qui traine quelque-part pour les voir). Ou alors il faut stocker ces credentials dans les variables d'env de manière chiffrée, et avoir la clé de déchiffrement dans un fichier de conf (qui sera peut etre identique entre la prod et la pltf de test, sinon tu tournera en rond)
    • ne pas exposer les credentials à tout vent : le volume chiffré, ou tout autre solution de gestion de secret peut etre intéressante, mais il faut etre certain que ta machine ne soit pas compromise (on peut supposer que si qqn arrive a avoir un acces root a la machine, il peut voir tout les secrets)

    Cela dépend aussi d’éventuelles fonctions de sécurité que peut proposer ton hébergeur. Par exemple, un serveur de base de données ne va autoriser les connexions qu'en provenance d'une machine bien précise, sans credential particulier.

    Pour des grosses archi, il faut aussi prévoir la mise à jour des secret et leur prise en compte, sans interruption de service, avec controle et audit de qui y a acces etc…

  • # ou les deux

    Posté par  . Évalué à 3.

    Tu peux aussi avoir un fichier de config par environnement, qui contient les paramètres pour cet env. Le nom du fichier chargé par l'appli est passé via une variable d'env.

    Par exemple:

    config-prod.php:
$dburl="posgresql://kikoo:rigolo2000@dbprod.internal.perdu.com:5432:wonderwurst"
$uploaddir="/srv/www/prod/uploads"
#
# ou bien :
#
$dbdriver="postgresql"
$dbuser="kikoo"
$dbpass="rigolo2000"
$dbserver="dbprod.internal.perdu.com"
$dbport="5432"
$dbname="wonderwurst"
$uploaddir="/srv/www/prod/uploads"

    et dans ton env:

    APP_CONFIG_FILE=/un/repertoire/en/dehors/de/l/arbo/du/site/config/config-prod.php

    Dans le monde merveilleux de Docker c'est très courant d'utiliser des variables d'env pour configurer les services.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.