¿Debo aceptar escribir un código no seguro si mi empleador me lo solicita? [cerrado]

Mi empleador me pidió que implementara una función que requeriría almacenar contraseñas en texto claro en una base de datos (o usar una función oscura de cifrado / descifrado almacenada en un binario, que es un poco mejor, pero también insegura).

Respondí que estaba dispuesto a implementar dicha función, siempre que se reconociera a los clientes las implicaciones de seguridad al usarla.

Al discutir este problema con colegas, alguien me dijo que, como ingeniero de software, somos personalmente responsables (en el sentido legal) de los problemas de seguridad que presentamos en nuestros productos. Revisé mi contrato, pero no encontré nada relacionado con un caso similar.

Desde un punto de vista legal, ¿debería negarme a implementar tal característica? ¿Es cierto que mi empleador podría llevarme a los tribunales si un cliente sufre daños debido a esta característica, incluso si también tiene conocimiento de las preocupaciones de seguridad?

EDITAR: Entiendo que esta pregunta solo puede ser respondida de manera confiable por un abogado. Lo mismo es cierto para las preguntas sobre licencias: las personas aquí dan su comprensión y su experiencia, a veces después de haber consultado a un abogado, sin garantía de que se aplique en otra jurisdicción. Pero la licencia se acepta explícitamente como un tema aquí, consulte ¿Qué tipo de preguntas puedo hacer aquí? . Creo que otros programadores pueden tener el mismo problema, y ​​otros pueden haberse enfrentado a esta situación antes, y pueden haber consultado a un abogado para eso.

Su colega está equivocado, especialmente porque no pudo encontrar nada sobre responsabilidad de seguridad en su contrato. Incluso si lo hiciera, acaba de recibir una orden conflictiva de la gerencia.

Creo que la única vez que se somete a un litigio potencial es si a sabiendas daña el producto usted mismo, crea su propia bomba de tiempo, huevo de pascua, etc.

En la mayoría de los casos, la compañía es propietaria del software, por lo que pueden disfrutar de las ganancias, pero también significa que también pueden asumir los riesgos, no el desarrollador individual.

Personalmente, me aseguraría de que la administración conociera los problemas con esta característica de seguridad, de modo que se documentara de antemano, y simplemente continuara haciendo mi trabajo.

Dicho esto, consulte a un abogado, yada-yada-yada.

Pase lo que pase: nunca escriba dicho código sin tener un correo electrónico u otra evidencia que demuestre claramente que acaba de seguir las instrucciones de su empleador.

Desde un punto de vista legal, consulte a un abogado. No soy uno, ni tenemos idea de la jurisdicción o leyes bajo las cuales usted vive que podrían ayudar a explicar algunas cosas. Pero, en cualquier caso, consulte a un abogado, ¿confiaría en un sitio de preguntas y respuestas de Internet con su futuro personal, profesional y financiero?

El consejo comercial general es asegurarse de obtener sus reservas por escrito y la orden directa de su empleador de continuar debido a las preocupaciones de seguridad por escrito. Si las cosas van hacia el sur y golpeas el ventilador, tendrás que recurrir a eso.

Otra forma de evitar esto sería profundizar en los requisitos: ha compartido el plan, no el problema que está resolviendo. Hay más de una forma de desollar a un gato o manejar los requisitos de búsqueda de contraseña.

No me preocuparía, no es como si decidieras maliciosamente poner la característica insegura y explotarla tú mismo más tarde, o simplemente ponerla porque eres negligente. La compañía quiere esto, alguien ha decidido que la compensación entre el tiempo de desarrollo y las expectativas del usuario es aceptable (como de costumbre) y, por lo tanto, debe seguir adelante. Si está realmente preocupado por cualquier regreso, envíe un correo electrónico a su jefe y guarde la respuesta. Una vez que haya hecho eso, como empleado, estará cubierto.

A veces hay razones por las que esto es aceptable; por ejemplo, conozco algunas soluciones de misión crítica que almacenan contraseñas de texto sin formato, pero el resto del sistema está protegido para que esto no se convierta en un problema. Este sistema está en una red separada, por ejemplo. Si no conoce el resto de la historia (una situación común en la mayoría de las empresas), puede esperar razonablemente que alguien más lo haya considerado. Del mismo modo, si tiene ese correo electrónico de su jefe, puede esperar que él sepa lo que está haciendo.

Por cierto ... ¿es este un producto que yo (como consumidor) podría usar? Si es así ... ¿qué es, así puedo evitarlo? :)

¿Nos damos cuenta de que los desarrolladores agregan numerosos errores que dañan a los clientes durante las operaciones en vivo a un activo igualmente excelente? No creemos que sean intencionales, pero aún así es el resultado de parte de nuestro trabajo concreto y aún no es correcto. Por lo tanto, el ejemplo que ha hecho no es un caso aislado, donde las decisiones del desarrollador (o superiores) afectan al cliente.

Esto es lo que sugiero:

1. En primer lugar, por supuesto, es la empresa la que entrega el software a la otra empresa. A un individuo no se le otorga un crédito directo (más allá de los aplausos dentro del equipo y el sueldo como máximo) y la propiedad del trabajo. Entonces, si bien esto no es algo bueno como parte de nuestra entrega, usted no es el criminal aquí, siempre y cuando la decisión no sea suya.

2. Como programador profesional, indicaría claramente las limitaciones del código y los peligros involucrados en cómo mantener las cosas como parte del archivo README o la documentación involucrada. Si hay un documento de requisitos, el informe de prueba sugerido, etc., debe mencionar claramente las limitaciones.

3. Para responsabilizar al verdadero responsable de la toma de decisiones, solicitaría al superior que confirme su opinión en el correo electrónico de dichos documentos.

4. Sopesar el riesgo correctamente. El software de mi tarjeta de datos almacena la contraseña en el texto del plan, pero eso no es importante. Pero lo mismo no es aceptable si estoy almacenando la contraseña del banco o si es el acceso a la base de datos o al servidor. Por lo tanto, según el riesgo real, debe escalar el problema lo más alto posible.

A menos que realice su trabajo de una manera deliberadamente perjudicial, hay pocas desventajas legales para realizar las tareas que se le solicitan. Tendrá un contrato de trabajo que indicará sus responsabilidades, puede consultar a un abogado sobre los aspectos técnicos. Obtenga la aprobación por escrito de la decisión de diseño de las contraseñas de texto sin formato si realmente se siente expuesto.

No revelaré qué software es hasta que esté seguro de que esta característica aparece en la versión final. Todavía tengo la esperanza de que podamos informar a los clientes de una manera que me parezca aceptable.

Un poco más preocupante es su cita sobre 'informar a los clientes'. Si daña la reputación de su compañía, su reputación, etc. (una cláusula sobre la cual estará en su contrato), entonces su compañía podría demandarlo, y una defensa de 'denunciante' podría no ayudarlo cuando necesite una referencia u otro trabajo.

Si no está satisfecho con las implicaciones de los agujeros de seguridad, repase su currículum y continúe, pero si no fue su decisión y no es su empresa, no puedo ver por qué esto sería 'culpable' (legalmente) de usted .

Su empresa debería haber contratado un seguro de indemnización profesional cuando lo contrataron. Esto debería proporcionar una protección legal adecuada para todos sus empleados en caso de cualquier cosa salga mal con el software, o el mal uso del software o fallas que se encuentren en el software (como contraseñas sin cifrar).

Como empleado, se supone que debe hacer lo que le piden, y se supone que debe hacer lo que el cliente quiere, siempre y cuando ninguna de las partes infrinja la ley, no hay problema, pero si hace lo que la empresa quiere, entonces se encuentra que no es lo que el cliente quería / requería, entonces eso está entre ellos, y el seguro de indemnización profesional debe cubrirlo de cualquier culpa / responsabilidad personal.

IANAL, pero me ocuparía de esto con el equipo legal de las compañías, además de consultar con sus propios abogados.

PD: si está seriamente asustado por esto, guarde todos los correos electrónicos relevantes en forma electrónica e impresa en algún lugar fuera del sitio si es posible.

Hora de un nuevo trabajo. Olvídate de implementar esto. Es hora de moverse. Si están dispuestos a ser tan arrogantes y engañosos con esto, tampoco tendrán miedo de arrojarte debajo del autobús.

Además, no tenga miedo una vez que se haya comunicado anónimamente con uno de los muchos grupos que señalan agujeros de seguridad en el software de la gente. Este es un desastre esperando a suceder. No hay absolutamente ninguna razón sólida para almacenarlos. ¿Tu jefe te dio una razón? ¿Quieren iniciar sesión como usuarios? ¿Quieren facilitar la recuperación de contraseñas? A menos que obtenga una respuesta a una de estas anteriores que pueda abordar de manera más segura, entonces es hora de seguir adelante. Cuando te vayas, sería mejor no decirles por qué.

lo que puede hacer para seguir las instrucciones para almacenar contraseñas en un formato recuperable y, al mismo tiempo, es imposible recuperarlas si tiene acceso completo al programa utilizando cifrado asimétrico

cifras la clave (salada como siempre) con la clave pública almacenada en el binario

y cuando las contraseñas se necesitan en texto plano, un humano necesita proporcionar la clave privada que de otro modo se mantendría segura lejos del servidor

Personalmente, nunca he oído hablar de un ingeniero de software, sin una cláusula en el contrato u otro acuerdo formal, siendo legalmente responsable de los problemas de seguridad en los productos en los que trabajan. Por lo que he leído sobre las leyes y la ética en la ingeniería de software, los requisitos de seguridad para un sistema están dictados por la especificación de requisitos, que también se refiere a los requisitos legales, industriales o corporativos. Cuando se construye un sistema, el incumplimiento de los requisitos de seguridad se trata como un incumplimiento de los términos del contrato, ya que el sistema no se construyó según lo especificado. Cómo se desarrollan los eventos específicos depende de los contratos entre el ingeniero y el empleador y el empleador y el cliente.

Las leyes tampoco le dicen lo que debe hacer, sino lo que puede / no puede hacer. No menciona en qué industria se encuentra, pero algunos tienen leyes, regulaciones y reglas sobre cómo manejar tipos específicos de datos: qué debe cifrarse, niveles mínimos de cifrado, requisitos para administrar / controlar el acceso, Etcétera. Si su área (país, estado) no tiene reglas sobre seguridad, su industria no tiene reglas sobre seguridad y los requisitos de software no mencionan los requisitos o estándares de seguridad, podría ser más un problema ético que un Problema legal.

Cuando se trata de cuestiones éticas en el desarrollo de software, me suscribo al Código de Ética y Práctica Profesional de Ingeniería de Software . En última instancia, es tu decisión. Sin embargo, creo que almacenar contraseñas en texto sin formato o en un formato que se pueda descifrar no es ético.

Simplemente cumpla con el proceso de desarrollo de su proyecto: si esta característica está escrita en el documento de requisitos, deberá implementarla.