Jangan pernah memasukkan kata sandi ke dalam kode Anda. Hal ini baru-baru ini diangkat dalam 25 Kesalahan Pemrograman Paling Berbahaya Teratas :
Melakukan hard-coding akun rahasia dan kata sandi ke dalam perangkat lunak Anda sangat nyaman - untuk insinyur yang terampil. Jika kata sandi sama di semua perangkat lunak Anda, maka setiap pelanggan menjadi rentan ketika kata sandi itu pasti diketahui. Dan karena ini memiliki kode keras, sangat sulit untuk memperbaikinya.
Anda harus menyimpan informasi konfigurasi, termasuk sandi, dalam file terpisah yang dibaca aplikasi saat dijalankan. Itu adalah satu-satunya cara nyata untuk mencegah kata sandi bocor akibat dekompilasi (jangan pernah mengkompilasinya 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 Preferensi. 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);
}
}
Pada kode di atas, Anda dapat memanggil setCredentialsmetode tersebut setelah menampilkan dialog askign untuk nama pengguna dan kata sandi. Saat Anda perlu menyambungkan ke database, Anda cukup menggunakan metode getUsernamedan getPassworduntuk mengambil nilai yang disimpan. Kredensial login tidak akan di-hardcode 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 sebagainya). Di Linux, setidaknya, ini bukan masalah, karena pemanggilan Preferences.userNodeForPackageakan membuat file XML di direktori home pengguna saat ini, yang toh tidak bisa dibaca oleh pengguna lain. Di Windows, situasinya mungkin berbeda.
Lebih Banyak Catatan Penting: Ada banyak diskusi di komentar jawaban ini dan lainnya tentang apa arsitektur yang benar untuk situasi ini. Pertanyaan asli tidak benar-benar menyebutkan konteks di mana aplikasi tersebut digunakan, jadi saya akan berbicara tentang dua situasi yang dapat saya pikirkan. Yang pertama adalah kasus di mana orang yang menggunakan program sudah mengetahui (dan diberi wewenang untuk mengetahui) kredensial database. Yang kedua adalah kasus di mana Anda, pengembang, mencoba merahasiakan kredensial database dari orang yang menggunakan program.
Kasus Pertama: Pengguna diberi wewenang untuk mengetahui kredensial login database
Dalam hal ini, solusi yang saya sebutkan di atas akan berfungsi. Kelas Java Preferenceakan menyimpan nama pengguna dan kata sandi dalam teks biasa, tetapi file preferensi hanya akan dapat dibaca oleh pengguna yang berwenang. Pengguna cukup membuka file XML preferensi dan membaca kredensial login, tetapi itu bukan risiko keamanan karena pengguna tahu kredensial tersebut sejak awal.
Kasus Kedua: Mencoba menyembunyikan kredensial login 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 tersebut 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 mengautentikasi 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. Ini disebut arsitektur tiga tingkat (tingkatannya adalah server database Anda, server logika bisnis, dan aplikasi klien). Ini lebih kompleks, tetapi ini adalah cara paling aman untuk melakukan hal semacam ini.
Urutan operasi dasar adalah:
- Klien mengautentikasi dengan tingkat logika bisnis menggunakan nama pengguna / kata 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 di seluruh 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 hanya kemudian menjalankan kueri SQL.