Daftar Periksa Penyimpanan Aman Kotlin untuk Token, Kunci, dan PII

Apa yang ingin Anda lindungi (dalam istilah sederhana)

Penyimpanan aman dalam aplikasi bisnis berarti satu hal: jika seseorang mendapatkan ponsel (atau file aplikasi Anda), mereka tetap tidak boleh bisa membaca atau menggunakan kembali apa yang Anda simpan. Itu mencakup data yang diam (di disk) dan juga kebocoran rahasia melalui backup, log, laporan crash, atau alat debug.

Satu tes mental sederhana: apa yang bisa dilakukan orang asing jika mereka membuka folder penyimpanan aplikasi Anda? Di banyak aplikasi, item paling berharga bukan foto atau pengaturan. Mereka adalah string kecil yang membuka akses.

Penyimpanan di perangkat sering kali berisi session token (supaya pengguna tetap masuk), refresh token, API key, kunci enkripsi, data pribadi (PII) seperti nama dan email, dan catatan bisnis yang di-cache untuk penggunaan offline (pesanan, tiket, catatan pelanggan).

Berikut adalah mode kegagalan dunia nyata yang umum:

• Perangkat hilang atau dicuri diperiksa, dan token disalin untuk berpura-pura menjadi pengguna.\n- Malware atau aplikasi "pembantu" membaca file lokal pada perangkat yang di-root atau lewat trik aksesibilitas.\n- Backup otomatis memindahkan data aplikasi ke tempat yang tidak Anda rencanakan.\n- Build debug mencatat token, menulisnya ke laporan crash, atau menonaktifkan pemeriksaan keamanan.

Itulah mengapa "cukup simpan di SharedPreferences" tidak cukup untuk apa pun yang memberi akses (token) atau bisa merugikan pengguna dan perusahaan Anda (PII). SharedPreferences biasa seperti menulis rahasia di kertas tempel di dalam aplikasi: nyaman, dan mudah dibaca jika seseorang mendapat akses.

Titik awal yang paling berguna adalah memberi nama setiap item yang disimpan dan ajukan dua pertanyaan: apakah itu membuka sesuatu, dan apakah itu bermasalah jika menjadi publik? Sisanya (Keystore, encrypted preferences, encrypted database) mengikuti dari situ.

Klasifikasikan data Anda: token, kunci, dan PII

Penyimpanan aman jadi lebih mudah saat Anda berhenti memperlakukan semua "data sensitif" sama. Mulailah dengan mendaftar apa yang aplikasi simpan dan apa yang terjadi jika bocor.

Token tidak sama dengan password. Access token dan refresh token dimaksudkan untuk disimpan agar pengguna tetap masuk, tetapi mereka tetap rahasia bernilai tinggi. Password sebaiknya tidak disimpan sama sekali. Jika perlu login, simpan hanya yang diperlukan untuk menjaga sesi (biasanya token) dan andalkan server untuk pemeriksaan password.

Kunci adalah kelas yang berbeda. API key, kunci tanda tangan, dan kunci enkripsi bisa membuka sistem secara keseluruhan, bukan hanya satu akun pengguna. Jika seseorang mengekstraknya dari perangkat, mereka bisa otomatisasi penyalahgunaan dalam skala besar. Aturan bagus: jika suatu nilai bisa digunakan di luar aplikasi untuk berpura-pura menjadi aplikasi Anda atau mendekripsi data, anggap itu berisiko lebih tinggi daripada token pengguna.

PII adalah apa pun yang bisa mengidentifikasi seseorang: email, telepon, alamat rumah, catatan pelanggan, identitas pemerintahan, data kesehatan. Bahkan field yang terlihat tidak berbahaya menjadi sensitif bila digabungkan.

Sistem pelabelan cepat yang bekerja dalam praktik:

• Rahasia sesi: access token, refresh token, cookie sesi
• Rahasia aplikasi: API key, kunci tanda tangan, kunci enkripsi (sebisa mungkin hindari menaruh ini di perangkat)
• Data pengguna (PII): detail profil, identifier, dokumen, info medis atau finansial
• ID perangkat dan analitik: advertising ID, device ID, install ID (tetap sensitif menurut banyak kebijakan)

Android Keystore: kapan menggunakannya

Android Keystore terbaik saat Anda perlu melindungi rahasia yang tidak boleh keluar dari perangkat dalam bentuk plaintext. Ini adalah brankas untuk kunci kriptografi, bukan database untuk data Anda.

Kegunaannya: menghasilkan dan menyimpan kunci yang digunakan untuk enkripsi, dekripsi, penandatanganan, atau verifikasi. Anda biasanya mengenkripsi token atau data offline di tempat lain, dan kunci Keystore adalah apa yang membukanya.

Kunci berbasis perangkat keras: apa artinya sebenarnya

Di banyak perangkat, kunci Keystore bisa hardware-backed. Itu berarti operasi kunci terjadi di lingkungan terlindungi dan material kunci tidak bisa diekstrak. Ini menurunkan risiko dari malware yang bisa membaca file aplikasi.

Hardware-backed tidak dijamin ada di setiap perangkat, dan perilakunya bervariasi menurut model dan versi Android. Bangunlah seolah-olah operasi kunci bisa gagal.

Gerbang autentikasi pengguna

Keystore dapat mengharuskan kehadiran pengguna sebelum kunci bisa digunakan. Begitulah cara Anda mengikat akses ke biometrik atau kredensial perangkat. Misalnya, Anda bisa mengenkripsi token ekspor dan hanya mendekripsinya setelah pengguna mengonfirmasi dengan sidik jari atau PIN.

Keystore cocok saat Anda ingin kunci yang tidak dapat diekspor, saat Anda ingin persetujuan biometrik atau kredensial perangkat untuk tindakan sensitif, dan saat Anda menginginkan rahasia per-perangkat yang tidak boleh sinkron atau ikut backup.

Rencanakan jebakan: kunci bisa diinvalidasi setelah perubahan layar kunci, perubahan biometrik, atau kejadian keamanan. Harapkan kegagalan dan buat fallback yang bersih: deteksi kunci invalid, hapus blob terenkripsi, dan minta pengguna untuk masuk kembali.

EncryptedSharedPreferences: kapan cukup

EncryptedSharedPreferences adalah default yang baik untuk sejumlah kecil rahasia dalam bentuk key-value. Ini adalah "SharedPreferences, tapi terenkripsi" sehingga seseorang tidak bisa sekadar membuka file dan membaca nilainya.

Di balik layar, ia menggunakan master key untuk mengenkripsi dan mendekripsi nilai. Master key itu dilindungi oleh Android Keystore, sehingga aplikasi Anda tidak menyimpan kunci enkripsi mentah dalam bentuk plaintext.

Biasanya cukup untuk beberapa item kecil yang sering dibaca, seperti access dan refresh token, session ID, device ID, flag lingkungan, atau potongan state kecil seperti waktu sinkron terakhir. Juga aman untuk potongan kecil data pengguna jika Anda benar-benar harus menyimpannya, tetapi ini tidak seharusnya menjadi tempat pembuangan PII.

Ini tidak cocok untuk apa pun yang besar atau terstruktur. Jika Anda memerlukan daftar offline, pencarian, atau query berdasarkan field (pelanggan, tiket, pesanan), EncryptedSharedPreferences menjadi lambat dan canggung. Di titik itu Anda ingin database terenkripsi.

Aturan sederhana: jika Anda bisa mencantumkan setiap kunci yang disimpan di satu layar, EncryptedSharedPreferences mungkin baik. Jika Anda butuh baris dan query, pindah ke yang lain.

Enkripsi database: kapan Anda membutuhkannya

Enkripsi database penting ketika Anda menyimpan lebih dari sekadar pengaturan kecil atau satu token. Jika aplikasi Anda menyimpan data bisnis di perangkat, anggap itu bisa diekstrak dari ponsel yang hilang kecuali Anda melindunginya.

Database masuk akal ketika Anda perlu akses offline ke record, caching lokal untuk performa, jejak audit/riwayat, atau catatan panjang dan lampiran.

Dua pendekatan enkripsi yang umum

Enkripsi seluruh database (sering seperti SQLCipher) mengenkripsi seluruh file saat diam. Aplikasi Anda membukanya dengan sebuah kunci. Ini mudah dipahami karena Anda tidak perlu mengingat kolom mana yang dilindungi.

Enkripsi di lapisan aplikasi per-field hanya mengenkripsi field tertentu sebelum menulis, lalu mendekripsi setelah membaca. Ini bisa bekerja jika sebagian besar record tidak sensitif, atau jika Anda mencoba mempertahankan setup database tanpa mengubah format file.

Tradeoff: kerahasiaan vs pencarian dan pengurutan

Enkripsi penuh menyembunyikan semuanya di disk, tetapi setelah database dibuka, aplikasi Anda bisa melakukan query seperti biasa.

Enkripsi field melindungi kolom tertentu, tetapi Anda kehilangan kemampuan pencarian dan pengurutan mudah pada nilai terenkripsi. Mengurutkan berdasarkan nama belakang terenkripsi tidak bekerja andal, dan pencarian menjadi enten "cari setelah dekripsi" (lambat) atau "simpan indeks tambahan" (lebih kompleks dan potensi bocor).

Dasar manajemen kunci

Kunci database tidak boleh di-hardcode atau dikirim bersama aplikasi. Pola umum adalah menghasilkan kunci database acak, lalu menyimpannya dalam bentuk terbungkus (terenkripsi) menggunakan kunci yang disimpan di Android Keystore. Saat logout, Anda bisa menghapus kunci yang dibungkus dan menganggap database lokal dapat dibuang, atau menyimpannya jika aplikasi harus bekerja offline lintas sesi.

Cara memilih: perbandingan praktis

Anda tidak memilih "yang paling aman" secara umum. Anda memilih opsi paling aman yang sesuai dengan bagaimana aplikasi Anda menggunakan data.

Pertanyaan yang benar-benar menentukan pilihan yang tepat:

• Seberapa sering data dibaca (setiap peluncuran atau jarang)?
• Berapa banyak datanya (beberapa byte atau ribuan record)?
• Apa yang terjadi jika bocor (menyebalkan, berbiaya, harus dilaporkan secara hukum)?
• Apakah Anda perlu akses offline, pencarian, atau pengurutan?\n- Apakah Anda punya persyaratan kepatuhan (retensi, audit, aturan enkripsi)?

Pemetaannya yang dapat digunakan:

• Token (OAuth access dan refresh token) biasanya cocok di EncryptedSharedPreferences karena kecil dan sering dibaca.
• Material kunci sebaiknya tinggal di Android Keystore kapan pun memungkinkan untuk mengurangi kemungkinan disalin dari perangkat.
• PII dan data bisnis offline biasanya membutuhkan enkripsi database begitu Anda menyimpan lebih dari beberapa field atau perlu daftar dan penyaringan offline.

Data campuran normal di aplikasi bisnis. Pola praktis adalah menghasilkan key enkripsi data (DEK) acak untuk database lokal atau file Anda, menyimpan hanya DEK yang dibungkus menggunakan kunci berbasis Keystore, dan memutarnya bila perlu.

Jika ragu, pilih jalur aman yang lebih sederhana: simpan lebih sedikit. Hindari PII offline kecuali benar-benar perlu, dan simpan kunci di Keystore.

Langkah demi langkah: implementasi penyimpanan aman di aplikasi Kotlin

Mulailah dengan menuliskan setiap nilai yang Anda rencanakan untuk disimpan di perangkat dan alasan pastinya harus ada di sana. Ini cara tercepat untuk mencegah penyimpanan "untuk berjaga-jaga".

Sebelum menulis kode, tentukan aturan Anda: berapa lama setiap item harus hidup, kapan harus diganti, dan apa arti "logout" sebenarnya. Access token mungkin kedaluwarsa dalam 15 menit, refresh token mungkin lebih lama, dan PII offline mungkin perlu aturan "hapus setelah 30 hari" yang tegas.

Implementasi yang tetap mudah dipelihara:

• Buat satu pembungkus "SecureStorage" sehingga sisa aplikasi tidak pernah menyentuh SharedPreferences, Keystore, atau database langsung.
• Taruh setiap item di tempat yang tepat: token di EncryptedSharedPreferences, kunci enkripsi dilindungi oleh Android Keystore, dan dataset offline lebih besar di database terenkripsi.
• Tangani kegagalan secara sengaja. Jika penyimpanan aman gagal, gagal dengan tertutup. Jangan diam-diam kembali ke penyimpanan plaintext.
• Tambahkan diagnostik tanpa membocorkan data: catat jenis event dan kode error, jangan pernah token, kunci, atau detail pengguna.
• Sambungkan jalur penghapusan: logout, hapus akun, dan "clear app data" harus mengarah ke rutinitas wipe yang sama.

Kemudian uji kasus membosankan yang memecah penyimpanan aman di produksi: pemulihan dari backup, upgrade dari versi aplikasi lama, perubahan pengaturan layar kunci, migrasi ke ponsel baru. Pastikan pengguna tidak terjebak di loop di mana data yang disimpan tidak bisa didekripsi tetapi aplikasi terus mencoba.

Terakhir, tuliskan keputusan dalam satu halaman yang bisa diikuti seluruh tim: apa yang disimpan, di mana, periode retensi, dan apa yang terjadi saat dekripsi gagal.

Kesalahan umum yang merusak penyimpanan aman

Kebanyakan kegagalan bukan soal memilih library yang salah. Mereka terjadi ketika satu jalan pintas kecil diam-diam menyalin rahasia ke tempat yang tidak Anda maksudkan.

Tanda bahaya terbesar adalah refresh token (atau token sesi jangka panjang) disimpan dalam plaintext di mana pun: SharedPreferences, file, cache "sementara", atau kolom database lokal. Jika seseorang mendapat backup, dump perangkat yang di-root, atau artefak build debug, token itu bisa bertahan lebih lama daripada password.

Rahasia juga bocor lewat visibilitas, bukan penyimpanan. Mencatat header permintaan lengkap, mencetak token saat debug, atau menyertakan konteks "membantu" pada laporan crash dan event analytics bisa mengekspos kredensial di luar perangkat. Perlakukan log sebagai publik.

Penanganan kunci adalah celah umum lain. Menggunakan satu kunci untuk semuanya memperbesar dampak kebocoran. Tidak pernah memutarnya berarti kompromi lama tetap valid. Sertakan rencana untuk versi kunci, rotasi, dan apa yang terjadi pada data terenkripsi lama.

Jangan lupa jalur "di luar brankas"

Enkripsi tidak menghentikan backup cloud menyalin data aplikasi lokal. Tidak menghentikan screenshot atau perekaman layar menangkap PII. Tidak menghentikan build debug dengan pengaturan longgar, atau fitur ekspor (CSV/share sheet) membocorkan field sensitif. Penggunaan clipboard juga dapat membocorkan kode satu kali atau nomor akun.

Selain itu, enkripsi tidak memperbaiki otorisasi. Jika aplikasi Anda menampilkan PII setelah pengguna logout, atau menyimpan cache yang dapat diakses tanpa otentikasi ulang, itu bug kontrol akses. Kunci UI, hapus cache sensitif saat logout, dan periksa izin sebelum menampilkan data terlindungi.

Detail operasional: siklus hidup, logout, dan kasus tepi

Penyimpanan aman bukan hanya tempat Anda menaruh rahasia. Ini tentang bagaimana mereka berperilaku seiring waktu: saat aplikasi tidur, saat pengguna logout, dan saat perangkat terkunci.

Untuk token, rencanakan siklus hidup penuh. Access token sebaiknya berumur pendek. Refresh token harus diperlakukan seperti password. Jika token kadaluwarsa, refreshlah dengan tenang. Jika refresh gagal (dicabut, password diubah, perangkat dihapus), hentikan loop coba ulang dan paksa sign-in bersih. Juga dukung pencabutan sisi server. Penyimpanan lokal sempurna tidak membantu jika Anda tidak pernah menonaktifkan kredensial yang dicuri.

Gunakan biometrik untuk re-auth, bukan untuk semua hal. Minta saat tindakan membawa risiko nyata (melihat PII, mengekspor data, mengubah detail payout, menampilkan kunci satu kali). Jangan memicu prompt setiap kali membuka aplikasi.

Saat logout, bersikap ketat dan dapat diprediksi:

• Bersihkan salinan di memori terlebih dahulu (token yang di-cache di singleton, interceptor, atau ViewModel).
• Hapus token yang tersimpan dan state sesi (termasuk refresh token).
• Hapus atau invalidasi kunci enkripsi lokal jika desain Anda mendukungnya.
• Hapus PII offline dan respons API yang di-cache.
• Nonaktifkan job background yang mungkin mengambil data lagi.

Kasus tepi penting di aplikasi bisnis: beberapa akun di satu perangkat, work profile, backup/restore, transfer perangkat-ke-perangkat, dan logout parsial (ganti perusahaan/workspace bukan sign-out penuh). Uji force stop, upgrade OS, dan perubahan jam karena drift waktu bisa memecah logika expiry.

Deteksi manipulasi adalah sebuah tradeoff. Pemeriksaan dasar (build debuggable, flag emulator, sinyal root sederhana, verdict Play Integrity) bisa mengurangi penyalahgunaan kasual, tetapi penyerang yang gigih bisa melewatinya. Perlakukan sinyal tamper sebagai input risiko: batasi akses offline, minta re-auth, dan catat kejadian.

Daftar periksa cepat sebelum rilis

Gunakan ini sebelum rilis. Ini menargetkan tempat-tempat di mana penyimpanan aman gagal di aplikasi bisnis nyata.

• Asumsikan perangkat bisa bermusuhan. Jika penyerang punya perangkat di-root atau image perangkat penuh, dapatkah mereka membaca token, kunci, atau PII dari file aplikasi, preferensi, log, atau screenshot? Jika jawabannya "mungkin," pindahkan rahasia ke perlindungan berbasis Keystore dan jaga payload terenkripsi.
• Periksa backup dan transfer perangkat. Jauhkan file sensitif dari Android Auto Backup, backup cloud, dan transfer perangkat-ke-perangkat. Jika kehilangan kunci saat restore mematahkan dekripsi, rencanakan alur pemulihan (re-auth dan unduh ulang daripada mencoba mendekripsi).
• Cari plaintext tidak sengaja di disk. Periksa file sementara, cache HTTP, laporan crash, event analytics, dan cache gambar yang mungkin mengandung PII atau token. Periksa logging debug dan dump JSON.
• Kedaluwarsa dan rotasi. Access token harus berumur pendek, refresh token dilindungi, dan sesi sisi-server bisa dicabut. Tentukan rotasi kunci dan apa yang aplikasi lakukan saat token ditolak (hapus, re-auth, coba ulang sekali).
• Perilaku reinstall dan pergantian perangkat. Uji uninstall dan reinstall, lalu buka saat offline. Jika kunci Keystore hilang, aplikasi harus gagal dengan aman (hapus data terenkripsi, tampilkan sign-in, hindari pembacaan parsial yang merusak state).

Validasi cepat adalah tes "hari buruk": pengguna logout, ganti password, restore backup ke ponsel baru, dan membuka aplikasi di pesawat. Hasilnya harus dapat diprediksi: data terdekripsi untuk pengguna yang tepat, atau dihapus dan diambil ulang setelah sign-in.

Contoh skenario: aplikasi bisnis yang menyimpan PII offline

Bayangkan aplikasi sales lapangan yang dipakai di area sinyal buruk. Sales masuk sekali di pagi hari, menelusuri pelanggan yang ditugaskan offline, menambah catatan pertemuan, lalu sinkronisasi nanti. Di sini daftar periksa penyimpanan berhenti jadi teori dan mencegah kebocoran nyata.

Pembagian praktis:

• Access token: buat umur pendek dan simpan di EncryptedSharedPreferences.
• Refresh token: lindungi lebih ketat dan batasi akses lewat Android Keystore.
• PII pelanggan (nama, telepon, alamat): simpan di database lokal terenkripsi.
• Catatan offline dan lampiran: simpan di database terenkripsi, dengan perhatian ekstra pada fitur ekspor dan berbagi.

Tambahkan dua fitur dan risikonya berubah.

Jika Anda menambahkan "remember me," refresh token menjadi pintu utama kembali ke akun. Perlakukan seperti password. Bergantung pada pengguna Anda, mungkin minta unlock perangkat (PIN/pattern/biometrik) sebelum mendekripsinya.

Jika Anda menambahkan mode offline, Anda tidak lagi hanya melindungi sesi. Anda melindungi daftar pelanggan penuh yang berharga sendiri. Itu biasanya mendorong Anda ke enkripsi database ditambah aturan logout yang jelas: hapus PII lokal, simpan hanya yang diperlukan untuk login berikutnya, dan batalkan sinkronisasi background.

Uji di perangkat nyata, bukan hanya emulator. Minimal, verifikasi perilaku kunci/buka, perilaku reinstall, backup/restore, dan pemisahan multi-user atau work profile.

Langkah selanjutnya: jadikan ini kebiasaan tim

Penyimpanan aman bekerja hanya jika menjadi kebiasaan. Tuliskan kebijakan penyimpanan singkat yang dapat diikuti tim Anda: apa yang ke mana (Keystore, EncryptedSharedPreferences, database terenkripsi), apa yang tidak pernah disimpan, dan apa yang harus dihapus saat logout.

Masukkan ini ke dalam rutinitas pengiriman sehari-hari: definition of done, code review, dan pemeriksaan rilis.

Checklist ringan untuk reviewer:

• Setiap item yang disimpan diberi label (token, material kunci, atau PII).
• Pilihan penyimpanan dibenarkan di komentar kode.
• Logout dan pergantian akun menghapus data yang tepat (dan hanya data itu).
• Error dan log tidak pernah mencetak rahasia atau PII penuh.
• Seseorang memegang kepemilikan kebijakan dan memperbaruinya.

Jika tim Anda menggunakan AppMaster (appmaster.io) untuk membangun aplikasi bisnis dan mengekspor sumber Kotlin untuk klien Android, pertahankan pendekatan pembungkus SecureStorage yang sama sehingga kode yang dihasilkan dan kustom mengikuti kebijakan konsisten.

Mulailah dengan bukti konsep kecil

Buat POC kecil yang menyimpan satu auth token dan satu record PII (misalnya nomor telepon pelanggan yang dibutuhkan offline). Lalu uji instalasi baru, upgrade, logout, perubahan layar kunci, dan clear app data. Kembangkan hanya setelah perilaku wipe benar dan dapat diulang.