Apa yang harus dilakukan ketika perusahaan Anda tidak mengenkripsi kata sandi

Latar Belakang

Saya dikontrak untuk membantu perusahaan menjaga server mereka. Saya bekerja pada beberapa proyek PHP kecil tetapi juga melihat masalah kinerja dan baru-baru ini, memindai log untuk peretas.

Orang-orang ini telah menjalankan server mereka untuk beberapa waktu dan memiliki apa yang saya sebut aplikasi warisan pada kaki terakhirnya. Ini menggunakan kutipan ajaib, variabel global (yang memungkinkan $iduntuk ditimpa oleh $_GET['id']), gunakan .htaccess sebagai satu-satunya keamanan mereka dalam beberapa kasus, sebut saja. Sebuah mimpi buruk keamanan dan pemrograman.

Kami telah diretas di masa lalu, sebagian besar dengan suntikan SQL, yang akan menjalankan SLEEP(99999999)perintah dan bertindak sebagai serangan DOS. Untungnya mereka tidak menjalankan "meja bobby kecil",

XKCD: http://xkcd.com/327/

Jadi saya menulis ulang pernyataan SQL mereka yang rentan dari mysql_query()(bukan mysqli) ke transaksi PDO. Saya juga menganalisis kueri untuk SLEEPdan UNION, yang tidak kami gunakan tetapi injeksi. Sejauh ini baik.

Masalah terbaru

Baru-baru ini kami diberi tahu bahwa catatan berubah dalam DB untuk pengguna, seperti alamat email mereka yang mungkin dibuat oleh pengirim spam.

Saya perhatikan kolom mereka tidak memiliki last_modifiedkolom, jadi kami bahkan tidak bisa tahu kapan kolom itu diubah, apalagi oleh siapa. Saya menambahkan kolom itu, tapi itu bukan langkah pertama.

Ketika saya melihat ke tabel ini, saya perhatikan kata sandi tidak asin atau bahkan hash, hanya disimpan sebagai plaintext.

Komunikasi Klien

Bagaimana saya bisa mendekati mereka tentang seluruh situasi, sebagai kontraktor, tanpa menggapai-gapai lengan saya seperti orang gila? Ada saran? Saya sedang memikirkan pendekatan yang tenang,

    MASALAH 1
        Ringkasan
        Mengapa ini menjadi masalah?
        Apa yang bisa terjadi jika ini tidak diperbaiki
        Perbaikan yang disarankan

    MASALAH # 2
        Ringkasan
        Mengapa ini menjadi masalah?
        Apa yang bisa terjadi jika ini tidak diperbaiki
        Perbaikan yang disarankan
        

Pendekatan tenang yang Anda sarankan akan menjadi yang terbaik. Menunjukkan bahwa ketika data ini terpapar, sebagian besar pengguna Anda akan rentan terhadap pencurian identitas karena penggunaan kembali kata sandi. Ini akan menjadi waktu yang cukup baik untuk menunjukkan bahwa ini adalah masalah yang sama yang mempengaruhi Target (dengan asumsi bahwa perusahaan bukan Target). Dan manajer Anda harus cukup reseptif untuk mengubah ini.

Berkenaan dengan legalitas dengan data, saya tidak percaya bahwa nama pengguna / kata sandi dianggap sama dengan Data CC, Informasi Pribadi, dll. Meskipun itu bisa bergantung pada informasi apa pun yang Anda miliki untuk pengguna Anda. Saya bukan pengacara dan aspek-aspek ini akan lebih baik diangkat dalam wahyu Anda dan harus dibawa ke departemen hukum perusahaan Anda untuk menentukan legalitas.

https://en.wikipedia.org/wiki/Information_privacy_law

Dan Anda memiliki XKCD ini untuk membantu Anda juga:

Ini benar-benar tergantung pada audiens di mana Anda mencoba melakukan pendekatan dengan ini. Saya telah bekerja di perusahaan dengan masalah keamanan parah seperti yang Anda nyatakan tetapi mereka menolak untuk mendengarnya sampai saya menunjukkannya kepada mereka.

Salah satu pendekatan, jika memungkinkan, adalah mengumpulkan pada dasarnya apa yang ingin Anda lakukan dan merinci apa yang sudah mungkin terjadi dalam peretasan ini. Jika audiens Anda non teknis, Anda mungkin perlu menunjukkan biaya bisnis yang dapat dikompromikan. Akun yang diretas jelas mengurangi kredibilitas dalam sistem Anda dan nilai pelanggan yang dirasakan dari produk Anda. Belum lagi sistem yang dikompromikan dengan kata sandi teks biasa dan alamat email untuk pengguna dapat menyebabkan efek riak yang serius.

Hal selanjutnya yang harus Anda lakukan, jika memungkinkan, buktikan. Jika Anda dapat menahan sistem ini di lingkungan pengujian, lakukanlah. Kemudian tunjukkan di depan mereka jenis dampak yang dapat Anda miliki pada sistem dari sisi klien aplikasi. Bahkan dengan orang-orang teknologi ini terbukti cukup meyakinkan bagi saya (meskipun mereka biasanya tidak bertindak dalam kasus saya).

Tentu saja, seperti yang Anda katakan, Anda perlu menjelaskan jika ada tindakan apa yang harus diambil dan perkiraan upaya untuk mencapai itu. Ini akan membantu mereka membenarkan biayanya meskipun beberapa tempat tidak peduli. Setidaknya Anda dapat menghapus kesadaran Anda dan bergerak maju mengetahui Anda telah mencoba.

Jika seperti yang Anda katakan Anda telah dikontrak untuk memelihara server mereka, tentunya kontrak ini harus termasuk dalam tugas-tugas uraian pekerjaan seperti memastikan integritas, keamanan dan ketersediaan sistem operasi, perangkat lunak aplikasi dan semua data dll ?! Jika ada petunjuk yang samar-samar bahwa kontrak mengharapkan (dan membuat Anda bertanggung jawab) untuk memastikan server aman maka saya tidak akan membuang waktu menyatukan kasus bisnis dan hanya melakukan pekerjaan yang baik untuk memastikan masalah tersebut diperbaiki (mengambil cadangan sebelum dan sesudah, menjaga riwayat versi kode Anda berubah).

Saya tidak akan mengharapkan perubahan seperti ini untuk mengambil lebih dari nilai kerja pagi dan jika mereka bertanya apa yang telah Anda habiskan waktu Anda bekerja maka Anda dapat membuat jurnal untuk menjelaskan dan membenarkan tindakan Anda. Asalkan Anda bekerja dalam lingkup kontrak Anda, seharusnya tidak ada masalah di sini. Terkadang membuat semua keamanan menjadi gila di depan pembuat keputusan menyebabkan kepanikan atau dalam kasus terburuk menciptakan kesempatan bagi mereka untuk mengatakan mereka tidak peduli dengan masalah-masalah itu jadi jangan memperbaikinya, sementara itu kontrak Anda tetap membuat Anda bertanggung jawab jika terjadi sebuah pelanggaran! Mungkin ini tidak selalu merupakan pendekatan yang paling ramah bisnis, tetapi etika profesional saya tidak akan membiarkan saya meninggalkan kata sandi yang tidak terenkripsi dalam sistem apa pun yang pernah saya pertanggungjawabkan karena hal itu menarik perhatian saya.

Dari pengalaman pribadi saya cenderung menemukan setiap kali saya mulai bekerja untuk majikan atau klien baru, membahas skenario dan harapan di muka dapat menghemat banyak tekanan di pihak Anda, misalnya: jika saya menemukan masalah keamanan yang dapat saya perbaiki apakah Anda senang untuk itu saya untuk melanjutkan dan menyelesaikan pekerjaan ini tanpa datang kepada Anda setiap saat, hanya memberi tahu Anda tentang dugaan pelanggaran / insiden? Mereka hampir selalu akan mengatakan ya untuk ini karena dari sudut pandang mereka, mereka tidak tertarik untuk mengkhawatirkan masalah keamanan atau komputer - itu sebabnya mereka mempekerjakan Anda! Mungkin ini tidak menjawab pertanyaan seperti yang Anda harapkan, tetapi saya harap ini memberi bahan untuk dipikirkan. Semoga Anda mendapatkan yang terbaik dan harap masalah ini diperbaiki!

Tentunya jika mengubah alamat email pelanggan sudah terjadi, dan itu dianggap masalah - maka kemampuan untuk mengubah kata sandi juga menjadi masalah.

Sekarang, jika Anda telah mengamankan DB secukupnya untuk mencegah hal ini terjadi di masa mendatang, maka peluang siapa pun dapat mengedit kata sandi pengguna juga telah diperbaiki dan Anda hanya perlu mempertimbangkan apakah seseorang dapat membaca kata sandi sekarang.

Tentu saja jika mereka bisa, atau jika (dalam hal yang tidak mungkin ) bahwa Anda belum benar-benar mengamankan DB maka pasti mengenkripsi kata sandi harus dilakukan - bagaimana cara melakukannya? Letakkan saja dalam konteks yang sama dengan masalah "memiliki alamat email yang diperbarui". Apakah ini memerlukan aplikasi untuk berubah, dan apakah itu masalah "terlalu sulit" adalah masalah lain yang perlu diangkat bersama mereka. Lihatlah kodenya dan lihat berapa biaya untuk mengubahnya sebelum mengambil perbaikan yang disarankan untuk mereka.