Sous ce titre putaclick se cache une question fort simple : comment stocker des mots de passe pour pouvoir y accéder plus tard ?
 
Je me suis lancé dans un projet : développer un outil pour gérer notre documentation à mon travail. Je fais ça quand j'ai rien d'autres à faire, parce que la programmation me passionne et parce que notre outil actuel est un wiki avec les mots de passe root des serveurs en clair      
Donc même si ça ne rentrera probablement jamais en prod, vu l'inertie dans cette petite COGIP, on va faire comme si, et au moins j'aurai monté en compétence sur le dev
 
Donc vous aurez compris, la question concerne les mots de passe des serveurs, pas ceux des utilisateurs qui auront à se connecter à l'outil (pour ça j'utilise la fonction php password_hash, à laquelle je vais ajouter un salt, d'après les quelques docs que j'ai lu ce soir).  
 
Notez que je me demande si il y a moyen d'interfacer un gestionnaire de mots de passe reconnu comme KeePass pour éviter de stocker les mots de passe dans ma base de données. Edit : à priori oui, mais en lecture seule...
 
Merci

T'emmerde pas, si vos règles de sécurité internes ne l'interdisent pas (apparemment y a pas trop de contraintes à ce sujet chez vous ) stocke les effectivement en base, sous forme cryptée, mais réversible contrairement à un hash.

Tu cryptes ça en AES (par exemple, ou n'importe quel algo symétrique ou asymétrique que tu voudrais) avec une clé et un algo qui sont dans le code.
Tu peux aussi compliquer un peu plus en déportant une partie des données d'encryption dans les fichiers de conf de la production.
Comme ça le code pourra encoder et décoder les mdp, et la base seule ne sert à rien à un pirate vu qu'elle contient juste les mdp cryptés.
Par contre un attaquant motivé qui arrive à vous piquer votre code ET votre base ET votre conf de prod finira par y avoir accès (forcément).

Sinon il faut que ça soit géré niveau machine (LDAP et cie) pour ne plus avoir de credentials du tout dans l'appli elle même.

Si t'as un wiki, tu stockes dedans un fichier .zip un fichier texte qui contient les mdp et tu chiffres en AES le .zip avc un mdp. Ce mdp, tu le donnes qu'aux personnes devant avoir accès aux mdp des serveurs. Pas besoin de faire du dév

 
Merci, ça répond bien à ma question. Je vais donc stocker les mots de passe encryptés avec openssl_encrypt. Par contre c’est la clef pour laquelle je m’interroge. Selon toi je devrais la stocker dans un fichier sur le serveur ? J’imagine qu’il faut une clef par mot de passe, générée automatiquement ? Sinon comme tu disais, plus simplement en mettant la clef directement dans mon php.  
 

 
Non... Je code pour l’exercice. Parce que ça m’intéresse.  
 
De plus, ta solution ne me parait pas optimale pour travailler en équipe. Dès que quelqu’un modifie un mot de passe il faut uploader le fichier et tout le monde doit downloader la nouvelle version... Et puis si c’est pour stocker uniquement des mots de passe, il y a des outils pour ça comme KeePass. On a essayé de stocker les infos dans un fichier type Excel, c’était l’enfer
 
Le problème c’est que je ne veux pas que stocker des mots de passe. Je veux que l’outil que je développe fasse plus que ça. Par exemple pour chaque server je veux indiquer si c’est virtuel ou physique, les specs, l’emplacement si physique (dc, salle, rack...), l’hyperviseur si virtuel, le client, le backup, le monitoring, les rôles, les accès, l’année de mise en service, IP privée/publique, etc etc. Le tout le plus dynamique / automatique possible évidement. Ha et bien sûr il faut que tout soit relié. Dans une fiche client je veux voir apparaître tous les équipements du client, dans la fiche d’un serveur de backup je veux voir les serveurs qu’il prend en backup, etc.  
 

Encore une fois ça dépend du niveau de sécurité que tu vises. Mon post précédent te donne les pistes.
Une clé commune pour toutes les encryptions, directement dans le code ou dans la conf offre déjà un bon niveau de sécurité. Pas forcément sous forme de fichier (c'est une simple chaîne).
Si c'est dans le code, gros inconvénient : n'importe qui (stagiaire, développeur...) qui a accès au code source, et à la base de production (y compris via un backup) peut théoriquement décrypter tous les mots de passe.
Si c'est dans la conf, tu déploies une clé de cryptage en prod différente de celle de dév, donc seuls ceux qui ont accès au serveur pourront la connaître.

Une solution plus poussée pourrait faire appel à des certificats, de l'asymétrique... Mais vu le contexte que tu présentes je ne pense pas que ça soit à la fois intéressant ni même possible en terme de temps et de moyens à consacrer.

Ok... effectivement vu le contexte, une clef stockée dans le code fera l'affaire. Actuellement dans le wiki c'est tout en clair
Et dans une version précédente ébauchée avec Django, les mots de passe étaient donc en clair dans la bdd, ça ne dérangeait pas mon boss à qui j'avais montré ça...

A vous de voir, mais

- Il ne faut pas faire une confiance aveugle aux gens. Même si t'as l'impression d'être dans une bonne équipe loyale, un pétage de câble ça peut arriver, et tu ne sais pas non plus qui pourrait vous rejoindre par la suite.

- En cas de gros souci, la responsabilité du type qui a introduit la vulnérabilité peut être engagée. Genre celui qui a dit "et si on mettait tous les mots de passe en base avec juste un cryptage léger assuré par le code". Parce que les managers et les décideurs sont des connards qui n'en ont plus rien à foutre de toi dès qu'ils ont besoin de se couvrir. Évidemment cet argument marche encore mieux si les mdp sont carrément en clair.

Perso si je devais prendre une décision sur un truc aussi sensible, je ferai un mail à un "coupable hiérarchique potentiel" pour lui décrire ce qui va être fait et les éventuels risques. Je ne sais pas à quel niveau de hiérarchie tu interviens mais il faut que tu puisses dire "je n'ai pas pris la décision finale, et la situation a bien été analysée et soumise à la personne compétente".

Faut trouver le juste milieu entre négligence et paranoïa

Je n'ai fait que survoler mais +1 pour TR.  
Honnêtement quand j'ai vu le titre j'ai eu peur.

Pour les fonction supplémentaires, GLPI ne fait pas déjà tout ça ? Dans ce cas, t'aurais qu'à développer un petit plugin pour gérer le chiffrement du mdp pour chaque fiche associée à une machine.

 
Bon, je vais en parler à un responsable pour savoir ce qu'on fait à propos des mots de passe. Genre je vais parler un peu de la situation actuelle (le wiki) et de ce que ma solution pourrait apporter. C'est sûr que c'est une question délicate le stockage des mots de passe. Idéalement j'aimerais interfacer mon application php avec une solution dédiée pour les mots de passe. Ceci dit, ce genre de solutions généralement fonctionne avec un mot de passe maitre, et s'il faut écrire le mot de passe maitre dans model.php pour accéder aux mots de passe, a-t-on vraiment avancé ?
 

C'est fait exprès

 
Oui bien sûr GLPI fait déjà ce genre de choses. D'ailleurs quelques semaines après être entré dans cette petite compagnie, j'ai proposé à mon boss de migrer nos infos dans GLPI que je connaissais. Mais le produit ne l'intéressait pas. Il préférait que l'on développe notre propre outil qui ferait aussi les tickets par exemple. Donc à ce moment là je suis partit sur le dev d'une application avec Django. Malheureusement je me suis vite heurté aux limitations de Django, mais j'ai quand même réussi à pousser une v1 viable (avec les mots de passe des serveurs en clair dans la bdd, choix validé par mon boss). Sauf que ça n'a jamais été mis en prod, parce que pas le temps, l'envie et pas confiance en Django de la part de la direction (alors que c'est lui qui m'a dit de coder avec ça...).  
 
BREF, ce projet là est mort dans l'oeuf et ne passera jamais en prod, pour d'autres raisons : limitations de Django, difficulté d'interfacer avec nos autres outils (backup, monitoring, tickets, etc), et surtout parce que je l'avais fait bien trop compliqué à utiliser. Trop d'options pour chaque serveur, trop de champs à remplir, pas assez d'automatisme.  
 
Et cette année je me suis inscrit à un cours du soir en dev web, pour mettre un peu d'ordre dans les connaissances en dev que j'ai acquis sur le terrain. Comme j'ai du temps parfois à la job, que j'aime le dev, et pour l'exercice, je me suis lancé dans une v2, from scratch. Plus simple, plus automatisée, liée avec nos outils et surtout plus facile à modifier dans le futur. Pas sûr du tout que ça passera en prod par contre, mais finalement, je m'en fous un peu. Chaque question que je me pose en développant ça c'est de l'apprentissage.
 
Bon j'ai été un peu hors sujet là mais pas grave

Encore en cas d'école du projet de dév d'outil interne mal spécif et mal branlé du début à la fin. C'est dommage

 
Encore un cas d'école d'un commentaire non constructif. C'est dommage.

Connaissant les interventions de rufo je ne ne pense pas que ça soit le but.

Là où toi tu arrives, plein de bonne volonté certes, mais avec une réflexion qui semble surtout personnelle et spontanée, un projet de ce genre pourrait plutôt faire l'objet d'une démarche d'entreprise encadré avec une analyse et des specs suffisantes en amont. D'où mes avertissements plus haut sur les risques et impacts.
A mon avis (si je peux me permettre de parler pour lui) ça doit être ça qui interpelle rufo, il ne cherchait pas à te vexer mais plutôt aller dans mon sens par rapport au côté sensible d'une partie des données stockées et au fait que ça sera utilisé par tous, donc que ça n'est pas un petit projet anodin.

Effectivement, je ne cherchais pas à te vexer, mon propos n'était pas dirigé envers toi mais envers ton entreprise. Dans ce genre de cas de figure, il m'arrive régulièrement de faire référence à cet article et les stats qu'il présente : https://fr.wikipedia.org/wiki/Proje [...] erformance
 
Du coup, alors que ça doit bien faire 15-20 ans facile qu'on a identifié les clés de l'échec d'un projet (pas forcément informatique, un logiciel dans ton cas de figure), il est navrant de constater à quel point les donneurs d'ordre/dirigeants sont encore si peu mature sur ce sujet et répètent inlassablement les mêmes erreurs, bien souvent "pour gagner du temps" ou "pour économiser de l'argent". Je ne rentre même pas dans le "détail" du stockage des mdp et des aspects techniques ou légaux que soulevaient (à juste titre) TotalRecall. Les 2-3 posts où tu expliques le déroulement du projet sont éloquents. De ce que j'ai compris :
- spec faite dans ton coin (ou avec peu de concertation de toutes les parties prenantes) parce qu'il fallait bien que quelqu'un s'y colle vu que les problèmes existaient depuis un bon moment
- bonne idée de partir sur GLPI quitte à le faire un peu évoluer refusée et choix de partir sur un dév en interne avec une techno non maîtrisée et/ou pas adaptée au besoin
- qui plus est, le dév ne semble pas être ton métier, mais une passion. J'ai cru comprendre que tu n'avais pas fait de formation en dév.
- tout au long du processus de dév, pas ou peu d'implication de la hiérarchie et de la prod.
- pas de conduite du changement mise en place tout au long du projet de la par de la hiérarchie.
 
Bref, on a tous les éléments dès le départ pour aller dans le mur. Car au final :
- on a un produit trop complexe du fait que les utilisateur finaux n'ont pu évaluer un prototype d'IHM ou n'ont pas eu assez leur mot à dire sur l'ergonomie. Tu as beau bien connaître le besoin et le contexte, c'est une toute autre histoire d'arriver à trouver la meilleure solution et de la faire accepter aux utilisateurs.
- le produit ne fait pas gagner suffisamment de temps aux utilisateurs parce qu'il ne s'interface pas suffisamment bien avec l'écosystème en prod. Le fait qu'il soit en plus complexe fait finalement plus perdre du temps qu'en gagner, d'où une possible frustration des utilisateurs et un rejet.
- le produit n'est pas maintenable dans le temps. Tu n'en parles pas, mais j'imgine que côté documentation, ça devait être assez léger (spéc détaillée, dossier de conception détaillée, MCD  et MLD de la BD, manuel d'exploitation, manuel utilisateur, dossier de tests...). Or, la qualité de la doc est une part importante de la maintenabilité d'une appli dans le temps.
 
Un point important que je rappelais à mon stagiaire que j'ai eu il y a peu : on ne code pas en contexte pro comme on code pour un projet personnel. Pour soit, on va tester pleins de framesworks, des méthodes... En contexte pro, on essaye d'être le moins dépendant possible de trop de librairies ou frameworks, en particuliers s'ils sont trop récents et plutôt prendre des trucs qui ont fait leurs preuves et très connus. Ca en facilite la maintenance et il est plus facile de monter en compétence sur l'appli pour les nouveaux dévs si elle repose sur une architecture et des librairies/frameworks connus.
 
Donc, ce n'est pas de ta faute l'échec de ce projet mais des responsables qui ont pris de mauvaises décisions et ont laissé faire...
 
Je te recommande de regarder du côté des méthodes agiles (ex : scrum et dév piloté par les tests). Regarder du côté de devops ne serait pas inutile non plus . Voilà pour un commentaire constructif

Merci pour le long message  
 
Effectivement tu as bien résumé ce qui s'est passé. Ceci dit, je vais donner un peu de contexte. La compagnie dans laquelle je travaille est toute petite. Nous sommes une compagnie de services TI. Quatre techniciens, un vendeur/chef de projet (arrivé après la version Django de mon app), une adjointe de direction/secrétaire/comptable et un directeur-président. C'est tout. Je pense que rien que cette information peut expliquer pas mal de choses.
 
Ensuite, même si on est une petite compagnie, on arrive quand même à être ultra désorganisés sur plein de choses. Aucune nomenclature, aucune procédure, pas d'outil de gestion de projet, calendrier mal branlés et peu ou pas utilisés, outils de ticketing qui ne gère pas le temps passé (on doit remplir des feuilles de temps tous les jours). Et surtout, un wiki pas à jour et monolithique pour la documentation technique. J'ajouterai peu de discipline, aussi. Ayant travaillé dans une compagnie de 500 techs par le passé, et forcément mieux organisée, j'ai essayé de proposer des améliorations pour nous simplifier la vie. D'où mon app, entre autres.  
 
Enfin, le dev me passionne, je n'ai pas fait de formation. En fait je me suis inscrit à un cours du soir en dev web cette année. C'est très basique pour l'instant (html...), mais j'espère que ça m'aidera à structurer un peu mes connaissances. J'attend surtout le cours sur les BDD et PHP, vers la fin du programme (au printemps). Je vais surement me trouver un travail de développeur une fois le cours terminé.  
 
L'outil que j'essaye de développer est quelque chose de simple. Des pages clients, des pages serveurs, etc. Pour l'instant c'est tout. Et honnêtement j'ai du mal à voir comment je pourrais faire pire que le wiki qu'on a actuellement...    

Sur le papier, faire une appli de gestion, ça paraît toujours relativement simple. Mais rien que recueillir le besoin d'un client ou d'utilisateurs, c'est déjà toute une histoire et tout un art. Ca fait 15 ans que je fais (entre autre) ça : faire accoucher du réel besoin du client, c'est chaud car il ne sait pas forcément lui-même ce qu'il veut.
 
Après, une fois qu'on a compris ce que le client veut, il faut tout spécifier : comme je le dis souvent, le diable se cache dans les détails. Le coup du client qui vient te voir vers la fin du projet en disant "ah oui, au fait, je t'ai pas dit, mais il faut que le soft puisse faire ça aussi. C'est pas un problème ?" Des fois c'est pas rien, parfois, ça peut remettre en cause toute ou partie du logiciel, dans les grandes largeurs
 
Puis, il faut modéliser la BD. Là, on va voir de suite la différence entre un autodidacte ou quelqu'un dont c'est pas le métier et un ingénieur en dév. La BD, c'est les l'équivalent des fondations d'une maison pour une appli de gestion. Si tes fondations ne sont pas solides, ton appli finira par se casser la tronche (plus ou moins rapidement). J'en ai un bel exemple à mon travail : 4-5 ans pour faire l'appli, BD toute moisie, 2.5 ans après la mise en prod, on parlait déjà de la remplacer à cause des nombreux bugs et de la BD mal conçue. Si la notion de forme 3NF de Codd ne te dit rien, va regarder ici : https://fr.wikipedia.org/wiki/Forme [...] me_normale
C'est aussi un article que je cite régulièrement. Il montre bien que modéliser une BD, c'est pas juste transposer des tableaux Excel dans des tables de BD. Aujourd'hui, le modèle relationnel (SGBDR) est pas mal remis en cause avec le Big Data et le NoSQL du fait de l'incapacité des SGBDR à traiter des volumes gigantesques (mais bon, c'est un autre sujet).
 
Une fois la BD bien modélisée, y'a toute l'appli à écrire : faire l'architecture, faire du code propre et bien commenté, implémenter les bons algos de manière efficace... Tester, corriger.
Mon stagiaire (bac+5 pourtant) a réussi en quelques heures à faire passer un affichage de données qui prenait 1s à 1 min dans mon appli ! Juste parce qu'il ne maîtrisait pas le SQL.
 
Tout ça pour dire que coder une appli de gestion, déjà que lorsque c'est son métier, c'est déjà pas évident, mais quand ce n'est pas son métier, c'est quasi mort à moins d'être vraiment très bon (et c'est malheureusement pas souvent le cas)
 
A l'exception des mdp en clair, un wiki peut s'avérer très puissant dès lors qu'on lui a installé quelques fonctions très pratiques (ex : taxonomie, moteur de recherche efficace, espaces de noms, redirections, extension de syntaxe...)
 
Un classique : https://www.triskel.ch/wp-content/u [...] _avant.png
 
Je suis issu d'une petite boîte d'environ 10 personnes dont le patron. Aujourd'hui, je travaille dans une grosse boîte. Le fait est qu'on était bien plus organisé dans la petite que dans la grosse. La taille du service, de l'entreprise, n'est pas le facteur clé. C'est la volonté de chaque individu à bien vouloir travailler de manière structurée, avec des processus, des méthodologies et des outils qui automatisent un maximum de choses afin de diminuer la charge mentale des personnes.
 
Mon travail, depuis 15 ans, c'est justement de mettre en place une méthodologie efficace reposant, entre autres, sur des outils. Mon outil Astres (cf ma signature), que j'ai développé depuis 2003, sert justement à ça. Sur une équipe de 30 personnes, il a fait gagner 3 ETP. On a donc pu faire plus de choses qu'avant ou plus vite.
Et cet outil se couple avec Mediawiki pour la base de connaissances + un algorithme d'analyse sémantique pour repérer les tickets similaires ou identiques. Le datamining appelé aujourd'hui big data) et la gestion de connaissances sont mes 2 autres passions
 
En tout cas, bonne chance pour la suite. Je pense que tu peux tout à fait améliorer pleins de choses dans ta petite boîte mais ça va demander du temps et de la méthodologie et des compétences, quitte à vous faire aider de l'extérieur
 
"Tout seul, on va plus vite, ensemble, on va plus loin."
 
PS : je ne veux pas me montrer moralisateur. Simplement, ton cas est du vu et revu et re-revu mais pas une fatalité. Il existe des méthodologies pour arriver à obtenir ce qu'on veut au final sans que le projet dérive en coût ou délais ou répondre aux besoins

Je suis pas du tout qualifié pour faire du "vrai" dev, mais je connais un principe qui s'appelle KIS: Keep it simple.
Si je comprends bien le problème initial c'est "juste" une histoire de mot de passe en clair. Or pour corriger ça tu veux créer en partant de zéro tout une application ce qui doit représenter un travail monstre (avec toutes les problèmes que décrivent rufo et les autres "vrais" dev). Tu ne vois pas un peu trop grand? Je comprends, tu es motivé et tu veux apprendre, c'est une très bonne chose, mais on a vite fait de se casser complètement la figure - ça je l'ai eu avec des projets perso.  
 
Si tu veux développer une appli de gestion soit, amuses-toi, mais ne te mets pas la pression en disant au patron que tu vas faire un truc qui va tout gérer d'ici $délai temps. Pour le besoin immédiat je regarderais plutôt si il n'y a pas une solution simple, au pire un peu HB comme une archive / un fichier cryptée / un conteneur crypté ou ce genre de truc.
 
Enfin bref, comme je dis je suis pas qualifié, c'est juste des pensées...

@rufo : merci pour le partage de ton expérience.  
Je sais pourquoi on n’est pas organisés, c’est parce qu’il n’y a pas de volonté du boss de le devenir. Dès qu’on parle de mettre en place un process, ça dure jamais. A partir de là j’ai finit par baisser les bras. Comme les autres avant moi. Je me suis lancé dans ce dev pour les raisons évoqués plus haut, à savoir le goût d’apprendre, de progresser en dev, de faire passer le temps, la satisfaction de se creuser les neurones pour résoudre des problèmes, avec peut être la satisfaction qu’un jour ça rentre en prod. Notre besoin en terme d’application métier est vraiment simple, on pourrait presque s’en sortir avec un tableur. On l’a même essayé mais c’est l’enfer à maintenir.  
 
@rat de combat : non ce n’est pas juste pour stocker des mots de passe. C’est le titre du sujet car c’est la dessus que je bloquais. Si c’était pour des mots de passe je proposerai autre chose. Keepass, Lastpass... ce genre de chose. Je développe ce truc pour ajouter de l’interaction entre les éléments. Tel serveur est pris en backup par tel autre, je peux me rendre sur la page du serveur de backup et voir tous les serveurs qu’il prend en backup, par exemple. Sur ce serveur je vois qu’il appartient à tel client, je le retrouve sur la page du client. Même chose pour monitoring, virtualisation, etc.