Dois-je accepter d'écrire un code non sécurisé si mon employeur me le demande? [fermé]

Mon employeur m'a demandé de mettre en œuvre une fonctionnalité qui nécessiterait de stocker des mots de passe en texte clair dans une base de données (ou d'utiliser une fonction de cryptage / décryptage obscure stockée dans un binaire, ce qui est un peu mieux, mais aussi non sécurisé).

J'ai répondu que j'étais prêt à implémenter une telle fonctionnalité, à condition que les clients soient reconnus des implications de sécurité lors de son utilisation.

Lors de la discussion de ce problème avec des collègues, quelqu'un m'a dit qu'en tant qu'ingénieur logiciel, nous sommes personnellement responsables (au sens juridique) des problèmes de sécurité que nous introduisons dans nos produits. J'ai examiné mon contrat, mais je n'ai rien trouvé concernant un cas similaire.

D'un point de vue juridique, dois-je refuser de mettre en œuvre une telle fonctionnalité? Est-il vrai que mon employeur pourrait me poursuivre en justice si un client subit des dommages en raison de cette fonctionnalité, même s'il était également conscient de problèmes de sécurité?

EDIT: Je comprends que cette question ne peut être répondue de manière fiable que par un avocat. Il en va de même pour les questions de licence: les gens ici donnent leur compréhension et leur expérience, parfois après avoir consulté un avocat, sans aucune garantie que cela s'applique dans une autre juridiction. Mais la licence est explicitement acceptée comme sujet ici, voir Quel genre de questions puis-je poser ici? . Je crois que d'autres programmeurs peuvent avoir le même problème, et d'autres peuvent avoir été confrontés à cette situation auparavant, et peuvent avoir consulté un avocat pour cela.

Votre collègue est erroné, d'autant plus que vous n'avez rien trouvé sur la responsabilité de la sécurité dans votre contrat. Même si c'était le cas, vous venez de recevoir un ordre contradictoire de la direction.

Je pense que la seule fois où vous vous soumettez à un litige potentiel est si vous endommagez sciemment le produit vous-même, créez votre propre bombe à retardement, œuf de Pâques, etc.

Dans la plupart des cas, l'entreprise est propriétaire du logiciel, ce qui lui permet de profiter des bénéfices, mais cela signifie également qu'elle doit assumer les risques, pas le développeur individuel.

Personnellement, je m'assurerais que la direction était au courant des problèmes avec cette fonctionnalité de sécurité, afin qu'elle soit documentée à l'avance, et je continue simplement à faire mon travail.

Cela étant dit, consultez un avocat, yada-yada-yada.

Quoi qu'il arrive: N'écrivez jamais un tel code sans avoir reçu un e-mail ou d'autres preuves montrant clairement que vous venez de suivre les instructions de votre employeur.

D'un point de vue juridique, consultez un avocat. Je n'en suis pas un, et nous n'avons aucune idée de la juridiction ou des lois sous lesquelles vous vivez qui pourraient aider à expliquer certaines choses. Mais dans tous les cas, consultez un avocat, feriez-vous confiance à un site Internet de questions / réponses avec votre avenir personnel, professionnel et financier.

Le conseil commercial général est de vous assurer que vous notez vos réservations par écrit et l'ordre direct de votre employeur de continuer, étant donné les problèmes de sécurité par écrit. Si les choses vont au sud et frappent l'éventail, vous aurez à vous rabattre.

Une autre solution consiste à approfondir les exigences: vous avez partagé le plan et non le problème que vous résolvez. Il existe plusieurs méthodes pour habiller un chat ou gérer les exigences de recherche de mot de passe.

Je ne m'inquiéterais pas à ce sujet - ce n'est pas comme si vous décidiez par malveillance de mettre la fonctionnalité non sécurisée et de l'exploiter vous-même plus tard, ou simplement de la mettre parce que vous êtes négligent. L'entreprise le veut, quelqu'un a décidé que le compromis entre le temps de développement et les attentes des utilisateurs est acceptable (comme d'habitude) et vous devriez donc y aller. Si vous êtes vraiment inquiet de tout retour, envoyez un e-mail à votre patron et conservez la réponse. Une fois que vous avez fait cela, en tant qu'employé, vous êtes couvert.

Parfois, il y a des raisons pour lesquelles cela est acceptable - par exemple, je connais des solutions très critiques qui stockent des mots de passe en texte brut, mais le reste du système est sécurisé afin que cela ne devienne pas un problème. Ce système est par exemple sur un réseau séparé. Si vous ne connaissez pas le reste de l'histoire (une situation courante dans la plupart des entreprises), vous pouvez raisonnablement vous attendre à ce que quelqu'un d'autre y réfléchisse. De même, si vous avez cet e-mail de votre patron, vous pouvez vous attendre à ce qu'il sache ce qu'il fait.

Soit dit en passant ... est-ce un produit que je (en tant que consommateur) pourrais utiliser? Si oui .. qu'est-ce que c'est, donc je peux l'éviter? :)

Nous rendons-nous compte que de nombreux bogues sont ajoutés par les développeurs, ce qui nuit aux clients pendant les opérations en direct, ce qui est tout aussi important. Nous ne pensons pas qu'ils sont intentionnels, mais c'est toujours le résultat de certains de nos travaux concrets et toujours pas à la hauteur. Ainsi, l'exemple que vous avez fait n'est pas un cas isolé, où les décisions du développeur (ou des niveaux supérieurs) affectent le client.

Voici ce que je propose:

1. Tout d'abord, par tous les moyens - c'est l'entreprise qui livre le logiciel à l'autre entreprise. Un individu ne reçoit pas de crédit direct (au-delà des applaudissements au sein de l'équipe et du salaire maximum) et de la propriété du travail. Donc, bien que ce ne soit pas une bonne chose dans le cadre de notre livraison, mais vous n'êtes pas le criminel ici - tant que la décision ne vous appartient pas.

2. En tant que programmeur professionnel - vous indiqueriez clairement les limites du code et les dangers impliqués dans la façon de maintenir les choses dans le cadre du fichier README ou de la documentation impliquée. S'il existe un document d'exigences - le rapport d'essai suggéré, etc. doit mentionner clairement les limites.

3. Afin de tenir le véritable décideur pour responsable, je demanderais au plus haut niveau de confirmer sa pensée dans l'e-mail de ces documents.

4. Pesez le risque correctement. Mon logiciel de carte de données stocke le mot de passe dans le texte du plan, mais ce n'est pas important. Mais la même chose n'est pas acceptable si je stocke un mot de passe bancaire ou s'il s'agit d'un accès à une base de données ou à un serveur. Donc, en fonction du risque réel, vous devez faire remonter le problème le plus haut possible.

À moins que vous n'effectuiez votre travail de manière délibérément dommageable, il y a peu d'inconvénients légaux à faire les tâches qui vous sont demandées. Vous aurez un contrat de travail qui indiquera vos responsabilités, vous pouvez consulter un avocat sur les détails techniques. Obtenez une approbation écrite de la décision de conception sur les mots de passe en texte brut si vous vous sentez vraiment exposé.

Je ne révélerai pas de quel logiciel il s'agit tant que je ne suis pas sûr que cette fonctionnalité sera disponible dans la version finale. J'espère toujours que nous parviendrons à informer les clients d'une manière que je trouve acceptable.

Un peu plus inquiétant est votre citation sur «l'information des clients». Si vous portez atteinte à la réputation, à la réputation de votre entreprise, etc. (une clause qui figurera dans votre contrat), votre entreprise pourrait vous poursuivre - et une défense de `` dénonciateur '' pourrait ne pas vous aider lorsque vous avez besoin d'une référence ou d'un autre emploi.

Si vous n'êtes pas satisfait des implications des failles de sécurité, rafraîchissez votre curriculum vitae et passez à autre chose, mais si ce n'était pas votre décision et que ce n'est pas votre entreprise, je ne vois pas pourquoi cela vous serait `` blâmé '' (légalement) .

Votre entreprise aurait dû souscrire une forme d'assurance responsabilité professionnelle lorsqu'elle vous a engagé. Cela devrait assurer une protection juridique adéquate pour tous ses employés en cas de quoi que ce soit qui ne va pas avec le logiciel, ou une mauvaise utilisation des logiciels ou des défauts se trouvent dans le logiciel (comme les mots de passe non chiffrés).

En tant qu'employé, vous êtes censé faire ce qu'il demande, et il est censé faire ce que veut le client, tant qu'aucune des parties n'enfreint la loi, il n'y a pas de problème, mais si vous faites ce que l'entreprise veut, et n'est pas ce que le client voulait / exigeait, alors c'est entre eux, et l'assurance responsabilité professionnelle devrait vous couvrir de tout blâme / responsabilité personnelle.

IANAL, mais je voudrais en discuter avec l'équipe juridique de l'entreprise, en plus de vérifier avec vos propres avocats.

PS, si vous êtes sérieusement effrayé par cela, enregistrez tous les e-mails pertinents dans une copie électronique et papier quelque part hors site si possible.

Il est temps pour un nouvel emploi. Oubliez la mise en œuvre de cela. Il est temps de bouger. S'ils sont prêts à être si cavaliers et trompeurs avec cela, ils n'auront pas peur de vous jeter sous le bus non plus.

De plus, n'ayez pas peur une fois que vous êtes allé contacter anonymement l'un des nombreux groupes qui signalent des failles de sécurité dans les logiciels des peuples. C'est un désastre qui attend de se produire. Il n'y a absolument aucune raison valable de les stocker. Votre patron vous a-t-il donné une raison? Souhaitent-ils se connecter en tant qu'utilisateurs? Souhaitent-ils faciliter la récupération des mots de passe? À moins que vous n'obteniez une réponse à l'une de ces questions ci-dessus que vous pouvez aborder de manière plus sécurisée, il est temps de passer à autre chose. Lorsque vous partirez, il serait préférable de ne pas leur dire pourquoi.

ce que vous pouvez faire pour suivre les instructions pour stocker les mots de passe dans un format récupérable tout en étant impossible à récupérer si vous avez un accès complet au programme utilise un cryptage asymétrique

vous cryptez la clé (salée comme toujours) avec la clé publique stockée dans le binaire

et lorsque les mots de passe sont nécessaires en texte brut, un humain a besoin de fournir la clé privée qui est autrement gardée en sécurité loin du serveur

Personnellement, je n'ai jamais entendu parler d'un ingénieur logiciel, sans clause du contrat ou autre accord formel, tenu légalement responsable des problèmes de sécurité des produits sur lesquels il travaille. D'après ce que j'ai lu sur les lois et l'éthique en génie logiciel, les exigences de sécurité pour un système sont dictées par la spécification des exigences, qui fait également référence à toutes les exigences légales, industrielles ou d'entreprise. Lors de la construction d'un système, le non-respect des exigences de sécurité est traité comme un échec à remplir les termes du contrat car le système n'a pas été construit comme spécifié. Le déroulement des événements spécifiques dépend des contrats entre l'ingénieur et l'employeur et l'employeur et le client.

Les lois ne vous disent pas non plus ce que vous devez faire, mais ce que vous pouvez / ne pouvez pas faire. Vous ne mentionnez pas le secteur dans lequel vous vous trouvez, mais certains ont des lois, des réglementations et des règles sur la façon de traiter des types de données spécifiques - ce qui doit être crypté, les niveaux minimaux de cryptage, les exigences de gestion / contrôle d'accès, et ainsi de suite. Si votre région (pays, état) n'a pas de règles de sécurité, que votre industrie n'a pas de règles de sécurité et que les exigences logicielles n'exigent pas d'exigences ou de normes de sécurité, cela pourrait être plus un problème éthique qu'un problème légal.

En ce qui concerne les questions éthiques dans le développement de logiciels, je souscris au Code d'éthique et de pratique professionnelle du génie logiciel . En fin de compte, c'est votre appel. Cependant, je pense que le stockage des mots de passe en clair ou dans un format qui peut être décrypté est contraire à l'éthique.

Il suffit de se conformer au processus de développement de votre projet: si cette fonctionnalité est écrite dans le document d'exigence, vous devez l'implémenter.