Katakanlah saya memiliki aplikasi Android yang terhubung ke .Net API untuk menerima / menyetel data. Kebingungan yang saya miliki adalah tentang cara mendaftar / masuk pengguna pertama kali dan mengautentikasinya setiap kali mereka membuat permintaan ke API.

• Jika saya hanya menggunakan otentikasi berbasis nama pengguna / kata sandi, mereka tidak akan cukup aman?
• Dan saya tidak dapat menyimpan nama pengguna / kata sandi itu di perangkat karena alasan keamanan?
• Haruskah saya mengeluarkan GUID untuk setiap pengguna saat mendaftar, menyimpannya di perangkat mereka, dan mengambilnya setiap kali selama permintaan API?

Pola lain apa yang tersedia dan mana yang paling efisien dan aman, saya hanya perlu alur proses untuk itu. Dapatkah seseorang memberi tahu saya metode apa yang digunakan aplikasi Android terkenal seperti Facebook, FourSquare, atau Twitter untuk mengautentikasi setiap permintaan yang datang dari aplikasi seluler ke server mereka?

Maaf sebelumnya jika itu bukan informasi publik.

Saya membayangkan mereka menggunakan sistem keamanan berbasis "token", jadi sandi sebenarnya tidak pernah disimpan di mana pun, hanya digunakan pertama kali untuk otentikasi. Jadi aplikasi awalnya memposting nama pengguna / kata sandi (melalui ssl) dan server mengembalikan token yang disimpan aplikasi. Untuk upaya sinkronisasi berikutnya, token dikirim terlebih dahulu, server memeriksanya valid, lalu mengizinkan data lain untuk diposting.

Token harus memiliki masa kedaluwarsa sehingga server dapat meminta ulang upaya otentikasi.

Jika Anda terhubung ke adaptor sinkronisasi dari dalam Kerangka Android, Anda akan diberi kemampuan untuk menyinkronkan dan mengautentikasi semua yang ada di balik terpal.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

Jika Anda memeriksa akun di bawah Pengaturan pada perangkat Anda, Anda akan melihat apa yang saya maksud.

Pada dasarnya ini terkenal menggunakan protokol OAuth (1) / framework (2). Meskipun harus menjadi standar, masing-masing memiliki implementasi protokol / kerangka kerja yang berbeda. Jadi kita harus sangat berhati-hati dalam hal integrasi.

Contoh: Dropbox masih menggunakan OAuth 1 dan baru-baru ini hadir dengan dukungan OAuth 2.

Kembali ke Jawaban, Seperti, peterpan menyatakan, ini adalah cara otentikasi berbasis token adalah satu kali hal dan keluar dari persamaan. Token ini kedaluwarsa atau kekuatan itu diberikan kepada pengembang dalam beberapa kasus.

Hal yang menarik di balik ini adalah bahwa, ruang lingkup akses sumber daya dapat didefinisikan daripada mengizinkan aplikasi klien untuk menyimpan nama pengguna, kata sandi yang berbahaya.

Ini adalah ilustrasi dasar tentang cara kerjanya.

Saya akan memperbarui jawabannya setelah saya mendapatkan detail lebih lanjut tentang ini, karena saya bekerja di bidang ini hari ini :)

Jika saya hanya menggunakan otentikasi berbasis nama pengguna / kata sandi, mereka tidak akan cukup aman?

Tidak, karena Anda hanya mengidentifikasi SIAPA yang mengakses server API, tetapi bukan WHAT yang mengaksesnya.

Perbedaan Antara WHO dan WHAT Mengakses Server API

Untuk lebih memahami perbedaan antara WHO dan WHAT yang mengakses server API, mari gunakan gambar ini:

Saluran Komunikasi yang Dimaksud mewakili aplikasi seluler yang digunakan seperti yang Anda harapkan, oleh pengguna yang sah tanpa niat jahat, menggunakan versi aplikasi seluler tanpa gangguan, dan berkomunikasi langsung dengan server API tanpa menjadi orang yang diserang di tengah.

Saluran sebenarnya mungkin mewakili beberapa skenario berbeda, seperti pengguna sah dengan niat jahat yang mungkin menggunakan versi aplikasi seluler yang dikemas ulang, peretas menggunakan versi asli aplikasi seluler, sementara orang di tengah menyerangnya, untuk memahami caranya komunikasi antara aplikasi seluler dan server API sedang dilakukan untuk dapat mengotomatiskan serangan terhadap API Anda. Banyak skenario lain yang mungkin, tetapi kami tidak akan menghitung satu per satu di sini.

Saya berharap saat ini Anda mungkin sudah memiliki petunjuk mengapa WHO dan WHAT tidak sama, tetapi jika tidak akan menjadi jelas suatu saat.

The WHO adalah pengguna dari aplikasi mobile yang kita dapat mengotentikasi, wewenang dan mengidentifikasi dalam beberapa cara, seperti menggunakan OpenID Connect atau OAUTH2 mengalir.

OAUTH

Umumnya, OAuth memberikan "akses yang didelegasikan secara aman" ke sumber daya server atas nama pemilik sumber daya. Ini menentukan proses bagi pemilik sumber daya untuk memberi otorisasi akses pihak ketiga ke sumber daya server mereka tanpa membagikan kredensial mereka. Dirancang khusus untuk bekerja dengan Hypertext Transfer Protocol (HTTP), OAuth pada dasarnya memungkinkan token akses diterbitkan ke klien pihak ketiga oleh server otorisasi, dengan persetujuan dari pemilik sumber daya. Pihak ketiga kemudian menggunakan token akses untuk mengakses sumber daya yang dilindungi yang dihosting oleh server sumber daya.

OpenID Connect

OpenID Connect 1.0 adalah lapisan identitas sederhana di atas protokol OAuth 2.0. Hal ini memungkinkan Klien untuk memverifikasi identitas Pengguna Akhir berdasarkan otentikasi yang dilakukan oleh Server Otorisasi, serta untuk mendapatkan informasi profil dasar tentang Pengguna Akhir dengan cara yang dapat dioperasikan dan seperti REST.

Meskipun autentikasi pengguna mungkin memberi tahu server API siapa yang menggunakan API, itu tidak dapat menjamin bahwa permintaan berasal dari APA yang Anda harapkan, versi asli dari aplikasi seluler.

Sekarang kita membutuhkan cara untuk mengidentifikasi APA yang memanggil server API, dan di sini segalanya menjadi lebih rumit daripada yang mungkin dipikirkan kebanyakan pengembang. The APA adalah hal yang membuat permintaan ke server API. Apakah ini benar-benar contoh asli dari aplikasi seluler, atau apakah bot, skrip otomatis, atau penyerang secara manual mengaduk-aduk server API, menggunakan alat seperti Postman?

Untuk mengejutkan Anda, Anda mungkin akhirnya menemukan bahwa Itu bisa menjadi salah satu pengguna yang sah menggunakan versi aplikasi seluler yang dikemas ulang atau skrip otomatis yang mencoba untuk melakukan gamify dan memanfaatkan layanan yang disediakan oleh aplikasi.

Nah, untuk mengidentifikasi APA , pengembang cenderung menggunakan kunci API yang biasanya mereka kode keras dalam kode aplikasi seluler mereka. Beberapa pengembang bekerja ekstra dan menghitung kunci pada waktu proses di aplikasi seluler, sehingga itu menjadi rahasia waktu proses sebagai lawan dari pendekatan sebelumnya ketika rahasia statis disematkan dalam kode.

Tulisan di atas diambil dari artikel yang saya tulis berjudul MENGAPA APLIKASI SELULER ANDA MEMBUTUHKAN KUNCI API? , dan Anda dapat membaca selengkapnya di sini , itu adalah artikel pertama dari rangkaian artikel tentang kunci API.

Menyimpan Data Sensitif di Perangkat Klien

Dan saya tidak dapat menyimpan nama pengguna / kata sandi itu di perangkat karena alasan keamanan? Haruskah saya mengeluarkan GUID untuk setiap pengguna saat mendaftar, menyimpannya di perangkat mereka, dan mengambilnya setiap kali selama permintaan API?

Apa pun yang Anda simpan di perangkat, meskipun dienkripsi, dapat direkayasa balik selama waktu pengoperasian dengan alat seperti Frida atau Xposed.

Frida

Masukkan skrip Anda sendiri ke dalam proses kotak hitam. Hubungkan fungsi apa pun, mata-matai API kripto atau lacak kode aplikasi pribadi, tidak perlu kode sumber. Edit, tekan simpan, dan langsung lihat hasilnya. Semua tanpa langkah kompilasi atau program dimulai ulang.

xPosed

Xposed adalah kerangka kerja untuk modul yang dapat mengubah perilaku sistem dan aplikasi tanpa menyentuh APK apa pun. Itu bagus karena itu berarti modul dapat bekerja untuk versi yang berbeda dan bahkan ROM tanpa perubahan apa pun (selama kode aslinya

Di perangkat yang dikontrol penyerang, dia juga dapat menggunakan proxy untuk melakukan Man in the Middle Attack untuk mengekstrak rahasia apa pun yang dapat Anda gunakan untuk mengidentifikasi WHAT atau WHO seperti yang saya tunjukkan di artikel Mencuri Kunci API itu dengan Man in the Attack :

Meskipun kami dapat menggunakan teknik lanjutan, seperti JNI / NDK, untuk menyembunyikan kunci API di kode aplikasi seluler, hal itu tidak akan menghalangi seseorang untuk melakukan serangan MitM untuk mencuri kunci API. Faktanya, serangan MitM mudah sampai-sampai bisa dicapai oleh non pengembang.

Jadi sekarang apa ... Apakah saya ditakdirkan sampai pada titik saya tidak dapat melindungi server API saya dari penyalahgunaan ??? Tidak ada ketenangan jadi ... harapan masih ada !!!

Solusi yang memungkinkan

Dapatkah seseorang memberi tahu saya metode apa yang digunakan aplikasi Android terkenal seperti Facebook, FourSquare, atau Twitter untuk mengautentikasi setiap permintaan yang datang dari aplikasi seluler ke server mereka?

Maaf, tetapi saya tidak memiliki cukup pengetahuan tentang aplikasi ini untuk menjelaskan kepada Anda, tetapi saya dapat mengarahkan Anda ke beberapa pendekatan lain.

Pola lain apa yang tersedia dan mana yang paling efisien dan aman, saya hanya perlu alur proses untuk itu.

Jadi, apa pun yang berjalan di sisi klien dan memerlukan beberapa rahasia untuk mengakses API dapat disalahgunakan dengan berbagai cara dan Anda dapat mempelajari lebih lanjut rangkaian artikel ini tentang Teknik Keamanan API Seluler. Artikel ini akan mengajari Anda bagaimana Kunci API, Token Akses Pengguna, HMAC dan TLS Pinning dapat digunakan untuk melindungi API dan bagaimana mereka dapat dilewati.

Untuk mengatasi masalah APA yang mengakses aplikasi seluler Anda, Anda perlu menggunakan satu atau semua solusi yang disebutkan dalam rangkaian artikel tentang Teknik Keamanan API Seluler yang saya sebutkan di atas dan diterima bahwa mereka hanya dapat mempersulit akses tidak sah ke server API Anda. melewati tapi bukan tidak mungkin.

Solusi yang lebih baik dapat digunakan dengan menggunakan solusi Pengesahan Aplikasi Seluler yang akan memungkinkan server API mengetahui hanya menerima permintaan dari aplikasi seluler asli.

Pengesahan Aplikasi Seluler

Penggunaan solusi Pengesahan Aplikasi Seluler akan memungkinkan server API mengetahui APA yang mengirimkan permintaan, sehingga memungkinkan untuk hanya menanggapi permintaan dari aplikasi seluler asli sambil menolak semua permintaan lain dari sumber yang tidak aman.

Peran solusi Pengesahan Aplikasi Seluler adalah untuk menjamin pada saat berjalan bahwa aplikasi seluler Anda tidak dirusak, tidak berjalan di perangkat yang di-rooting, tidak diinstrumentasi oleh kerangka kerja seperti xPosed atau Frida, tidak sedang diserang MitM, dan ini dicapai dengan menjalankan SDK di latar belakang. Layanan yang berjalan di cloud akan menantang aplikasi, dan berdasarkan tanggapannya, itu akan membuktikan integritas aplikasi seluler dan perangkat yang dijalankan, sehingga SDK tidak akan pernah bertanggung jawab atas keputusan apa pun.

Pada pengesahan integritas aplikasi seluler yang berhasil, token JWT yang berumur pendek dikeluarkan dan ditandatangani dengan rahasia yang hanya diketahui oleh server API dan layanan Pengesahan Aplikasi Seluler di cloud. Dalam kasus kegagalan pada pengesahan aplikasi seluler, token JWT ditandatangani dengan rahasia yang tidak diketahui oleh server API.

Sekarang Aplikasi harus mengirim dengan setiap panggilan API token JWT di header permintaan. Ini akan memungkinkan server API untuk hanya melayani permintaan ketika dapat memverifikasi tanda tangan dan waktu kedaluwarsa dalam token JWT dan menolaknya jika verifikasi gagal.

Setelah rahasia yang digunakan oleh layanan Pengesahan Aplikasi Seluler tidak diketahui oleh aplikasi seluler, tidak mungkin untuk merekayasa baliknya pada waktu proses bahkan ketika Aplikasi dirusak, berjalan di perangkat yang di-rooting atau berkomunikasi melalui koneksi yang menjadi target dari Man in the Middle Attack.

Layanan Pengesahan Aplikasi Seluler sudah ada sebagai solusi SAAS di Approov (Saya bekerja di sini) yang menyediakan SDK untuk beberapa platform, termasuk iOS, Android, React Native, dan lainnya. Integrasi juga memerlukan pemeriksaan kecil di kode server API untuk memverifikasi token JWT yang dikeluarkan oleh layanan cloud. Pemeriksaan ini diperlukan agar server API dapat memutuskan permintaan apa yang akan dilayani dan apa yang ditolak.

Kesimpulan

Pada akhirnya, solusi yang digunakan untuk melindungi server API Anda harus dipilih sesuai dengan nilai dari apa yang Anda coba lindungi dan persyaratan hukum untuk jenis data tersebut, seperti peraturan GDPR di Eropa.

APAKAH ANDA INGIN PERGI KE EXTRA MILE?

Proyek Keamanan Seluler OWASP - 10 risiko teratas

Proyek Keamanan Seluler OWASP adalah sumber daya terpusat yang dimaksudkan untuk memberi pengembang dan tim keamanan sumber daya yang mereka butuhkan untuk membangun dan memelihara aplikasi seluler yang aman. Melalui proyek ini, tujuan kami adalah untuk mengklasifikasikan risiko keamanan seluler dan memberikan kontrol perkembangan untuk mengurangi dampak atau kemungkinan eksploitasi.

Saya sedang mencari hal yang persis sama dan menemukan cara google, seperti yang dikatakan peterpan, tetapi melalui Google API. Coba tautan ini dan Google jalan Anda melaluinya, saya juga mulai! Saya akan memposting info baru saat saya melakukannya!

http://developer.android.com/google/auth/http-auth.html

Saya pemula tetapi saya akan mencoba memberikan solusi logis untuk pertanyaan yang diberikan.

Akan ada dua opsi, [1] Untuk setiap URI, otentikasi http akan dilakukan di mana kredensial yang dimasukkan pengguna akan diverifikasi dan pengguna harus mengakses sumber daya.

[2] Pendekatan lain bisa jadi, pengguna harus diautentikasi dan pada setiap otentikasi token unik akan dibuat. Menggunakan token yang dihasilkan, pengguna harus mengakses sumber daya.

Meskipun saya tidak yakin pendekatan mana yang paling cocok untuk aplikasi seluler.

Contoh otentikasi adalah tempat yang baik untuk memulai. Android menyimpan kredensial di Manajer Akun, Anda dapat melihat akun di pengaturan Android. Ini secara otomatis akan menyimpan token, meminta kredensial pengguna jika kadaluwarsa atau hilang, menyegarkan token, dll. Saya menemukan bagian http dari contoh ini kurang atau lama. Memperluas AccountAuthenticatorActivity android adalah bantuan yang bagus untuk mengurai data serial ke tata letak dan kembali ke internet.

Nama pengguna dan kata sandi dapat aman jika ditempatkan di SharedPreferences. Menggunakan https dalam menghubungkan ke server juga sudah cukup baik.