Haruskah saya menerima untuk menulis kode tidak aman jika majikan saya meminta saya untuk melakukannya? [Tutup]


24

Majikan saya meminta saya untuk mengimplementasikan fitur yang akan membutuhkan penyimpanan kata sandi dalam teks yang jelas dalam database (atau menggunakan fungsi enkripsi / dekripsi tersembunyi yang disimpan dalam biner, yang sedikit lebih baik, tetapi juga tidak aman).

Saya menjawab bahwa saya bersedia menerapkan fitur seperti itu, asalkan pelanggan mengetahui implikasi keamanan ketika menggunakannya.

Ketika mendiskusikan masalah ini dengan kolega, seseorang mengatakan kepada saya bahwa, sebagai insinyur perangkat lunak, kami secara pribadi bertanggung jawab (dalam pengertian hukum) untuk masalah keamanan yang kami perkenalkan dalam produk kami. Saya melihat ke dalam kontrak saya, tetapi tidak menemukan sesuatu yang berhubungan dengan kasus serupa.

Dari sudut pandang hukum, haruskah saya menolak untuk mengimplementasikan fitur seperti itu? Benarkah majikan saya dapat membawa saya ke pengadilan jika seorang pelanggan mengalami kerusakan karena fitur ini, bahkan jika ia juga mengetahui masalah keamanan?


EDIT: Saya mengerti pertanyaan ini hanya dapat dijawab dengan andal dari seorang pengacara. Hal yang sama berlaku untuk pertanyaan perizinan: orang-orang di sini memberikan pemahaman dan pengalaman mereka, kadang-kadang setelah berkonsultasi dengan pengacara, tanpa jaminan itu berlaku di yurisdiksi lain. Tetapi lisensi diterima secara eksplisit sebagai topik di sini, lihat Pertanyaan apa yang bisa saya tanyakan di sini? . Saya percaya programmer lain mungkin memiliki masalah yang sama, dan yang lain mungkin pernah berhadapan dengan situasi ini sebelumnya, dan mungkin telah berkonsultasi dengan pengacara untuk itu.


2
Anda harus menghubungi pengacara - ini bukan tempat yang tepat untuk mendapatkan jawaban.
Oded

11
IANAL, tetapi tampaknya tidak mungkin bahwa seorang majikan akan berhasil menuntut seorang karyawan untuk melakukan persis apa yang mereka perintahkan kepadanya untuk lakukan.

3
@Oded: klien dapat menuntut perusahaan, ya, dan perusahaan mungkin masih menyalahkan dan memecat karyawan secara tidak adil (dalam yurisdiksi "sesuka"), tetapi saya belum pernah mendengar ada pelanggan yang dapat menuntut masing-masing programmer. The perusahaan adalah badan hukum yang masuk ke dalam kontrak penjualan, tidak karyawan, sehingga perusahaan yang bertanggung jawab untuk masalah kualitas dalam produk.

8
Apa yang bisa menurunkan kepercayaan pelanggan Anda dalam solusi Anda lebih dari menyimpan kata sandi dalam teks biasa ?! Kemustahilan. Jika bos Anda akan meminta Anda untuk menggali kuburnya sendiri maka lakukan saja, tetapi pastikan Anda mendapatkannya secara tertulis melalui email bahwa Anda memberi tahu dia tentang ketidaksetujuan Anda dan memperingatkannya tentang kemungkinan konsekuensi, dan juga dia memerintahkan Anda untuk lakukan saja. Simpan korespondensi itu dengan Anda selalu.
maple_shaft

3
Saya memberikan suara untuk menutup pertanyaan ini sebagai di luar topik karena pertanyaan hukum yang hanya dapat dijawab dengan benar oleh pengacara.

Jawaban:


11

Rekan Anda salah arah, terutama karena Anda tidak dapat menemukan apa pun tentang tanggung jawab keamanan dalam kontrak Anda. Bahkan jika itu terjadi, Anda hanya mendapat pesanan yang saling bertentangan dari manajemen.

Saya pikir satu-satunya saat Anda mengajukan diri ke litigasi potensial adalah jika Anda secara sadar merusak produk sendiri, membuat bom waktu Anda sendiri, telur paskah, dll.

Pada kebanyakan kasus, perusahaan memiliki perangkat lunak, sehingga mereka dapat menikmati keuntungan, tetapi itu juga berarti mereka dapat mengambil risiko juga, bukan pengembang individu.

Secara pribadi, saya akan memastikan manajemen mengetahui masalah dengan fitur keamanan ini, sehingga didokumentasikan sebelumnya, dan terus melakukan pekerjaan saya.

Yang sedang berkata, berkonsultasi dengan pengacara, yada-yada-yada.


34

Apa pun yang terjadi: Jangan pernah menulis kode seperti itu tanpa memiliki email atau bukti lain yang menunjukkan dengan jelas bahwa Anda hanya mengikuti instruksi dari majikan Anda.


6
Dan cetak / kirim ke akun luar juga.
Bill Leeper

7
Dikenal sebagai CYA (Cover A ..). Saya pernah mengirim email salinan instruksi yang tidak menyenangkan ke akun email pribadi saya, dan mengirimkannya ke divisi hukum perusahaan (Kami punya tim etika jadi ini rahasia). Tergantung pada berapa banyak panas yang Anda siapkan untuk mengambil, dan berapa banyak "perlindungan" yang Anda butuhkan. Orang lain yang layak dipikirkan adalah Pemasaran, Dewan (paling bertanggung jawab), Pemilik / pemegang saham. Tanyakan "Siapa yang paling longgar"? Ini akan membatasi karir, karena Anda telah membuang banyak waktu orang penting, atau membuat Anda bos terlihat buruk.
mattnz

+1 - tutupi punggung Anda. Dokumentasikan keberatan dan alasan Anda mengapa Anda pikir ini buruk. Dokumentasikan tanggapan manajer Anda. Cetak ini dan arsipkan dengan hati-hati seandainya panas kembali ke Anda.
Qwerky

CYA tapi jangan pasif agresif tentang hal itu. Pastikan Anda menyuarakan keberatan KEMBALI ke perusahaan Anda dan simpan email itu juga.
Doug T.

Sederhana dan sederhana - Saya suka jawaban ini. Ini pasti akan membantu dengan tanggung jawab secara hukum, namun, Anda masih harus membuat keputusan etis sendiri.
stringo0

6

Dari sudut pandang hukum, konsultasikan dengan pengacara. Saya bukan satu, kami juga tidak memiliki petunjuk apa yurisdiksi atau hukum yang Anda jalani yang dapat membantu menjelaskan beberapa hal. Tetapi bagaimanapun juga berkonsultasi dengan pengacara, apakah Anda akan mempercayai situs T&J internet dengan masa depan pribadi, profesional, dan keuangan Anda.

Nasihat bisnis umum adalah memastikan Anda membuat reservasi Anda secara tertulis dan perintah langsung atasan Anda untuk terus mengingat masalah keamanan secara tertulis. Jika ada hal-hal pergi ke selatan dan tekan kipas Anda akan memiliki itu untuk jatuh kembali.

Cara lain untuk mengatasinya adalah dengan melihat lebih dalam persyaratan - Anda telah membagikan rencana, bukan masalah yang sedang Anda pecahkan. Ada lebih dari satu cara untuk menguliti kucing, atau menangani persyaratan pencarian kata sandi.


3

Saya tidak akan khawatir tentang hal itu - tidak seperti Anda dengan jahat memutuskan sendiri untuk memasukkan fitur tidak aman dan mengeksploitasinya sendiri nanti, atau hanya memasukkannya karena Anda lalai. Perusahaan menginginkan ini, seseorang telah memutuskan pertukaran antara waktu pengembangan dan harapan pengguna dapat diterima (seperti biasa) dan karenanya Anda harus melanjutkannya. Jika Anda benar-benar khawatir tentang serangan balik, kirimkan surel kepada atasan Anda dan simpan jawabannya. Setelah Anda selesai melakukannya, sebagai karyawan, Anda dilindungi.

Kadang-kadang ada alasan mengapa hal ini dapat diterima - misalnya, saya tahu beberapa solusi kritis yang menyimpan kata sandi teks biasa, tetapi sisa sistem diamankan sehingga ini tidak menjadi masalah. Sistem ini pada jaringan yang terpisah misalnya. Jika Anda tidak tahu sisa ceritanya (situasi umum di sebagian besar perusahaan) maka Anda dapat berharap bahwa orang lain telah mempertimbangkan hal ini. Demikian pula, jika Anda memiliki email itu dari bos Anda, Anda dapat berharap bahwa dia tahu apa yang dia lakukan.

Secara kebetulan ... apakah ini produk yang saya (sebagai konsumen) akan gunakan? Jika demikian .. apa itu, jadi saya bisa menghindarinya? :)


1

Apakah kita menyadari bahwa banyak bug ditambahkan oleh pengembang yang tidak membahayakan pelanggan selama operasi langsung ke aset yang sama hebatnya. Kami tidak berpikir mereka disengaja tetapi masih merupakan hasil dari beberapa pekerjaan nyata kami dan masih belum tepat sasaran. Jadi contoh yang Anda buat bukanlah kasus yang terisolasi, di mana keputusan pengembang (atau atasan) memang memengaruhi klien.

Inilah yang saya sarankan:

  1. Pertama, dengan segala cara - itu adalah perusahaan yang mengirimkan perangkat lunak ke perusahaan lain. Seorang individu tidak diberikan kredit langsung (melebihi tepuk tangan di dalam tim dan gaji paling banyak) dan kepemilikan pekerjaan. Jadi sementara ini bukan hal yang baik sebagai bagian dari pengiriman kami, tetapi Anda bukan penjahat di sini - selama keputusan bukan milik Anda.

  2. Sebagai seorang programmer profesional - Anda akan dengan jelas menunjukkan keterbatasan kode dan bahaya yang terlibat dalam cara memelihara sesuatu sebagai bagian dari file README atau dokumentasi yang terlibat. Jika ada dokumen persyaratan - laporan uji yang disarankan, dll. Harus dengan jelas menyebutkan batasannya.

  3. Untuk membuat pengambil keputusan sejati bertanggung jawab - saya akan meminta yang lebih tinggi untuk mengonfirmasi pemikiran mereka dalam email dari dokumen tersebut.

  4. Timbang risikonya dengan benar. Perangkat lunak kartu data saya memang menyimpan kata sandi dalam teks paket tetapi itu tidak penting. Tetapi hal yang sama tidak dapat diterima jika saya menyimpan kata sandi bank atau jika itu akses ke database atau server. Jadi berdasarkan risiko nyata, Anda harus mengeskalasi masalah menjadi lebih tinggi sebanyak mungkin.


1

Kecuali jika Anda melakukan pekerjaan Anda dengan sengaja merusak, ada sedikit kerugian hukum untuk melakukan tugas yang diminta dari Anda. Anda akan memiliki kontrak kerja yang akan menyatakan kewajiban Anda, Anda dapat berkonsultasi dengan pengacara mengenai masalah teknis. Dapatkan persetujuan tertulis dari keputusan desain kata sandi plaintext jika Anda benar-benar merasa terbuka.

Saya tidak akan mengungkapkan perangkat lunak mana itu sampai saya yakin fitur ini membuatnya dalam rilis final. Saya masih berharap kami dapat memberi tahu pelanggan dengan cara yang menurut saya dapat diterima.

Yang sedikit lebih mengkhawatirkan adalah kutipan Anda tentang 'menginformasikan pelanggan'. Jika Anda merusak kedudukan, reputasi, dll. (Klausa tentang mana yang akan ada dalam kontrak Anda), maka perusahaan Anda dapat menuntut Anda - dan pembelaan 'pelapor' mungkin tidak membantu Anda ketika Anda memerlukan referensi atau pekerjaan lain.

Jika Anda tidak puas dengan implikasi dari lubang keamanan maka gosok resume Anda dan lanjutkan, tetapi jika itu bukan keputusan Anda dan bukan perusahaan Anda, saya tidak dapat melihat mengapa ini akan 'disalahkan' (secara hukum) pada Anda .


1
Terima kasih atas jawaban anda. Saya menyatakan buruk dalam komentar saya. Saya tidak akan senang dengan keputusan khusus ini, tetapi itu tidak membuat saya marah terhadap perusahaan atau siapa pun. Mempublikasikannya di situs tanya jawab tentu saja merupakan ide yang buruk. Ini akan menjadi iklan negatif DAN sangat sedikit kesempatan untuk membantu siapa pun.
Antoine

Bagus bahwa ada forum seperti ini untuk Anda curahkan - Saya harap semuanya berjalan baik.
amelvin

1

Perusahaan Anda seharusnya mengambil bentuk asuransi ganti rugi profesional ketika mereka mempekerjakan Anda. Ini harus memberikan perlindungan hukum yang memadai untuk semua karyawannya dalam kasus apapun beres dengan perangkat lunak, atau penyalahgunaan perangkat lunak atau kelemahan yang ditemukan dalam perangkat lunak (seperti password terenkripsi).

Sebagai karyawan Anda seharusnya melakukan apa yang mereka minta, dan mereka seharusnya melakukan apa yang diinginkan klien, selama tidak ada pihak yang melanggar hukum, tidak ada masalah, tetapi jika Anda melakukan apa yang diinginkan perusahaan, dan kemudian ditemukan bukan apa yang diinginkan / diminta klien, maka itu adalah di antara mereka, dan asuransi ganti rugi profesional harus melindungi Anda dari kesalahan / pertanggungjawaban pribadi.

IANAL, tetapi saya akan mengambil ini dengan tim hukum perusahaan, selain memeriksa dengan pengacara Anda sendiri.

PS, jika Anda benar-benar takut dengan ini, simpan semua email yang relevan dalam bentuk elektronik & cetak di suatu tempat di luar situs jika memungkinkan.


1

Saatnya untuk pekerjaan baru. Lupakan penerapan ini. Saatnya bergerak. Jika mereka rela begitu angkuh dan licik dengan ini, mereka juga tidak akan takut melempar Anda ke bawah bus.

Selain itu, jangan takut begitu Anda pergi untuk menghubungi secara anonim salah satu dari banyak grup yang menunjukkan celah keamanan pada perangkat lunak orang. Ini adalah bencana yang menunggu untuk terjadi. Sama sekali tidak ada alasan kuat untuk menyimpan ini. Apakah bos Anda memberi Anda alasan? Apakah mereka ingin masuk sebagai pengguna? Apakah mereka ingin membuatnya lebih mudah untuk mengambil kata sandi? Kecuali jika Anda mendapatkan jawaban untuk salah satu di atas yang dapat Anda atasi dengan lebih aman, maka inilah saatnya untuk melanjutkan. Ketika Anda pergi, akan lebih baik untuk tidak memberi tahu mereka alasannya.


Anda menyadari bahwa bahkan Google menyimpan kata sandi dalam teks biasa, bukan? Jika Anda adalah administrator situs, Anda dapat melihat kata sandi akun.
apscience

1
Um, kurasa tidak. Anda tidak menyimpan kata sandi. Anda melakukan hash satu arah yang tidak dapat dibalik dan menyimpannya. Itulah cara standar untuk melakukannya. Bahkan peretasan terbaru di mana akun dikompromikan melakukannya dengan cara itu. Masalah utama ada jika seseorang mendapat hash dan tahu bagaimana mereka dihasilkan mereka memukulnya dengan kamus. Tapi TIDAK, TIDAK, Anda tidak pernah, tidak pernah, tidak pernah, tidak pernah menyimpan kata sandi itu sendiri bahkan dienkripsi. Hanya meminta masalah dengan yang itu. Ingin tahu lebih banyak. Buka di sini: owasp.org/index.php/Main_Page
Bill Leeper

Saya cukup yakin google melakukannya. Jika Anda mengelola aplikasi, Anda dapat melihat semua kata sandi pengguna Anda. Lihat google.com/support/forum/p/Google%20Apps/… , jawab # 4.
apscience

1
RTFA. Maaf, katanya ANDA bisa masuk sebagai pengguna. Ini adalah metode di mana pengguna dengan hak istimewa tertentu dapat menyamar sebagai pengguna lain. Google tidak pernah memberi Anda kata sandi orang lain. Anda masuk dengan kredensial Anda sendiri dan kemudian menyamar sebagai pengguna lain. Ini sangat umum dan merupakan salah satu solusi untuk komentar asli saya di mana bos mungkin ingin masuk sebagai pengguna tertentu.
Bill Leeper

0

apa yang dapat Anda lakukan untuk mengikuti arahan untuk menyimpan kata sandi dalam format yang dapat dipulihkan namun tetap tidak mungkin untuk diambil jika Anda memiliki akses penuh ke program ini menggunakan enkripsi asimetris

Anda mengenkripsi kunci (asin seperti biasa) dengan kunci publik yang disimpan dalam biner

dan ketika kata sandi diperlukan dalam teks biasa, manusia perlu menyediakan kunci pribadi yang jika tidak disimpan jauh dari server


Tergantung pada alasan permintaan, ini mungkin tidak mendekati memuaskan para atasan OP.
CVn

0

Secara pribadi, saya belum pernah mendengar tentang insinyur perangkat lunak, tanpa klausul dalam kontrak atau perjanjian formal lainnya, yang secara hukum bertanggung jawab atas masalah keamanan dalam produk yang mereka kerjakan. Dari apa yang saya baca tentang hukum dan etika dalam rekayasa perangkat lunak, persyaratan keamanan untuk suatu sistem ditentukan oleh spesifikasi persyaratan, yang juga merujuk pada persyaratan hukum, industri, atau perusahaan. Saat membangun sistem, kegagalan untuk memenuhi persyaratan keamanan diperlakukan sebagai kegagalan untuk menyelesaikan persyaratan kontrak karena sistem tidak dibangun seperti yang ditentukan. Bagaimana peristiwa spesifik terungkap tergantung pada kontrak antara insinyur dan majikan dan majikan dan pelanggan.

Hukum juga tidak memberi tahu Anda apa yang harus Anda lakukan, tetapi apa yang bisa / tidak bisa Anda lakukan. Anda tidak menyebutkan industri apa yang Anda ikuti, tetapi beberapa memang memiliki undang-undang, peraturan, dan aturan bagaimana menangani jenis data tertentu - apa yang harus dienkripsi, tingkat enkripsi minimum, persyaratan untuk mengelola / mengendalikan akses, Dan seterusnya. Jika area Anda (negara, negara bagian) tidak memiliki aturan tentang keamanan, industri Anda tidak memiliki aturan tentang keamanan, dan persyaratan perangkat lunak tidak menyebut persyaratan atau standar keamanan, mungkin itu lebih merupakan masalah etika daripada masalah hukum.

Ketika datang ke masalah etika dalam pengembangan perangkat lunak, saya berlangganan Kode Etik Rekayasa Perangkat Lunak dan Praktek Profesional . Pada akhirnya, itu panggilan Anda. Namun, saya merasa bahwa menyimpan kata sandi dalam plaintext atau dalam format yang dapat didekripsi adalah tidak etis.


-3

Cukup sesuaikan dengan proses pengembangan proyek Anda: jika fitur ini ditulis dalam dokumen persyaratan, Anda harus mengimplementasikannya.


Hanya mengikuti perintah pak. Saya kira tidak. Programer disewa untuk berpikir, mengajukan pertanyaan, menjadi kreatif. Ini adalah perangkat lunak yang jelek seperti ini yang memberikan nama buruk bagi industri dan membahayakan informasi pribadi kita.
Bill Leeper

Jawaban saya menunjukkan sebaliknya: jika bos Anda bertentangan dengan persyaratan, maka Anda dapat dengan aman melewati bos. Saya ragu bahwa dalam kasus yang diungkapkan, bos akan menerima bahwa perintahnya ditulis dalam persyaratan.
mouviciel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.