10
votes

Open Source et comment cela fonctionne pour des projets sécurisés?

J'ai toujours voulu faire certaines de nos entreprises produits open-source..mais nous avons beaucoup de choses dans notre code source qui nous rendrait vulnurables. Comment cela est-il traité dans la plupart des projets open source? Par exemple, nous utilisons des services Web personnalisés pour faire des actions dans notre base de données (ajouter des comptes, des comptes de suppression, ECT). Le code source devrait contenir la clé (mot de passe) que nous utilisons pour utiliser le service Web. Si quelqu'un voulait, ils pourraient attraper la source, obtenir la clé d'utiliser notre service Web et épauler des ravages sur notre base de données.

sont-ils juste des projets qui ne devraient pas être open source? Ou est-il courant de simplement mettre les choses sensibles dans un fichier ou quelque chose et ne pas inclure cette partie? (Bien que cela puisse faire cela, rendrait la source un peu inutile pour le public car elle perdrait sa fonctionnalité).

Tous les liens ou ressources sur des projets open-source et comment ce genre de choses devrait être traitée serait bien.

merci


2 commentaires

Pourquoi voulez-vous ouvrir le produit? Si vous le faites parce que vous pensez avoir beaucoup de développement gratuit, ce n'est pas la façon dont cela fonctionne. Les gens ne travailleront que sur des projets qu'ils utilisent et n'utiliseront que des projets qui leur fournissent une certaine valeur.


Voir aussi: Comment les projets open source gèrent-ils des artefacts sécurisés?


5 Réponses :


3
votes

ne serait-il pas possible de mettre vos données raisonnables dans un fichier de configuration? Cela permettra également aux autres utilisateurs d'ajouter facilement leurs propres informations sensibles, etc.


1 commentaires

Le fichier de configuration peut ne pas s'appliquer dans tous les cas. Normalement, nous utiliserons des fichiers de base de données / XML pour stocker les paramètres.



2
votes

Vous ne devez pas inclure les données sensibles au public, une option peut donc être de créer une API publique pour les services, puis les utilisateurs devraient créer un compte pour obtenir une clé API pour les données.

Je ne pense pas que cela devrait vous empêcher d'ouvrir la source des produits, mais je pense que vous devez repenser la manière dont les données sont accomplies à la haoute une API publique.


0 commentaires

9
votes

Les mots de passe et les données SENSTITATIVES sont mieux inclus le fichier source. Si vous regardez la conception de logiciels open-source comme phpmyadmin, un fichier de configuration est fourni pour ajouter ces informations et sont généralement stockés dans le dossier racine du bohost Webhost (ou n'importe où en dehors du dossier www).

L'idée est donc que si votre site Web utilise des informations pour créer un lien vers un service, vous devez également les masquer dans un fichier et demander à votre utilisateur de fournir le mot de passe et de créer leur propre compte.


0 commentaires

1
votes

Bien que les codes de programme sont open-source, vos données sensibles ne sont pas. Ne jamais "fournir" vos données à d'autres.

Normalement, la vérification de hachage à sens unique peut déjà être utilisée comme cryptage de base. Si une sécurité supplémentaire est nécessaire, utilisez une mesure supplémentaire, comme des clés publiques et privées et des mots de passe pré-partagés.


0 commentaires

2
votes

Si vous êtes un mot de passe de base de données dans votre code, vous le faites mal. Comme d'autres ont souligné, vous devez stocker cela dans un fichier de configuration séparé et protégé.

Si vous distribuez votre code, soyez-lui la source ou juste un binaire, ce mot de passe est là et peut être récupéré par quiconque qui se soucie de le faire. Les mots de passe codés dans les binaires sont souvent une affaire triviale pour un pirate informatique à récupérer.


0 commentaires