Mengapa char [] lebih disukai daripada String untuk kata sandi?

Dalam Swing, bidang kata sandi memiliki metode getPassword()(pengembalian char[]) alih-alih metode getText()(pengembalian String) biasa . Demikian pula, saya menemukan saran untuk tidak menggunakan Stringkata sandi.

Mengapa Stringmenimbulkan ancaman bagi keamanan ketika menyangkut kata sandi? Rasanya tidak nyaman untuk digunakan char[].

String tidak berubah . Itu berarti setelah Anda membuat String, jika proses lain dapat membuang memori, tidak ada cara (selain dari refleksi ) Anda dapat membuang data sebelum pengumpulan sampah dimulai.

Dengan sebuah array, Anda dapat menghapus data secara eksplisit setelah selesai. Anda dapat menimpa array dengan apa pun yang Anda suka, dan kata sandi tidak akan ada di mana pun dalam sistem, bahkan sebelum pengumpulan sampah.

Jadi ya, ini adalah masalah keamanan - tetapi bahkan menggunakan char[]hanya mengurangi jendela peluang bagi penyerang, dan itu hanya untuk jenis serangan khusus ini.

Seperti disebutkan dalam komentar, ada kemungkinan bahwa array yang dipindahkan oleh pengumpul sampah akan meninggalkan salinan data yang tersesat dalam memori. Saya percaya ini khusus implementasi - pengumpul sampah dapat menghapus semua memori saat berjalan, untuk menghindari hal semacam ini. Bahkan jika itu terjadi, masih ada waktu di mana char[]berisi karakter yang sebenarnya sebagai jendela serangan.

Sementara saran lain di sini tampaknya valid, ada satu alasan bagus lainnya. Dengan polos StringAnda memiliki peluang lebih tinggi untuk secara tidak sengaja mencetak kata sandi ke log , monitor, atau tempat tidak aman lainnya. char[]kurang rentan.

Pertimbangkan ini:

public static void main(String[] args) {
    Object pw = "Password";
    System.out.println("String: " + pw);

    pw = "Password".toCharArray();
    System.out.println("Array: " + pw);
}

Cetakan:

String: Password
Array: [C@5829428e

Mengutip dokumen resmi, panduan Arsitektur Kriptografi Java mengatakan ini tentang kata sandi char[]vs. String(tentang enkripsi berbasis kata sandi, tetapi ini lebih umum tentang kata sandi tentu saja):

Tampaknya logis untuk mengumpulkan dan menyimpan kata sandi dalam objek bertipe java.lang.String. Namun, inilah peringatannya: Objecttipe Stringtidak dapat diubah, yaitu, tidak ada metode yang didefinisikan yang memungkinkan Anda untuk mengubah (menimpa) atau nol konten dari String penggunaan setelah. Fitur ini membuat Stringobjek tidak cocok untuk menyimpan informasi sensitif keamanan seperti kata sandi pengguna. Anda harus selalu mengumpulkan dan menyimpan informasi sensitif keamanan dalam chararray.

Panduan 2-2 dari Panduan Pengkodean Aman untuk Bahasa Pemrograman Java, Versi 4.0 juga mengatakan sesuatu yang serupa (meskipun aslinya dalam konteks logging):

Panduan 2-2: Jangan mencatat informasi yang sangat sensitif

Beberapa informasi, seperti nomor Jaminan Sosial (SSN) dan kata sandi, sangat sensitif. Informasi ini tidak boleh disimpan lebih lama dari yang diperlukan atau di mana pun dapat dilihat, bahkan oleh administrator. Misalnya, itu tidak boleh dikirim ke file log dan keberadaannya tidak dapat dideteksi melalui pencarian. Beberapa data sementara dapat disimpan dalam struktur data yang dapat berubah, seperti array arang, dan dihapus segera setelah digunakan. Membersihkan struktur data telah mengurangi keefektifan sistem runtime Java karena objek dipindahkan dalam memori secara transparan ke pemrogram.

Pedoman ini juga memiliki implikasi untuk implementasi dan penggunaan perpustakaan tingkat rendah yang tidak memiliki pengetahuan semantik tentang data yang mereka hadapi. Sebagai contoh, parsing string string tingkat rendah dapat mencatat teks yang berfungsi. Aplikasi dapat menguraikan SSN dengan perpustakaan. Ini menciptakan situasi di mana SSN tersedia untuk administrator dengan akses ke file log.

Array karakter ( char[]) dapat dihapus setelah digunakan dengan mengatur setiap karakter ke nol dan Strings tidak. Jika seseorang entah bagaimana dapat melihat gambar memori, mereka dapat melihat kata sandi dalam teks biasa jika Strings digunakan, tetapi jika char[]digunakan, setelah membersihkan data dengan 0, kata sandi aman.

Beberapa orang percaya bahwa Anda harus menimpa memori yang digunakan untuk menyimpan kata sandi setelah Anda tidak lagi membutuhkannya. Ini mengurangi waktu jendela seorang penyerang harus membaca kata sandi dari sistem Anda dan sepenuhnya mengabaikan fakta bahwa penyerang sudah membutuhkan akses yang cukup untuk membajak memori JVM untuk melakukan ini. Seorang penyerang dengan akses sebanyak itu dapat menangkap peristiwa utama Anda yang membuat ini sama sekali tidak berguna (AFAIK, jadi tolong perbaiki saya jika saya salah).

Memperbarui

Berkat komentar saya harus memperbarui jawaban saya. Rupanya ada dua kasus di mana ini dapat menambahkan (sangat) peningkatan keamanan kecil karena mengurangi waktu kata sandi bisa mendarat di hard drive. Masih saya pikir itu berlebihan untuk kebanyakan kasus penggunaan.

• Sistem target Anda mungkin tidak dikonfigurasi dengan benar atau Anda harus menganggap itu dan Anda harus paranoid tentang dump inti (dapat valid jika sistem tidak dikelola oleh administrator).
• Perangkat lunak Anda harus terlalu paranoid untuk mencegah kebocoran data dengan penyerang mendapatkan akses ke perangkat keras - menggunakan hal-hal seperti TrueCrypt (dihentikan), VeraCrypt , atau CipherShed .

Jika memungkinkan, menonaktifkan dump inti dan file swap akan menangani kedua masalah. Namun, mereka akan memerlukan hak administrator dan dapat mengurangi fungsionalitas (lebih sedikit memori untuk digunakan) dan menarik RAM dari sistem yang sedang berjalan masih akan menjadi masalah yang valid.

Saya tidak berpikir ini adalah saran yang valid, tapi, setidaknya saya bisa menebak alasannya.

Saya pikir motivasi ingin memastikan bahwa Anda dapat menghapus semua jejak kata sandi di memori segera dan dengan pasti setelah digunakan. Dengan char[]Anda dapat menimpa setiap elemen array dengan kosong atau sesuatu pasti. Anda tidak dapat mengedit nilai internal dengan Stringcara itu.

Tapi itu saja bukan jawaban yang bagus; mengapa tidak memastikan referensi ke char[]atau Stringtidak melarikan diri? Maka tidak ada masalah keamanan. Tetapi masalahnya adalah bahwa Stringobjek dapat intern()diedit secara teori dan tetap hidup di dalam kolam konstan. Saya kira menggunakan char[]melarang kemungkinan ini.

Jawabannya sudah diberikan, tetapi saya ingin berbagi masalah yang saya temukan belakangan ini dengan perpustakaan standar Java. Sementara mereka sangat berhati-hati saat mengganti string kata sandi dengan di char[]mana - mana (yang tentu saja merupakan hal yang baik), data keamanan-kritis lainnya tampaknya diabaikan ketika datang untuk membersihkannya dari memori.

Saya sedang memikirkan misalnya kelas PrivateKey . Pertimbangkan skenario di mana Anda akan memuat kunci RSA pribadi dari file PKCS # 12, menggunakannya untuk melakukan beberapa operasi. Sekarang dalam kasus ini, mengendus kata sandi saja tidak akan banyak membantu Anda selama akses fisik ke file kunci dibatasi dengan benar. Sebagai seorang penyerang, Anda akan jauh lebih baik jika Anda mendapatkan kunci secara langsung daripada kata sandi. Informasi yang diinginkan dapat bocor berlipat ganda, core dumps, sesi debugger atau swap file hanyalah beberapa contoh.

Dan ternyata, tidak ada yang memungkinkan Anda menghapus informasi pribadi dari PrivateKeydari memori, karena tidak ada API yang memungkinkan Anda menghapus byte yang membentuk informasi yang sesuai.

Ini adalah situasi yang buruk, karena makalah ini menjelaskan bagaimana keadaan ini dapat berpotensi dieksploitasi.

Pustaka OpenSSL misalnya menimpa bagian memori kritis sebelum kunci pribadi dibebaskan. Karena Java dikumpulkan dari sampah, kita perlu metode eksplisit untuk menghapus dan membatalkan informasi pribadi untuk kunci Java, yang akan diterapkan segera setelah menggunakan kunci tersebut.

Seperti yang dinyatakan Jon Skeet, tidak ada jalan lain kecuali menggunakan refleksi.

Namun, jika refleksi adalah pilihan bagi Anda, Anda dapat melakukan ini.

public static void main(String[] args) {
    System.out.println("please enter a password");
    // don't actually do this, this is an example only.
    Scanner in = new Scanner(System.in);
    String password = in.nextLine();
    usePassword(password);

    clearString(password);

    System.out.println("password: '" + password + "'");
}

private static void usePassword(String password) {

}

private static void clearString(String password) {
    try {
        Field value = String.class.getDeclaredField("value");
        value.setAccessible(true);
        char[] chars = (char[]) value.get(password);
        Arrays.fill(chars, '*');
    } catch (Exception e) {
        throw new AssertionError(e);
    }
}

saat dijalankan

please enter a password
hello world
password: '***********'

Catatan: jika karakter String [] telah disalin sebagai bagian dari siklus GC, ada kemungkinan salinan sebelumnya ada di suatu tempat di memori.

Salinan lama ini tidak akan muncul di heap dump, tetapi jika Anda memiliki akses langsung ke memori mentah proses, Anda bisa melihatnya. Secara umum Anda harus menghindari siapa pun yang memiliki akses seperti itu.

Ini semua alasannya, kita harus memilih array char [] daripada String untuk kata sandi.

1. Karena String tidak dapat diubah di Jawa, jika Anda menyimpan kata sandi sebagai teks biasa, kata itu akan tersedia dalam memori sampai pengumpul Sampah mengosongkannya, dan karena String digunakan dalam kumpulan String untuk penggunaan kembali, ada kemungkinan yang cukup tinggi bahwa itu akan tetap tersimpan dalam memori untuk waktu yang lama, yang menimbulkan ancaman keamanan.

Karena siapa pun yang memiliki akses ke dump memori dapat menemukan kata sandi dalam teks yang jelas, itu alasan lain Anda harus selalu menggunakan kata sandi terenkripsi daripada teks biasa. Karena String tidak dapat diubah, tidak mungkin konten String dapat diubah karena perubahan apa pun akan menghasilkan String baru, sementara jika Anda menggunakan karakter [] Anda masih dapat mengatur semua elemen sebagai kosong atau nol. Jadi menyimpan kata sandi dalam susunan karakter jelas mengurangi risiko keamanan mencuri kata sandi.

2. Java sendiri merekomendasikan menggunakan metode getPassword () dari JPasswordField yang mengembalikan karakter [], alih-alih metode getText () yang sudah usang yang mengembalikan kata sandi dalam teks yang jelas yang menyatakan alasan keamanan. Adalah baik untuk mengikuti saran dari tim Java dan mematuhi standar daripada menentangnya.

3. Dengan String selalu ada risiko mencetak teks biasa dalam file log atau konsol tetapi jika Anda menggunakan Array Anda tidak akan mencetak konten array, tetapi sebaliknya lokasi memorinya akan dicetak. Meski bukan alasan sebenarnya, itu tetap masuk akal.

String strPassword="Unknown";
char[] charPassword= new char[]{'U','n','k','w','o','n'};
System.out.println("String password: " + strPassword);
System.out.println("Character password: " + charPassword);

String password: Unknown
Character password: [C@110b053

Dirujuk dari blog ini . Saya harap ini membantu.

Sunting: Kembali ke jawaban ini setelah satu tahun penelitian keamanan, saya menyadari itu membuat implikasi yang agak disayangkan bahwa Anda akan benar-benar membandingkan kata sandi plaintext. Tolong jangan. Gunakan hash satu arah yang aman dengan garam dan sejumlah iterasi yang masuk akal . Pertimbangkan untuk menggunakan perpustakaan: hal-hal ini sulit untuk diperbaiki!

Jawaban asli: Bagaimana dengan fakta bahwa String.equals () menggunakan evaluasi hubung singkat , dan karenanya rentan terhadap serangan waktu? Ini mungkin tidak mungkin, tetapi Anda secara teoritis dapat mengatur waktu perbandingan kata sandi untuk menentukan urutan karakter yang benar.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // Quits here if Strings are different lengths.
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // Quits here at first different character.
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

Beberapa lebih banyak sumber daya tentang serangan waktu:

• Pelajaran Dalam Serangan Waktu
• Diskusi tentang serangan timing pada Information Security Stack Exchange
• Dan tentu saja, halaman Timing Attack Wikipedia

Tidak ada yang array char memberi Anda vs String kecuali Anda membersihkannya secara manual setelah digunakan, dan saya belum melihat ada yang benar-benar melakukan itu. Jadi bagi saya preferensi char [] vs String agak berlebihan.

Lihatlah pustaka Spring Security yang _{banyak digunakan di} sini dan tanyakan pada diri Anda - apakah password Spring Security tidak kompeten atau char [] tidak masuk akal. Ketika beberapa peretas jahat mengambil memori dump RAM Anda pastikan ia akan mendapatkan semua kata sandi bahkan jika Anda menggunakan cara canggih untuk menyembunyikannya.

Namun, Java berubah setiap saat, dan beberapa fitur menakutkan seperti Deduplikasi String Java 8 mungkin menginternir objek String tanpa sepengetahuan Anda. Tapi itu percakapan yang berbeda.

String tidak berubah dan tidak dapat diubah setelah mereka dibuat. Membuat kata sandi sebagai string akan meninggalkan referensi menyimpang ke kata sandi pada heap atau pada kumpulan String. Sekarang jika seseorang mengambil tumpukan proses Java dan dengan hati-hati memindai dia mungkin bisa menebak kata sandi. Tentu saja string ini tidak digunakan akan menjadi sampah yang dikumpulkan tetapi itu tergantung pada kapan GC masuk.

Di sisi lain, char [] dapat berubah begitu otentikasi selesai, Anda dapat menimpa mereka dengan karakter seperti semua M atau backslash. Sekarang bahkan jika seseorang mengambil heap dump, dia mungkin tidak bisa mendapatkan kata sandi yang saat ini tidak digunakan. Ini memberi Anda lebih banyak kontrol dalam arti seperti membersihkan konten Objek sendiri vs menunggu GC melakukannya.

String tidak dapat diubah dan pergi ke kumpulan string. Setelah ditulis, tidak dapat ditimpa.

char[] adalah array yang harus Anda timpa setelah menggunakan kata sandi dan inilah yang harus dilakukan:

char[] passw = request.getPassword().toCharArray()
if (comparePasswords(dbPassword, passw) {
 allowUser = true;
 cleanPassword(passw);
 cleanPassword(dbPassword);
 passw=null;
}

private static void cleanPassword (char[] pass) {

Arrays.fill(pass, '0');
}

Satu skenario di mana penyerang bisa menggunakannya adalah crashdump - ketika JVM crash dan menghasilkan dump memori - Anda akan dapat melihat kata sandi.

Itu belum tentu penyerang eksternal jahat. Ini bisa menjadi pengguna dukungan yang memiliki akses ke server untuk keperluan pemantauan. Dia bisa mengintip crashdump dan menemukan kata sandinya.

Jawaban singkat dan langsung adalah karena char[]bisa berubah sementara Stringobjek tidak.

Stringsdi Jawa adalah objek abadi. Itulah sebabnya mereka tidak dapat dimodifikasi setelah dibuat, dan oleh karena itu satu-satunya cara agar isinya dihapus dari memori adalah dengan mengumpulkannya. Itu hanya akan terjadi ketika memori yang dibebaskan oleh objek dapat ditimpa, dan data akan hilang.

Sekarang pengumpulan sampah di Jawa tidak terjadi pada interval yang dijamin. ItuString demikian dapat bertahan dalam memori untuk waktu yang lama, dan jika suatu proses crash selama waktu ini, isi string mungkin berakhir di tempat penyimpanan memori atau log.

Dengan susunan karakter , Anda dapat membaca kata sandi, menyelesaikannya sesegera mungkin, dan kemudian segera mengubah isinya.

String dalam java tidak dapat diubah. Jadi, setiap kali string dibuat, itu akan tetap dalam memori sampai sampah dikumpulkan. Jadi siapa pun yang memiliki akses ke memori dapat membaca nilai string.
Jika nilai string diubah maka akhirnya akan membuat string baru. Jadi nilai asli dan nilai yang dimodifikasi tetap berada di memori sampai sampah dikumpulkan.

Dengan array karakter, isi array dapat dimodifikasi atau dihapus setelah tujuan kata sandi disajikan. Isi asli array tidak akan ditemukan dalam memori setelah dimodifikasi dan bahkan sebelum pengumpulan sampah dimulai.

Karena masalah keamanan, lebih baik menyimpan kata sandi sebagai array karakter.

Dapat diperdebatkan apakah Anda harus menggunakan String atau menggunakan Char [] untuk tujuan ini karena keduanya memiliki kelebihan dan kekurangan. Itu tergantung pada apa yang dibutuhkan pengguna.

Karena String di Java tidak dapat diubah, setiap kali beberapa orang mencoba untuk memanipulasi string Anda, itu menciptakan Obyek baru dan String yang ada tetap tidak terpengaruh. Ini bisa dilihat sebagai keuntungan untuk menyimpan kata sandi sebagai String, tetapi objek tetap ada dalam memori bahkan setelah digunakan. Jadi, jika ada orang yang entah bagaimana mendapatkan lokasi memori objek, orang itu dapat dengan mudah melacak kata sandi Anda yang tersimpan di lokasi itu.

Karakter [] bisa berubah, tetapi ia memiliki keuntungan bahwa setelah penggunaannya, pemrogram dapat secara eksplisit membersihkan array atau mengabaikan nilai. Jadi ketika sudah selesai digunakan itu sudah dibersihkan dan tidak ada yang bisa tahu tentang informasi yang Anda simpan.

Berdasarkan keadaan di atas, orang bisa mendapatkan ide apakah akan pergi dengan String atau pergi dengan Char [] untuk persyaratan mereka.

Tali Kasus:

    String password = "ill stay in StringPool after Death !!!";
    // some long code goes
    // ...Now I want to remove traces of password
    password = null;
    password = "";
    // above attempts wil change value of password
    // but the actual password can be traced from String pool through memory dump, if not garbage collected

Kasus CHAR ARRAY:

    char[] passArray = {'p','a','s','s','w','o','r','d'};
    // some long code goes
    // ...Now I want to remove traces of password
    for (int i=0; i<passArray.length;i++){
        passArray[i] = 'x';
    }
    // Now you ACTUALLY DESTROYED traces of password form memory