Android: Menyimpan nama pengguna dan kata sandi?

178

Jika saya ingin menyimpan nama pengguna dan kata sandi untuk digunakan di dalam aplikasi Android, apa cara terbaik untuk melakukannya? Apakah itu melalui layar preferensi (tetapi bagaimana jika pengguna melewatkan ini?), Atau memunculkan kotak dialog dan meminta kredensial? Jika demikian, saya harus mempertahankan status untuk aplikasi. Bagaimana saya melakukan ini?

android  authentication  storage  credentials 
— Legenda
sumber
4
stackoverflow.com/a/786588/1166727 Periksa apa yang dikatakan @RetoMeier (Pimpinan Teknologi untuk Pengembangan Android di Google) tentang ini.
— tony gil
1
Jika Anda mencari cara teraman untuk menyimpan kredensial. Baca jawaban ini stackoverflow.com/a/20560574/730807
— Durai Amuthan.H
3
@Legenda bagaimana Anda menyelesaikan masalah Anda?
— Erum
@ Legenda, dapatkah Anda menjelaskan penghematan pwd di prefs setelah enkripsi .. karena saya ingin aplikasi saya bekerja tanpa internet, lalu bagaimana saya mendapatkan kunci .. (karena saya tidak dapat menyimpan kunci pada perangkat)
— eRaisedToX
Anda dapat menggunakan keystore untuk Api +18. developer.android.com/training/articles/keystore
— Golnar

Jawaban:

115

Sebagian besar aplikasi Android dan iPhone yang saya lihat menggunakan layar awal atau kotak dialog untuk meminta kredensial. Saya pikir itu merepotkan bagi pengguna untuk harus sering memasukkan kembali nama / kata sandi mereka, jadi menyimpan info itu masuk akal dari perspektif kegunaan.

Saran dari ( panduan pengembang Android ) adalah:

Secara umum, kami sarankan meminimalkan frekuensi meminta kredensial pengguna - untuk membuat serangan phishing lebih mencolok, dan kecil kemungkinannya untuk berhasil. Alih-alih gunakan token otorisasi dan segarkan.

Jika memungkinkan, nama pengguna dan kata sandi tidak boleh disimpan di perangkat. Sebagai gantinya, lakukan otentikasi awal menggunakan nama pengguna dan kata sandi yang disediakan oleh pengguna, dan kemudian gunakan token otorisasi khusus layanan yang berumur pendek.

Menggunakan AccountManger adalah opsi terbaik untuk menyimpan kredensial. The SampleSyncAdapter memberikan contoh bagaimana menggunakannya.

Jika ini bukan opsi bagi Anda karena alasan tertentu, Anda dapat kembali ke kredensial yang ada menggunakan mekanisme Preferensi . Aplikasi lain tidak akan dapat mengakses preferensi Anda, sehingga informasi pengguna tidak mudah terekspos.

— Eric Levine
sumber
40
Saya akan mengatakan itu berisiko untuk tetap menggunakan informasi kata sandi seperti dalam preferensi. Pada ponsel yang di-root, dimungkinkan untuk mengakses file preferensi suatu aplikasi. Paling tidak yang bisa Anda lakukan adalah mengaburkan kata sandi.
— Jayesh
51
Jika seseorang memiliki ponsel Anda dan dapat melakukan rooting, tidak banyak yang dapat Anda lakukan untuk menjaga keamanan data Anda. Ini bukan ide yang buruk untuk mengaburkan kata sandi, tetapi itu tidak benar-benar menambahkan perlindungan yang jauh lebih banyak. Yang lebih penting adalah bahwa ada banyak lapisan keamanan yang sudah dibangun ke dalam OS. Tentu saja, Anda tidak ingin melakukan sesuatu yang bodoh untuk menghindari langkah-langkah itu. Mungkin lebih baik menggunakan sistem seperti OAuth, dan menyimpan token di perangkat daripada nama pengguna dan kata sandi.
— Eric Levine
4
Jika Anda menggunakan AccountManager(sesuai jawaban saya, dan @ Miguel secara tidak langsung) dan seseorang memegang telepon GSM Anda, mereka harus tetap menggunakan SIM Anda untuk memiliki akses ke akun Anda, karena itu akan membatalkan kredensial yang disimpan. saat SIM berubah.
— Jon O
3
Penghapusan akun pada perubahan SIP telah dihapus beberapa waktu yang lalu, karena itu tidak masuk akal, terutama bagi orang-orang yang memiliki lebih dari satu SIM. Strategi yang lebih baik jika ponsel Anda dicuri adalah pergi ke halaman akun Google Anda dan mencabut akses untuk perangkat tertentu.
— Nikolay Elenkov
2
"Menggunakan AccountManger adalah opsi terbaik untuk menyimpan kredensial." Mengapa?
— Luc
9

Anda harus menggunakan Manajer Akun Android . Ini dibuat khusus untuk skenario ini. Ini sedikit rumit tetapi salah satu hal yang dilakukannya adalah membatalkan kredensial lokal jika kartu SIM berubah, jadi jika seseorang menggesek ponsel Anda dan melempar SIM baru ke dalamnya, kredensial Anda tidak akan terganggu.

Ini juga memberi pengguna cara cepat dan mudah untuk mengakses (dan berpotensi menghapus) kredensial yang disimpan untuk akun apa pun yang mereka miliki di perangkat, semuanya dari satu tempat.

SampleSyncAdapter (seperti @Miguel disebutkan) adalah contoh yang memanfaatkan kredensial akun yang disimpan.

— Jon O
sumber
3
Di mana didokumentasikan bahwa AccountManager akan "membatalkan kredensial lokal jika kartu SIM berubah"?
— Eric Levine
Bukannya aku sadar. Namun, itu sesuatu yang saya yakini / terima / pahami setelah beberapa pengguna aplikasi saya mengalami masalah autentikasi setelah pertukaran SIM.
— Jon O
1
Saya tidak melihatnya di JavaDocs atau kode AccountManager. Kedengarannya seperti fitur yang bagus, akan lebih baik untuk memverifikasi dan memahami detailnya.
— Eric Levine
2
Menurut @NikolayElenkov, fitur perubahan kartu SIM yang tidak valid telah dihapus.
— ThomasW
2
@ Thomas Apakah Anda memiliki kutipan untuk itu? Akan sangat bagus untuk mendapatkan jawaban yang pasti.
— Jon O
8

Saya pikir cara terbaik untuk mengamankan kredensial Anda adalah dengan pertama-tama berpikir untuk menyimpan kata sandi dengan enkripsi dalam file account.db yang tidak dapat dengan mudah tersedia di perangkat yang tidak di-rooting dan jika perangkat yang di-rooting, peretas harus memerlukan kunci untuk mendekripsi. Itu.

Opsi lainnya adalah lakukan semua otentikasi Anda seperti yang dilakukan Gmail. setelah otentikasi pertama dengan server Gmail. Anda mendapat Token Auth yang akan digunakan jika kata sandi Anda. token itu akan disimpan dalam teks biasa. token ini bisa salah jika Anda mengubah kata sandi dari Server.

opsi terakhir saya sarankan Anda untuk mengaktifkan Otentikasi 2-Faktor & membuat Kata Sandi Khusus Perangkat untuk perangkat Anda. Setelah kehilangan perangkat, yang Anda butuhkan adalah menonaktifkan perangkat itu.

— Riz
sumber
2
Bisakah Anda memposting sumber yang mengatakan, bahwa accounts.db dienkripsi? Atau apakah Anda mengatakan bahwa kata sandi spesifik harus dienkripsi?
— Michał K
1
@Riz, tempat menyimpan kunci untuk enkripsi lalu ... karena aplikasi saya bekerja tanpa Internet, jadi tidak bisa mendapatkannya dari jaringan
— eRaisedToX
2

Dengan perangkat keras dan API sidik jari (Android 6.0) baru Anda dapat melakukannya seperti pada aplikasi contoh github ini .

— Zlatko
sumber
8
Proyek sampel yang direferensikan membuat kunci di Android Key Store dan menggunakannya untuk membuat sandi untuk mengenkripsi kata sandi. Kata sandi dan sandi yang dienkripsi disimpan sebagai string yang disandikan base64 dalam preferensi bersama. Setelah otentikasi sidik jari berhasil, kunci rahasia diambil dari Android Key Store dan digunakan dengan sandi yang didekodekan untuk mendekripsi sandi yang didekodekan.
— mjwheat
@ mjwheat ini sangat membantu untuk memahami apa yang terjadi dalam contoh ini. Terima kasih! Satu kesalahan ketik kecil: "... untuk mendekripsi kata sandi yang disandikan."
— muetzenflo
2

Ini diberi peringkat berdasarkan tingkat kesulitan untuk memecah informasi tersembunyi Anda .

  1. Simpan di cleartext

  2. Toko dienkripsi menggunakan kunci simetris

  3. Menggunakan Android Keystore

  4. Simpan dienkripsi menggunakan kunci asimetris

sumber: Di mana tempat terbaik untuk menyimpan kata sandi di aplikasi Android Anda

Keystore itu sendiri dienkripsi menggunakan pin / kata sandi lockscreen milik pengguna, karenanya, ketika layar perangkat terkunci, Keystore tidak tersedia. Ingatlah hal ini jika Anda memiliki layanan latar belakang yang mungkin perlu mengakses rahasia aplikasi Anda.

sumber: Sederhana menggunakan Android Keystore untuk menyimpan kata sandi dan informasi sensitif lainnya

— Dmytro Melnychuk
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.