Jangan pernah memasukkan kata sandi hard-code ke dalam kode Anda. Hal ini dibahas baru-baru ini di 25 Kesalahan Pemrograman Paling Berbahaya :
Pengkodean keras akun rahasia dan kata sandi ke dalam perangkat lunak Anda sangat mudah -- bagi insinyur balik yang terampil. Jika kata sandinya sama di semua perangkat lunak Anda, maka setiap pelanggan menjadi rentan ketika kata sandi itu pasti diketahui. Dan karena itu sulit dikodekan, sangat sulit untuk memperbaikinya.
Anda harus menyimpan informasi konfigurasi, termasuk kata sandi, dalam file terpisah yang dibaca aplikasi saat dimulai. Itulah satu-satunya cara nyata untuk mencegah kata sandi bocor akibat dekompilasi (jangan pernah mengompilasinya ke dalam biner untuk memulai).
Untuk informasi selengkapnya tentang kesalahan umum ini, Anda dapat membaca artikel CWE-259 . Artikel tersebut berisi definisi yang lebih menyeluruh, contoh, dan banyak informasi lain tentang masalah tersebut.
Di Java, salah satu cara termudah untuk melakukannya adalah dengan menggunakan kelas Preferences. Ini dirancang untuk menyimpan semua jenis pengaturan program, beberapa di antaranya dapat menyertakan nama pengguna dan kata sandi.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
// your code here
}
Dalam kode di atas, Anda dapat memanggil setCredentials metode setelah menampilkan dialog menanyakan nama pengguna dan kata sandi. Saat Anda perlu terhubung ke database, Anda cukup menggunakan getUsername dan getPassword metode untuk mengambil nilai yang disimpan. Kredensial login tidak akan dikodekan ke dalam biner Anda, jadi dekompilasi tidak akan menimbulkan risiko keamanan.
Catatan Penting: File preferensi hanyalah file XML teks biasa. Pastikan Anda mengambil langkah-langkah yang tepat untuk mencegah pengguna yang tidak sah melihat file mentah (izin UNIX, izin Windows, dan lain-lain). Di Linux, setidaknya, ini bukan masalah, karena memanggil Preferences.userNodeForPackage akan membuat file XML di direktori home pengguna saat ini, yang tetap tidak dapat dibaca oleh pengguna lain. Di Windows, situasinya mungkin berbeda.
Catatan Penting Lainnya: Ada banyak diskusi dalam komentar jawaban ini dan lainnya tentang apa arsitektur yang benar untuk situasi ini. Pertanyaan awal tidak benar-benar menyebutkan konteks penggunaan aplikasi, jadi saya akan berbicara tentang dua situasi yang dapat saya pikirkan. Yang pertama adalah kasus di mana orang yang menggunakan program sudah mengetahui (dan berwenang untuk mengetahui) kredensial basis data. Yang kedua adalah kasus di mana Anda, pengembang, mencoba untuk merahasiakan kredensial basis data dari orang yang menggunakan program.
Kasus Pertama:Pengguna berwenang untuk mengetahui kredensial login database
Dalam hal ini, solusi yang saya sebutkan di atas akan berhasil. Java Preference class akan menyimpan nama pengguna dan kata sandi dalam teks biasa, tetapi file preferensi hanya dapat dibaca oleh pengguna yang berwenang. Pengguna cukup membuka file XML preferensi dan membaca kredensial login, tetapi itu bukan risiko keamanan karena pengguna sudah mengetahui kredensialnya sejak awal.
Kasus Kedua:Mencoba menyembunyikan kredensial masuk dari pengguna
Ini adalah kasus yang lebih rumit:pengguna seharusnya tidak mengetahui kredensial login tetapi masih membutuhkan akses ke database. Dalam hal ini, pengguna yang menjalankan aplikasi memiliki akses langsung ke database, yang berarti program perlu mengetahui kredensial login sebelumnya. Solusi yang saya sebutkan di atas tidak sesuai untuk kasus ini. Anda dapat menyimpan kredensial login database dalam file preferensi, tetapi pengguna akan dapat membaca file itu, karena mereka akan menjadi pemiliknya. Faktanya, tidak ada cara yang baik untuk menggunakan kasing ini dengan cara yang aman.
Kasus yang Benar:Menggunakan arsitektur multi-tingkat
Cara yang benar untuk melakukannya adalah dengan memiliki lapisan tengah, di antara server database dan aplikasi klien Anda, yang mengotentikasi pengguna individu dan memungkinkan serangkaian operasi terbatas untuk dilakukan. Setiap pengguna akan memiliki kredensial login mereka sendiri, tetapi tidak untuk server database. Kredensial akan memungkinkan akses ke lapisan tengah (tingkat logika bisnis) dan akan berbeda untuk setiap pengguna.
Setiap pengguna akan memiliki nama pengguna dan kata sandi mereka sendiri, yang dapat disimpan secara lokal di file preferensi tanpa risiko keamanan apa pun. Ini disebut arsitektur tiga tingkat (tingkatan menjadi server database Anda, server logika bisnis, dan aplikasi klien). Ini lebih rumit, tetapi ini benar-benar cara paling aman untuk melakukan hal semacam ini.
Urutan operasi dasar adalah:
- Klien mengautentikasi dengan tingkat logika bisnis menggunakan nama pengguna/sandi pribadi pengguna. Nama pengguna dan kata sandi diketahui oleh pengguna dan tidak terkait dengan kredensial login database dengan cara apa pun.
- Jika otentikasi berhasil, klien membuat permintaan ke tingkat logika bisnis meminta beberapa informasi dari database. Misalnya, inventaris produk. Perhatikan bahwa permintaan klien bukanlah kueri SQL; itu adalah panggilan prosedur jarak jauh seperti
getInventoryList. - Tingkat logika bisnis terhubung ke database dan mengambil informasi yang diminta. Tingkat logika bisnis bertanggung jawab untuk membentuk kueri SQL yang aman berdasarkan permintaan pengguna. Parameter apa pun pada kueri SQL harus dibersihkan untuk mencegah serangan injeksi SQL.
- Tingkat logika bisnis mengirimkan daftar inventaris kembali ke aplikasi klien.
- Klien menampilkan daftar inventaris kepada pengguna.
Perhatikan bahwa dalam keseluruhan proses, aplikasi klien tidak pernah terhubung langsung ke database . Tingkat logika bisnis menerima permintaan dari pengguna yang diautentikasi, memproses permintaan klien untuk daftar inventaris, dan baru kemudian mengeksekusi kueri SQL.
