Rahasia OAuth di aplikasi seluler

137

Saat menggunakan protokol OAuth, Anda memerlukan string rahasia yang diperoleh dari layanan yang ingin Anda delegasikan. Jika Anda melakukan ini di aplikasi web, Anda dapat menyimpan rahasia di basis data Anda atau di sistem file, tetapi apa cara terbaik untuk menanganinya di aplikasi seluler (atau dalam hal ini aplikasi desktop)?

Menyimpan string di aplikasi jelas tidak baik, karena seseorang dapat dengan mudah menemukannya dan menyalahgunakannya.

Pendekatan lain adalah menyimpannya di server Anda, dan meminta aplikasi mengambilnya di setiap proses, tidak pernah menyimpannya di telepon. Ini hampir sama buruknya, karena Anda harus memasukkan URL ke dalam aplikasi.

Satu-satunya solusi yang bisa saya hasilkan adalah dengan terlebih dahulu mendapatkan Token Akses seperti biasa (sebaiknya menggunakan tampilan web di dalam aplikasi), dan kemudian merutekan semua komunikasi lebih lanjut melalui server kami, yang akan menambahkan rahasia ke data permintaan dan berkomunikasi dengan penyedia. Kemudian lagi, saya adalah seorang noob keamanan, jadi saya sangat ingin mendengar pendapat beberapa orang yang berpengetahuan tentang ini. Bagi saya, tampaknya tidak sebagian besar aplikasi melakukan hal ini untuk menjamin keamanan (misalnya, Facebook Connect tampaknya berasumsi bahwa Anda memasukkan rahasia ke dalam string tepat di aplikasi Anda).

Hal lain: Saya tidak percaya rahasianya terlibat dalam permintaan Token Akses pada awalnya, jadi itu bisa dilakukan tanpa melibatkan server kami sendiri. Apakah saya benar?

iphone  android  security  mobile  oauth 
— Felixyz
sumber
Maaf jika saya tidak mendapatkan yang jelas, tapi apa masalah dengan menyimpan kode dalam database aplikasi? Karena token tersebut dibuat dan disimpan setelah pengguna mengautentikasi akunnya, maka harus aman untuk mengasumsikan bahwa pengguna tersebut ingin perangkat seluler menyimpan akses untuk memiliki akses.
— aduk
Bahkan setelah pengguna mengizinkan Anda untuk mengakses akun mereka (misalnya di Twitter), Anda harus menggunakan rahasia yang Anda peroleh dari layanan yang coba Anda akses. Rahasia ini digunakan dalam semua komunikasi dengan server mereka, bersama dengan kunci otentikasi dan beberapa kunci lainnya. Jadi ya, Anda dapat menyimpan kunci akses, tetapi rahasianya tidak boleh disimpan, karena dapat digunakan dengan kunci otentikasi apa pun untuk menyalahgunakan layanan. Sekali lagi, saya akan senang dikoreksi oleh orang-orang yang mengetahui lebih banyak tentang ini.
— Felixyz
1
OAuth menawarkan metode autentikasi yang mengamankan data login pengguna asli. Untuk memungkinkan kombinasi login unik baru dibuat yang hanya bekerja bersama dengan kombinasi tombol aplikasi unik . Manfaat besar dari menyimpan data login pengguna adalah bahwa data tersebut benar-benar aman setelah otorisasi pertama dan dalam kasus pelanggaran apa pun, pengguna dapat dengan mudah mencabut akses otorisasi. Dan tentu saja tidak menyimpan rahasia tidak masuk akal karena pengguna perlu mengautentikasi ulang saat itu (dan bukan itu yang diinginkan pengguna saat memberikan akses aplikasi).
— aduk
@poke Kunci autentikasi yang diperoleh saat pengguna menyetujui aplikasi Anda dengan penyedia harus disimpan, tetapi token rahasia yang Anda terima dari penyedia sebelum merilis aplikasi tidak boleh (dalam kasus desktop atau aplikasi seluler; jika itu aplikasi web Anda jelas dapat menyimpan kunci di server, seperti yang dinyatakan dalam pertanyaan).
— Felixyz
4
Sesuai pemahaman saya tentang oAuth-- Dalam kasus aplikasi desktop, sangat mudah untuk mengendus / memantau lalu lintas HTTP / HTTPS dengan alat seperti ini ieinspector.com/httpanalyzer/index.html Oleh karena itu, rahasia token dan token Anda keduanya dapat ditemukan sangat dengan mudah. Jadi satu-satunya perlindungan adalah rahasia konsumen Anda. Sekarang jika Anda menyimpan rahasia di dalam aplikasi dan seseorang dapat menemukannya, meniru identitas aplikasi lain sebagai aplikasi Anda menjadi permainan anak-anak. Koreksi saya jika saya salah.
— Varun

Jawaban:

38

Ya, ini adalah masalah dengan desain OAuth yang kami hadapi sendiri. Kami memilih untuk mem-proxy semua panggilan melalui server kami sendiri. OAuth tidak sepenuhnya dihapus sehubungan dengan aplikasi desktop. Tidak ada solusi yang sempurna untuk masalah yang saya temukan tanpa mengubah OAuth.

Jika Anda memikirkannya dan mengajukan pertanyaan mengapa kami memiliki rahasia, sebagian besar untuk penyediaan dan menonaktifkan aplikasi. Jika rahasia kami disusupi, penyedia hanya dapat benar-benar mencabut seluruh aplikasi. Karena kami harus menyematkan rahasia kami di aplikasi desktop, kami agak kacau.

Solusinya adalah memiliki rahasia berbeda untuk setiap aplikasi desktop. OAuth tidak membuat konsep ini mudah. Salah satu caranya adalah meminta pengguna pergi dan membuat rahasia mereka sendiri dan memasukkan kuncinya sendiri ke dalam aplikasi desktop Anda (beberapa aplikasi facebook melakukan hal serupa untuk waktu yang lama, meminta pengguna untuk pergi dan membuat facebook untuk mengatur kuis khusus mereka dan sampah). Ini bukan pengalaman yang luar biasa bagi pengguna.

Saya sedang mengerjakan proposal untuk sistem delegasi untuk OAuth. Konsepnya adalah dengan menggunakan kunci rahasia kita sendiri yang kita dapatkan dari penyedia kita, kita dapat mengeluarkan rahasia yang didelegasikan kepada klien desktop kita sendiri (satu untuk setiap aplikasi desktop pada dasarnya) dan kemudian selama proses auth kita mengirim kunci itu ke tingkat atas penyedia yang menelepon kembali kepada kami dan memvalidasi ulang dengan kami. Dengan begitu kami dapat mencabut rahasia sendiri yang kami terbitkan ke setiap klien desktop. (Meminjam banyak cara kerjanya dari SSL). Keseluruhan sistem ini akan menjadi prefek untuk layanan web bernilai tambah yang meneruskan panggilan ke layanan web pihak ketiga.

Proses ini juga dapat dilakukan tanpa callback verifikasi delegasi jika penyedia tingkat atas menyediakan API untuk membuat dan mencabut rahasia baru yang didelegasikan. Facebook melakukan hal serupa dengan mengizinkan aplikasi Facebook mengizinkan pengguna membuat sub-aplikasi.

Ada beberapa pembicaraan tentang masalah ini secara online:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

Solusi Twitter dan Yammer adalah solusi pin otentikasi: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

— Zac Bowling
sumber
Ini sangat menarik, meskipun menegaskan apa yang saya takuti, bahwa OAuth tidak begitu bagus untuk aplikasi desktop / seluler. Tentu saja, penyerang harus mendapatkan rahasianya terlebih dahulu dan kemudian juga mengendus identitas seseorang, jadi itu akan membutuhkan tekad yang cukup tinggi. Solusi pin baik-baik saja untuk desktop tetapi untuk imo seluler yang berat.
— Felixyz
Bagaimana skema yang Anda usulkan membantu layanan web nilai tambah, karena masalah ini tidak berlaku untuk mereka? Juga, saya tidak melihat bagaimana itu akan bekerja dengan penyedia menghasilkan rahasia baru, karena Anda akan memerlukan "rahasia utama" bahkan untuk meminta rahasia baru tersebut, jadi Anda setidaknya memerlukan satu panggilan ke server Anda sendiri (yang menyimpan rahasia utama). Tapi itu tentu saja lebih baik daripada merutekan semua lalu lintas melalui server Anda sendiri. Klarifikasi dipersilahkan! Dan harap perbarui di sini seiring kemajuan proposal Anda!
— Felixyz
7
Hanya ingin tahu: bagaimana Anda menentukan bahwa hal yang membuat panggilan ke server proxy Anda adalah sah?
— davidtbernal
1
Menanggapi notJim: risiko utama dalam membiarkan rahasia konsumen Anda bocor adalah bahwa aplikasi berbahaya (atau bodoh) dapat dikembangkan menggunakannya, menodai reputasi Anda dan meningkatkan risiko Anda untuk menutup aplikasi Anda yang sah karena penyalahgunaan / penyalahgunaan API. Dengan mem-proxy semua panggilan yang memerlukan rahasia Anda melalui aplikasi web yang Anda kontrol, Anda kembali ke posisi di mana Anda dapat mengawasi pola penyalahgunaan dan mencabut akses pada pengguna atau mengakses tingkat token sebelum API yang Anda gunakan memutuskan untuk ditutup turunkan seluruh layanan Anda.
— quasistoic
Saya setuju dengan quasistoic di sini, Anda perlu menggunakan browser berkemampuan SSL untuk menangani panggilan oauth. Ini adalah hal yang baik karena beberapa alasan, termasuk dengan mudah mengelola pembaruan keamanan apa pun di masa mendatang, dan tidak ada dalam aplikasi aktual yang perlu diperbarui dari waktu ke waktu. Zac menunjukkan Twitter mengusulkan solusi PIN, yang sebenarnya saya pikirkan juga, karena Anda tidak dapat mempercayai aplikasi untuk mendapatkan kodenya dengan aman. Saya sarankan menggunakan 'Nonce' dengan enkripsi modern bersama dengan PIN dan rahasia untuk mem-proxy permintaan melalui server web.
— Tandai
18

Dengan OAUth 2.0, Anda dapat menyimpan rahasia di server. Gunakan server untuk memperoleh token akses yang kemudian Anda pindahkan ke aplikasi dan Anda dapat melakukan panggilan dari aplikasi ke sumber daya secara langsung.

Dengan OAuth 1.0 (Twitter), rahasia diperlukan untuk melakukan panggilan API. Proxying panggilan melalui server adalah satu-satunya cara untuk memastikan rahasia tidak dikompromikan.

Keduanya memerlukan beberapa mekanisme yang komponen server Anda tahu bahwa klien Anda yang memanggilnya. Ini cenderung dilakukan pada pemasangan dan menggunakan mekanisme khusus platform untuk mendapatkan semacam id aplikasi dalam panggilan ke server Anda.

(Saya adalah editor spesifikasi OAuth 2.0)

— Dick Hardt
sumber
3
Dapatkah Anda menguraikan tentang "mekanisme khusus platform untuk mendapatkan semacam id aplikasi"? Bagaimana komponen server memverifikasi identitas klien? Saya rasa ini bisa dilakukan dengan penyediaan klien. Misalnya, terapkan sertifikat SSL baru dan unik untuk setiap klien. Apa itu yang kamu maksud Jika lebih kompleks dari ini, mungkin Anda bisa merujuk ke artikel yang lebih mendalam?
— Cheeso
2
Saya ingat beberapa orang keamanan berbicara tentang bagaimana ini bisa dilakukan. Ada panggilan ke OS yang mengembalikan token yang ditandatangani yang kemudian dapat Anda kirim ke server Anda dan verifikasi. Maaf saya tidak punya secara spesifik. Ini adalah kesalahan yang mungkin menggunakan beberapa contoh bagus.
— Dick Hardt
3
@DickHardt tetapi dalam skenario ini, bagaimana Anda memastikan bahwa aplikasi seluler benar-benar aplikasi Anda dan bukan yang palsu?
— Rafael Membrives
11

Salah satu solusinya adalah dengan kode keras rahasia OAuth ke dalam kode, tetapi tidak sebagai string biasa. Mengaburkannya dengan cara tertentu - membaginya menjadi segmen, menggeser karakter dengan offset, memutarnya - lakukan salah satu atau semua hal ini. Seorang cracker dapat menganalisis kode byte Anda dan menemukan string, tetapi kode obfuscation mungkin sulit untuk diketahui.

Ini bukan solusi yang sangat mudah, tapi yang murah.

Bergantung pada nilai exploitnya, beberapa cracker jenius dapat berusaha lebih keras untuk menemukan kode rahasia Anda. Anda perlu mempertimbangkan faktor-faktornya - biaya solusi sisi server yang disebutkan sebelumnya, insentif bagi para cracker untuk menghabiskan lebih banyak upaya dalam menemukan kode rahasia Anda, dan kerumitan kebingungan yang dapat Anda terapkan.

— Jayesh
sumber
1
Ya saya rasa ini masuk akal. Butuh banyak tekad bagi seseorang untuk pertama-tama mengekstrak rahasia konsumen dan kemudian merebut kredensial orang untuk melakukan sesuatu yang berarti. Untuk aplikasi profil tinggi, saya tidak yakin ini akan cukup, tetapi untuk aplikasi rata-rata, menurut saya Anda benar bahwa Anda harus menyeimbangkan waktu implementasi dengan ancaman keamanan yang cukup kecil.
— Felixyz
7
Yang diperlukan hanyalah satu pengguna mengerahkan upaya dan kemudian menerbitkan atau membagikan rahasia Anda. Setelah rahasia Anda terungkap, risiko layanan Anda ditutup sepenuhnya karena penyalahgunaan meroket, dan itu benar-benar di luar kendali Anda.
— quasistoic
9
Kebingungan sama sekali bukanlah keamanan. Ini lebih buruk daripada tidak ada keamanan sama sekali, karena memberikan pengembang rasa aman yang palsu. en.wikipedia.org/wiki/Security_through_obscurity
— Paul Legato
9
"Kebingungan bukanlah keamanan sama sekali. Ini lebih buruk daripada tidak ada keamanan sama sekali, karena itu memberi pengembang rasa aman yang palsu." Omong kosong. Tidak ada yang mengatakan bahwa kebingungan menghasilkan keamanan yang baik. Tetapi jika saya akan mendistribusikan rahasia OAuth dengan apk saya, itu pasti lebih baik untuk disamarkan daripada tidak. Obfuscation adalah apa yang juga direkomendasikan Google saat menyimpan kunci / rahasia dalam aplikasi. Jika tidak ada yang lain, langkah-langkah ini mencegah peretas biasa, yang lebih baik daripada tidak sama sekali. Pernyataan menyeluruh seperti milik Anda menyamakan keamanan yang tidak sempurna dengan tanpa keamanan. Itu tidak benar. Tidak sempurna hanya tidak sempurna.
— kelaparan
2
Obfuscation TIDAK membantu, karena tidak peduli seberapa banyak pergeseran atau pengkodean yang Anda lakukan, Anda tetap membangun kunci bersama dan menggunakannya untuk membuat permintaan API Anda. Cukup mudah untuk secara dinamis mengaitkan API di tempat yang tepat untuk membuang permintaan yang Anda kirim bahkan sebelum enkripsi HTTPS. Jadi tolong, jangan sematkan kunci rahasia di aplikasi Anda kecuali memang tidak ada alternatif yang memungkinkan.
— C0deH4cker
6

Jangan simpan rahasia di dalam aplikasi.

Anda harus memiliki server yang dapat diakses oleh aplikasi melalui https (tentunya) dan Anda menyimpan rahasianya di dalamnya.

Ketika seseorang ingin masuk melalui aplikasi seluler / desktop Anda, aplikasi Anda hanya akan meneruskan permintaan ke server yang kemudian akan menambahkan rahasia dan mengirimkannya ke penyedia layanan. Server Anda kemudian dapat memberi tahu aplikasi Anda apakah berhasil atau tidak.

Kemudian jika Anda perlu mendapatkan informasi sensitif dari layanan (facebook, google, twitter, dll), aplikasi meminta server Anda dan server Anda akan memberikannya ke aplikasi hanya jika terhubung dengan benar.

Sebenarnya tidak ada pilihan lain kecuali menyimpannya di server. Tidak ada di sisi klien yang aman.

Catatan

Yang mengatakan, ini hanya akan melindungi Anda dari klien jahat tetapi bukan klien dari Anda yang jahat dan bukan klien dari klien jahat lainnya (phising) ...

OAuth adalah protokol yang jauh lebih baik di browser daripada di desktop / seluler.

— Gudradain
sumber
1
bukankah ini membuat hidup peretas lebih mudah ?! karena sekarang, untuk mengakses sumber daya server secara teknis kita hanya memerlukan id klien, karena server akan menambahkan rahasia ke permintaan. apakah saya melewatkan sesuatu?
— Hudi Ilfeld
@HudiIlfeld Ya, Anda melewatkan sesuatu: klien harus login ke server. Selama dia tidak masuk, server tidak akan mengembalikan apa pun. Salah satu cara untuk mengelolanya adalah setelah mengirim kredensial untuk pertama kalinya, server mengembalikan token akses ke klien dan kemudian klien mengirim token akses ini dengan setiap permintaan di masa mendatang. Ada banyak pilihan di sini.
— Gudradain
@Gudradain Saya tidak yakin bagaimana solusi Anda membantu di sini, karena semua itu bisa otomatis: 1) Klien mengirim client_id ke server. 2) Server mengembalikan Token Akses untuk Klien untuk mengirimkannya dalam permintaan berikutnya? Mengapa tepatnya? Tapi anggap saja tidak apa-apa. 3) Seorang peretas sekarang diautentikasi terhadap server, dan masih dapat membuat permintaan API / layanan apa pun yang diinginkannya, masih menyamar di belakang server proxy Anda. Apakah saya melewatkan sesuatu di sini?
— Ivo Pereira
@IvoPereira Menempatkan rahasia klien dalam aplikasi memudahkan untuk mencurinya. Setelah seseorang mengetahui id klien dan rahasia klien Anda, mereka dapat meniru identitas klien. Memvariasikan jumlah kerusakan dapat dilakukan jika seseorang menyamar sebagai klien, bergantung pada aplikasinya. Jika Anda ingin informasi lebih lanjut, saya sarankan Anda mengajukan pertanyaan lain (bukan komentar).
— Gudradain
@Gudradain Saya tidak menyarankan aliran yang tepat karena alasan yang Anda sebutkan, namun hanya menggunakan Proxy di tengah tidak akan menyelesaikan masalah untuk dirinya sendiri karena akan membuka pintu gratis lain untuk aktor yang buruk. Namun ini mungkin membantu mengurangi masalah: medium.com/@benjamin.botto/… (Arsitektur yang Disempurnakan -> Pertimbangan Keamanan)
— Ivo Pereira
4

Ada ekstensi baru untuk Jenis Pemberian Kode Otorisasi yang disebut Kunci Bukti untuk Pertukaran Kode (PKCE) . Dengan itu, Anda tidak memerlukan rahasia klien.

PKCE (RFC 7636) adalah teknik untuk mengamankan klien publik yang tidak menggunakan rahasia klien.

Ini terutama digunakan oleh aplikasi asli dan seluler, tetapi teknik ini dapat diterapkan ke klien publik mana pun juga. Ini membutuhkan dukungan tambahan oleh server otorisasi, sehingga hanya didukung pada penyedia tertentu.

dari https://oauth.net/2/pkce/

Untuk informasi lebih lanjut, Anda dapat membaca RFC 7636 lengkap atau pengantar singkat ini .

— Johannes Filter
sumber
Berhati-hatilah karena hal ini masih dapat menyebabkan Peniruan Identitas Klien: tools.ietf.org/html/rfc6749#section-10.2
— Ivo Pereira
2

Berikut sesuatu yang perlu dipikirkan. Google menawarkan dua metode OAuth ... untuk aplikasi web, tempat Anda mendaftarkan domain dan membuat kunci unik, dan untuk aplikasi terpasang tempat Anda menggunakan kunci "anonim".

Mungkin saya menyembunyikan sesuatu dalam pembacaan, tetapi tampaknya berbagi kunci unik aplikasi web Anda dengan aplikasi yang terpasang mungkin lebih aman daripada menggunakan "anonim" dalam metode aplikasi resmi yang terpasang.

— LetMyPeopleCode
sumber
2

Dengan OAuth 2.0 Anda cukup menggunakan alur sisi klien untuk mendapatkan token akses dan kemudian menggunakan token akses ini untuk mengautentikasi semua permintaan lebih lanjut. Maka Anda tidak membutuhkan rahasia sama sekali.

Penjelasan yang bagus tentang bagaimana menerapkan ini dapat ditemukan di sini: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

— Joel Richard
sumber
Asalkan layanan mendukung "aliran sisi klien". Banyak yang tidak melakukannya, sebagai gantinya membutuhkan ID klien dan rahasia klien untuk mendapatkan token akses ini.
— Damian Yerrick
0

Saya tidak memiliki banyak pengalaman dengan OAuth - tetapi bukankah setiap permintaan tidak hanya memerlukan token akses pengguna, tetapi juga kunci dan rahasia konsumen aplikasi? Jadi, bahkan jika seseorang mencuri perangkat seluler dan mencoba menarik datanya, mereka memerlukan kunci aplikasi dan rahasia juga untuk dapat melakukan apa pun.

Saya selalu berpikir niat di balik OAuth adalah agar setiap Tom, Dick, dan Harry yang memiliki mashup tidak harus menyimpan kredensial Twitter Anda dengan jelas. Saya pikir itu menyelesaikan masalah itu dengan cukup baik meskipun ada batasannya. Juga, itu tidak benar-benar dirancang dengan memikirkan iPhone.

— bpapa
sumber
Anda benar, sebagian besar OAuth dirancang dengan mempertimbangkan aplikasi web dan saya yakin OAuth berfungsi dengan baik untuk itu. Ya, Anda memerlukan token dan rahasia konsumen untuk menandatangani setiap permintaan, dan masalahnya adalah di mana menyimpan rahasia tersebut. Jika seseorang mencuri kunci akses, itu bukan masalah besar karena dapat dicabut, tetapi jika seseorang mendapatkan kunci konsumen, setiap salinan aplikasi Anda telah disusupi.
— Felixyz
OAuth 1 harus menandatangani setiap permintaan. OAuth 2 hanya membutuhkan token akses. Keduanya membutuhkan kunci dan rahasia saat memperoleh token.
— Dick Hardt
0

Saya setuju dengan Felixyz. OAuth sementara lebih baik daripada Basic Auth, masih memiliki jalan panjang untuk menjadi solusi yang baik untuk aplikasi seluler. Saya telah bermain-main dengan menggunakan OAuth untuk mengautentikasi aplikasi ponsel ke aplikasi Google App Engine. Fakta bahwa Anda tidak dapat dengan andal mengelola rahasia konsumen di perangkat seluler berarti bahwa defaultnya adalah menggunakan akses 'anonim'.

Langkah otorisasi browser penerapan Google App Engine OAuth membawa Anda ke laman yang berisi teks seperti: "Situs <some-site> meminta akses ke Akun Google Anda untuk produk yang tercantum di bawah"

YourApp (yourapp.appspot.com) - tidak berafiliasi dengan Google

dll

Ini mengambil <some-site> dari nama domain / host yang digunakan di url callback yang Anda berikan, yang bisa berupa apa saja di Android jika Anda menggunakan skema kustom untuk mencegat callback. Jadi, jika Anda menggunakan akses 'anonim' atau rahasia konsumen Anda disusupi, siapa pun dapat menyurati konsumen yang menipu pengguna agar memberikan akses ke aplikasi gae Anda.

Halaman otorisasi Google OAuth juga berisi banyak peringatan yang memiliki 3 tingkat keparahan tergantung pada apakah Anda menggunakan 'anonim', rahasia konsumen, atau kunci publik.

Hal yang cukup menakutkan bagi rata-rata pengguna yang tidak paham secara teknis. Saya tidak berharap memiliki persentase penyelesaian pendaftaran yang tinggi dengan hal-hal semacam itu.

Entri blog ini menjelaskan bagaimana rahasia konsumen tidak benar-benar berfungsi dengan aplikasi yang terpasang. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

— Martin Bayly
sumber
0

Saya juga mencoba menemukan solusi untuk otentikasi OAuth seluler, dan menyimpan rahasia dalam bundel aplikasi secara umum.

Dan ide gila baru saja menghantam saya: Ide paling sederhana adalah menyimpan rahasia di dalam biner, tetapi entah bagaimana disamarkan, atau, dengan kata lain, Anda menyimpan rahasia terenkripsi. Jadi, itu berarti Anda harus menyimpan kunci untuk mendekripsi rahasia Anda, yang tampaknya telah membawa kami pada lingkaran penuh. Namun, mengapa tidak menggunakan kunci yang sudah ada di OS, yaitu ditentukan oleh OS bukan oleh aplikasi Anda.

Jadi, untuk memperjelas ide saya adalah Anda memilih string yang ditentukan oleh OS, tidak masalah yang mana. Kemudian enkripsi rahasia Anda menggunakan string ini sebagai kuncinya, dan simpan di aplikasi Anda. Kemudian selama runtime, dekripsi variabel menggunakan kunci, yang hanya merupakan konstanta OS. Setiap peretas yang mengintip biner Anda akan melihat string terenkripsi, tetapi tidak ada kunci.

Apakah itu akan berhasil?

— Daniel Thorpe
sumber
4
Pemikiran bagus, tapi tidak. Cracker hanya akan melihat biner menunjuk ke alamat konstanta OS.
— GrayB
0

Tak satu pun dari solusi ini mencegah peretas yang ditentukan untuk mengendus paket yang dikirim dari perangkat seluler (atau emulator) mereka untuk melihat rahasia klien di header http.

Salah satu solusinya adalah memiliki rahasia dinamis yang terdiri dari stempel waktu yang dienkripsi dengan kunci & algoritme enkripsi 2 arah pribadi. Layanan kemudian mendekripsi rahasia dan menentukan apakah stempel waktunya +/- 5 menit.

Dengan cara ini, bahkan jika rahasianya dikompromikan, peretas hanya akan dapat menggunakannya selama maksimal 5 menit.

— Maximvs
sumber
-3

Seperti yang telah disebutkan orang lain, seharusnya tidak ada masalah nyata dengan menyimpan rahasia secara lokal di perangkat.

Selain itu, Anda selalu dapat mengandalkan model keamanan Android berbasis UNIX: hanya aplikasi Anda yang dapat mengakses apa yang Anda tulis ke sistem file. Cukup tulis infonya ke objek SharedPreferences default aplikasi Anda.

Untuk mendapatkan rahasianya, seseorang harus mendapatkan akses root ke ponsel Android.

— Christopher Orr
sumber
3
Seperti yang disebutkan? Jika yang Anda maksud adalah komentar poke, lihat jawaban saya rahasia itu! = Kunci otentikasi. Yang terakhir bisa disimpan dengan aman, yang pertama tidak bisa. Saya tidak tahu tentang Android, tetapi mendapatkan akses root ke iPhone sama sekali tidak sulit. Perhatikan bahwa rahasianya sama di semua contoh aplikasi, jadi penyerang hanya perlu mendapatkan akses ke satu biner. Dan bahkan jika mereka tidak dapat memperoleh akses root pada perangkat, mereka dapat menggunakan biner lain dan menarik token rahasia dari perangkat itu.
— Felixyz
1
hanya untuk menambahkannya, sangat mudah untuk melakukan root pada ponsel android juga
— kgutteridge
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.