Tôi có nên chấp nhận viết mã không an toàn nếu chủ lao động yêu cầu tôi làm như vậy không? [đóng cửa]

Chủ nhân của tôi yêu cầu tôi triển khai một tính năng yêu cầu lưu trữ mật khẩu bằng văn bản rõ ràng trong cơ sở dữ liệu (hoặc sử dụng chức năng mã hóa / giải mã tối nghĩa được lưu trữ trong tệp nhị phân, tốt hơn một chút, nhưng cũng không an toàn).

Tôi trả lời rằng tôi sẵn sàng thực hiện một tính năng như vậy, miễn là khách hàng được thừa nhận về ý nghĩa bảo mật khi sử dụng nó.

Khi thảo luận vấn đề này với các đồng nghiệp, có người nói với tôi rằng, là một kỹ sư phần mềm, chúng tôi chịu trách nhiệm cá nhân (theo nghĩa pháp lý) đối với các vấn đề bảo mật mà chúng tôi giới thiệu trong các sản phẩm của mình. Tôi đã xem xét hợp đồng của mình, nhưng không tìm thấy bất cứ điều gì liên quan đến một trường hợp tương tự.

Từ quan điểm pháp lý, tôi có nên từ chối thực hiện một tính năng như vậy? Có đúng là chủ nhân của tôi có thể đưa tôi ra tòa nếu khách hàng gặp thiệt hại do tính năng này, ngay cả khi anh ta cũng nhận thức được mối quan tâm về bảo mật?

EDIT: Tôi hiểu câu hỏi này chỉ có thể được trả lời một cách đáng tin cậy từ một luật sư. Điều tương tự cũng đúng đối với các câu hỏi cấp phép: mọi người ở đây đưa ra hiểu biết và kinh nghiệm của họ, đôi khi sau khi hỏi ý kiến ​​luật sư, không có gì đảm bảo nó được áp dụng trong khu vực tài phán khác. Nhưng cấp phép được chấp nhận rõ ràng là một chủ đề ở đây, xem Tôi có thể hỏi loại câu hỏi nào ở đây? . Tôi tin rằng các lập trình viên khác có thể có cùng một vấn đề, và người khác có thể đã phải đối mặt với tình huống này trước đây, và có thể đã hỏi ý kiến ​​một luật sư cho điều đó.

Đồng nghiệp của bạn đang sai lầm, đặc biệt là vì bạn không thể tìm thấy bất cứ điều gì về trách nhiệm bảo mật trong hợp đồng của bạn. Ngay cả khi nó đã làm, bạn chỉ nhận được một lệnh xung đột từ quản lý.

Tôi nghĩ rằng lần duy nhất bạn phải chịu sự kiện tụng tiềm tàng là nếu bạn cố tình làm hỏng sản phẩm, tự tạo ra quả bom hẹn giờ, quả trứng Phục sinh, v.v.

Trong hầu hết các trường hợp, công ty sở hữu phần mềm, vì vậy họ có thể tận hưởng lợi nhuận, nhưng điều đó cũng có nghĩa là họ cũng phải chấp nhận rủi ro, chứ không phải nhà phát triển cá nhân.

Cá nhân, tôi sẽ đảm bảo quản lý nhận thức được các vấn đề với tính năng bảo mật này, để nó được ghi lại trước và tiếp tục thực hiện công việc của tôi.

Điều đó đang được nói, tham khảo ý kiến ​​một luật sư, yada-yada-yada.

Bất cứ điều gì xảy ra: Không bao giờ viết mã như vậy mà không có email hoặc bằng chứng khác cho thấy rõ rằng bạn chỉ cần làm theo hướng dẫn của chủ lao động.

Từ quan điểm pháp lý, tham khảo ý kiến ​​một luật sư. Tôi không phải là một, chúng tôi cũng không có bất kỳ manh mối nào về quyền tài phán hoặc luật pháp mà bạn sống theo đó có thể giúp giải thích một số điều. Nhưng trong mọi trường hợp hãy tham khảo ý kiến ​​một luật sư, bạn có tin tưởng một trang web Hỏi & Đáp về internet với tương lai cá nhân, chuyên nghiệp và tài chính của bạn không.

Lời khuyên kinh doanh chung là đảm bảo bạn đặt phòng bằng văn bản và lệnh trực tiếp của chủ nhân để tiếp tục đưa ra các mối quan tâm về bảo mật bằng văn bản. Nếu mọi thứ đi về phía nam và chạm vào quạt, bạn sẽ có điều đó để quay trở lại.

Một cách khác để giải quyết vấn đề này là nhìn sâu hơn vào các yêu cầu - bạn đã chia sẻ kế hoạch không phải là vấn đề bạn đang giải quyết. Có nhiều cách để lột da mèo hoặc xử lý các yêu cầu tra cứu mật khẩu.

Tôi sẽ không lo lắng về điều đó - không giống như bạn quyết định độc hại khi đưa tính năng không an toàn vào và tự khai thác nó sau đó, hoặc chỉ đưa nó vào vì bạn sơ suất. Công ty muốn điều này, ai đó đã quyết định đánh đổi giữa thời gian phát triển và kỳ vọng của người dùng là chấp nhận được (như thường lệ) và vì vậy bạn nên tiếp tục với nó. Nếu bạn thực sự lo lắng về bất kỳ sự trở lại nào, hãy gửi email cho sếp của bạn và giữ phản hồi. Khi bạn đã thực hiện điều đó, với tư cách là một nhân viên, bạn được bảo vệ.

Đôi khi có những lý do tại sao điều này có thể chấp nhận được - ví dụ, tôi biết một số giải pháp rất quan trọng là lưu trữ mật khẩu văn bản đơn giản, nhưng phần còn lại của hệ thống được bảo mật để điều này không trở thành vấn đề. Hệ thống này là trên một mạng riêng chẳng hạn. Nếu bạn không biết phần còn lại của câu chuyện (một tình huống phổ biến ở hầu hết các công ty) thì bạn có thể mong đợi một cách hợp lý rằng ai đó đã xem xét điều này. Tương tự, nếu bạn có email đó từ sếp của bạn, bạn có thể mong đợi rằng anh ấy biết mình đang làm gì.

Ngẫu nhiên ... đây có phải là sản phẩm tôi (với tư cách là người tiêu dùng) có thể sử dụng không? Nếu vậy .. nó là gì, vì vậy tôi có thể tránh nó? :)

Chúng tôi có nhận ra rằng nhiều lỗi được thêm bởi các nhà phát triển gây hại cho khách hàng trong quá trình hoạt động trực tiếp với tài sản lớn không kém. Chúng tôi không nghĩ rằng họ có chủ ý nhưng nó vẫn là kết quả của một số công việc cụ thể của chúng tôi và vẫn chưa đạt được mục đích. Vì vậy, ví dụ bạn đã đưa ra không phải là trường hợp cá biệt, trong đó các quyết định của nhà phát triển (hoặc cấp cao hơn) ảnh hưởng đến khách hàng.

Đây là những gì tôi đề nghị:

1. Trước hết, bằng mọi cách - đó là công ty đang phân phối phần mềm cho công ty kia. Một cá nhân không được cấp tín dụng trực tiếp (ngoài tiếng vỗ tay trong nhóm và nhiều nhất là tiền lương) và quyền sở hữu công việc. Vì vậy, mặc dù đây không phải là một điều tốt trong giao hàng của chúng tôi, nhưng bạn không phải là tội phạm ở đây - miễn là quyết định không phải là của bạn.

2. Là một lập trình viên chuyên nghiệp - bạn sẽ chỉ ra rõ ràng các hạn chế của mã và các nguy hiểm liên quan đến cách duy trì mọi thứ như một phần của tệp README hoặc tài liệu liên quan. Nếu có một tài liệu yêu cầu - báo cáo thử nghiệm được đề xuất, vv nên đề cập rõ ràng các hạn chế.

3. Để buộc người ra quyết định thực sự phải chịu trách nhiệm - tôi sẽ yêu cầu cấp trên xác nhận suy nghĩ của họ trong email về bất kỳ tài liệu nào như vậy.

4. Cân nhắc rủi ro một cách chính xác. Phần mềm thẻ dữ liệu của tôi không lưu trữ mật khẩu trong văn bản kế hoạch nhưng điều đó không quan trọng. Nhưng điều tương tự không được chấp nhận nếu tôi đang lưu trữ mật khẩu ngân hàng hoặc nếu nó đang truy cập vào cơ sở dữ liệu hoặc máy chủ. Vì vậy, dựa trên rủi ro thực tế, bạn phải leo thang vấn đề lên cao nhất có thể.

Trừ khi bạn thực hiện công việc của mình một cách có chủ ý gây tổn hại, có rất ít nhược điểm pháp lý để thực hiện các nhiệm vụ được yêu cầu của bạn. Bạn sẽ có một hợp đồng lao động sẽ nêu rõ các khoản nợ của bạn, bạn có thể hỏi ý kiến ​​luật sư về các kỹ thuật. Nhận văn bản chấp thuận quyết định thiết kế về mật khẩu văn bản gốc nếu bạn thực sự cảm thấy bị phơi bày.

Tôi sẽ không tiết lộ đó là phần mềm nào cho đến khi tôi chắc chắn tính năng này làm cho nó trong bản phát hành cuối cùng. Tôi vẫn hy vọng chúng tôi quản lý để thông báo cho khách hàng theo cách mà tôi thấy nó có thể chấp nhận được.

Đáng lo ngại hơn một chút là câu nói của bạn về 'thông báo cho khách hàng'. Nếu bạn làm hỏng công ty của bạn, uy tín, v.v. (một điều khoản sẽ có trong hợp đồng của bạn) thì công ty của bạn có thể kiện bạn - và một người bảo vệ 'người thổi còi' có thể không giúp bạn khi bạn cần tham khảo hoặc công việc khác.

Nếu bạn không hài lòng về hệ lụy của các lỗ hổng bảo mật thì hãy tiếp tục và tiếp tục, nhưng nếu đó không phải là quyết định của bạn và không phải là công ty của bạn thì tôi không thể hiểu tại sao điều này lại bị 'đổ lỗi' (về mặt pháp lý) cho bạn .

Công ty của bạn nên có một hình thức bảo hiểm bồi thường chuyên nghiệp khi họ thuê bạn. Đây nên cung cấp bảo vệ pháp lý đầy đủ cho tất cả các nhân viên của mình trong trường hợp bất cứ điều gì sẽ xảy ra với các phần mềm, hoặc lạm dụng các phần mềm hoặc sai sót được tìm thấy trong các phần mềm (như mật khẩu không được mã hóa).

Là một nhân viên, bạn phải làm những gì họ yêu cầu, và họ phải làm những gì khách hàng muốn, miễn là không bên nào vi phạm pháp luật, không có vấn đề gì, nhưng nếu bạn làm những gì công ty muốn, và sau đó được phát hiện không phải là những gì khách hàng muốn / yêu cầu, sau đó là giữa họ và bảo hiểm bồi thường chuyên nghiệp sẽ bảo vệ bạn khỏi mọi trách nhiệm / trách nhiệm cá nhân.

IANAL, nhưng tôi sẽ giải quyết vấn đề này với đội ngũ pháp lý của công ty, ngoài việc kiểm tra với luật sư của bạn.

PS, nếu bạn bị ảnh hưởng nghiêm trọng bởi điều này, hãy lưu tất cả các email có liên quan dưới dạng bản sao điện tử & cứng ở đâu đó ngoài trang web nếu có thể.

Thời gian cho một công việc mới. Quên thực hiện điều này. Đã đến lúc di chuyển. Nếu họ sẵn sàng tỏ ra ung dung và gian dối với điều này, họ cũng sẽ không sợ ném bạn xuống xe buýt.

Ngoài ra, đừng sợ một khi bạn đã liên hệ nặc danh với một trong nhiều nhóm chỉ ra lỗ hổng bảo mật trong phần mềm của mọi người. Đây là một thảm họa đang chờ để xảy ra. Hoàn toàn không có lý do âm thanh để lưu trữ những thứ này. Có phải ông chủ của bạn cho bạn một lý do? Họ có muốn đăng nhập như người dùng không? Họ có muốn làm cho việc lấy lại mật khẩu dễ dàng hơn không? Trừ khi bạn nhận được câu trả lời cho một trong những điều trên mà bạn có thể giải quyết an toàn hơn, thì đây là lúc để tiếp tục. Khi bạn rời đi, tốt nhất là không nói với họ tại sao.

bạn có thể làm gì để làm theo chỉ dẫn để lưu trữ mật khẩu ở định dạng có thể phục hồi trong khi vẫn không thể truy xuất nếu bạn có quyền truy cập đầy đủ vào chương trình đang sử dụng mã hóa bất đối xứng

bạn mã hóa khóa (được muối như mọi khi) bằng khóa chung được lưu trữ trong tệp nhị phân

và khi mật khẩu là cần thiết trong văn bản đơn giản, con người cần cung cấp khóa riêng được giữ an toàn khỏi máy chủ

Cá nhân, tôi chưa bao giờ nghe nói về một kỹ sư phần mềm, không có điều khoản trong hợp đồng hoặc thỏa thuận chính thức khác, chịu trách nhiệm pháp lý về các vấn đề bảo mật trong các sản phẩm mà họ làm việc. Từ những gì tôi đã đọc về luật pháp và đạo đức trong công nghệ phần mềm, các yêu cầu bảo mật cho một hệ thống được quyết định bởi đặc tả yêu cầu, cũng đề cập đến bất kỳ yêu cầu pháp lý, công nghiệp hoặc doanh nghiệp nào. Khi xây dựng một hệ thống, việc không đáp ứng các yêu cầu bảo mật được coi là không hoàn thành các điều khoản của hợp đồng vì hệ thống không được xây dựng theo quy định. Làm thế nào các sự kiện cụ thể diễn ra phụ thuộc vào hợp đồng giữa kỹ sư và người sử dụng lao động và người sử dụng lao động và khách hàng.

Luật pháp cũng không cho bạn biết những gì bạn nên làm, nhưng những gì bạn có thể / không thể làm. Bạn không đề cập đến ngành nghề của mình, nhưng một số có luật, quy định và quy tắc về cách xử lý các loại dữ liệu cụ thể - những gì phải được mã hóa, mức mã hóa tối thiểu, yêu cầu quản lý / kiểm soát truy cập, và kể từ đó trở đi. Nếu khu vực của bạn (quốc gia, tiểu bang) không có quy tắc về bảo mật, thì ngành của bạn không có quy tắc về bảo mật và các yêu cầu phần mềm không gọi ra các yêu cầu hoặc tiêu chuẩn bảo mật, đó có thể là vấn đề đạo đức hơn là vấn đề về pháp luật.

Khi nói đến các vấn đề đạo đức trong phát triển phần mềm, tôi đăng ký Bộ quy tắc đạo đức và thực hành kỹ thuật phần mềm . Cuối cùng, đó là cuộc gọi của bạn. Tuy nhiên, tôi cảm thấy rằng việc lưu trữ mật khẩu trong bản rõ hoặc ở định dạng có thể được giải mã là phi đạo đức.

Chỉ cần tuân thủ quy trình phát triển của dự án của bạn: nếu tính năng này được viết trong tài liệu yêu cầu, bạn sẽ thực hiện nó.