Kata sandi VPN tersimpan: siapa yang bisa mendekripsinya dan kapan

Klien VPN yang menampilkan kata sandi terenkripsi di XML-nya hampir tidak memberi tahu Anda apa pun. Teks tersandi hanya menjawab bahwa nilai itu tidak disimpan sebagai teks biasa dalam representasi tersebut. Siapa yang bisa mendekripsinya, dengan kunci apa, dan dalam konteks pengguna mana adalah pertanyaan yang menentukan apakah penyimpanan itu membantu. Jawablah sebelum Anda menyebut berkas itu aman atau tidak aman.

Tetapkan objek apa yang disimpan

Mulailah dari model penyimpanan produk yang terdokumentasi. Klien dapat menyimpan kata sandi yang bisa dipulihkan, token, atau rujukan ke penyimpanan kredensial, dan masing-masing punya paparan berbeda. Nama elemen XML bukanlah desainnya, dan string yang tampak seperti base64 juga bukan bukti enkripsi.

Tanyakan kepada vendor atau administrator komponen mana yang membaca nilai itu saat terhubung.

Lalu identifikasi API perlindungan jika terdokumentasi. Di Windows, CryptProtectData melindungi data dengan kunci yang diturunkan dari kredensial logon pengguna yang mengenkripsi, dan opsi cakupan mesinnya mengubah siapa yang bisa mendekripsi. Itu contoh konkret mengapa cakupan itu penting. Itu bukan bukti bahwa klien VPN tertentu memakai API tersebut.

Pisahkan salinan yang dicuri dari penggunaan saat runtime

Klien yang menyambung kembali tanpa bertanya kepada Anda memerlukan cara yang didukung untuk memulihkan kredensial. Melindungi salinan cadangan tidak menghapus kemampuan itu. Program apa pun yang berjalan dalam konteks pengguna yang tepat mungkin memakai jalur yang sama, karena itu endpoint itu sendiri berada di dalam batas kepercayaan. Izin berkas dan hak istimewa proses mempersempit batas itu; keduanya tidak menghapusnya.

Itulah perbedaan yang biasanya salah dipahami klaim tentang berkas offline. Enkripsi saat diam dapat menghentikan orang yang menyalin satu berkas tanpa akun. Itu tidak menghentikan kode yang berjalan sebagai akun tersebut.

Kedua pernyataan bisa benar sekaligus, dan yang kedua adalah yang penting saat respons insiden.

Baca kontrol akses yang benar-benar berlaku

Periksa ACL berkas dan direktori di atasnya, bukan hanya mode berkas. Di Windows, bandingkan izin efektif profil pengguna dengan izin layanan atau tugas terjadwal klien. Rahasia yang dilindungi untuk satu pengguna tidak otomatis terlindungi dari administrator, dan juga tidak otomatis terbuka kepadanya.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Catat identitas mana yang menjalankan klien, karena identitas itulah subjek dekripsi.

Untuk armada terkelola, kontrol yang relevan mungkin manajemen perangkat, bukan berkasnya. Tanyakan apakah kredensial dititipkan, apakah bisa dicabut dari jarak jauh, dan bagaimana prosesnya saat perangkat hilang.

Rencanakan paparan, bukan menguji dekripsi

Jangan menjalankan alat ekstraksi yang tidak dikenal pada berkas itu untuk membuktikan suatu hal. Alat itu mungkin berhasil, mungkin merusak profil, dan bagaimanapun juga mengubah bukti. Gunakan desain yang terdokumentasi dan penilaian resmi jika verifikasi benar-benar diperlukan.

Jika paparan terbukti, putar kredensial di pemilik identitas.

Menghapus entri tersimpan bukanlah pencabutan. Itu bisa mencegah klien tersebut menawarkan nilainya lagi, dan tidak melakukan apa pun terhadap salinan yang sudah diambil atau sesi yang sudah diotorisasi. Ganti kredensial, akhiri sesi yang bisa diakhiri pemilik, dan catat apa yang diputar dan kapan.

Pertanyaan untuk tinjauan vendor

Tanyakan rahasia apa yang disimpan, komponen mana yang memakainya, kunci pengguna atau mesin mana yang melindunginya, kontrol akses apa yang berlaku untuk penggunaan normal dan cadangan, serta bagaimana kebijakan penyimpanan dan pembatalan jarak jauh ditangani. Kelima jawaban itu menggambarkan desainnya; XML tidak.

Simpan jawaban bersama catatan penerapan agar peninjau berikutnya tidak mengulang latihan.

Kredensial tersimpan adalah pertukaran antara kemudahan dan paparan. Lakukan pertukaran itu dengan sengaja, dan catat siapa yang menyetujuinya.