Praktik terbaik untuk menyimpan dan melindungi kunci API pribadi di aplikasi [ditutup]


373

Sebagian besar pengembang aplikasi akan mengintegrasikan beberapa perpustakaan pihak ketiga ke dalam aplikasi mereka. Jika ingin mengakses layanan, seperti Dropbox atau YouTube, atau untuk penebangan macet. Jumlah perpustakaan dan layanan pihak ketiga sangat mengejutkan. Sebagian besar perpustakaan dan layanan diintegrasikan dengan entah bagaimana mengotentikasi dengan layanan, sebagian besar waktu, ini terjadi melalui kunci API. Untuk tujuan keamanan, layanan biasanya menghasilkan publik dan swasta, sering juga disebut sebagai kunci rahasia. Sayangnya, untuk terhubung ke layanan, kunci pribadi ini harus digunakan untuk otentikasi dan karenanya, mungkin menjadi bagian dari aplikasi. Tak perlu dikatakan, bahwa ini menghadapi masalah keamanan besar. Kunci API publik dan pribadi dapat diekstraksi dari APK dalam hitungan menit dan dapat dengan mudah diotomatisasi.

Dengan asumsi saya memiliki sesuatu yang mirip dengan ini, bagaimana saya bisa melindungi kunci rahasia:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

Menurut Anda, apa cara terbaik dan paling aman untuk menyimpan kunci pribadi? Kebingungan, enkripsi, bagaimana menurut Anda?



saya telah menyimpan dalam gambar / png dan mendapatkan kunci melalui png sebagai BufferReader
Sumit

Saya pikir ini adalah masalah yang sah dan memposting masalah serupa di halaman github Android SDK Firebase: github.com/firebase/firebase-android-sdk/issues/1583 . Mari kita lihat apakah ini ditangani.
grebulon

Jawaban:


348
  1. Karena itu, aplikasi Anda yang dikompilasi berisi string kunci, tetapi juga nama konstan APP_KEY dan APP_SECRET. Mengekstrak kunci dari kode yang mendokumentasikan diri sendiri itu sepele, misalnya dengan alat Android standar dx.

  2. Anda dapat menerapkan ProGuard. Ini akan membuat string kunci tidak tersentuh, tetapi itu akan menghapus nama konstan. Itu juga akan mengganti nama kelas dan metode dengan nama pendek, tidak berarti, jika memungkinkan. Mengekstrak kunci kemudian membutuhkan waktu lebih lama, untuk mencari tahu string mana yang melayani tujuan mana.

    Perhatikan bahwa pengaturan ProGuard seharusnya tidak sesulit yang Anda takutkan. Untuk memulainya, Anda hanya perlu mengaktifkan ProGuard, seperti yang didokumentasikan dalam project.properties. Jika ada masalah dengan perpustakaan pihak ketiga, Anda mungkin perlu menekan beberapa peringatan dan / atau mencegahnya dikaburkan, di proguard-project.txt. Contohnya:

    -dontwarn com.dropbox.**
    -keep class com.dropbox.** { *; }

    Ini adalah pendekatan brute-force; Anda dapat memperbaiki konfigurasi tersebut setelah aplikasi yang diproses berfungsi.

  3. Anda dapat mengaburkan string secara manual dalam kode Anda, misalnya dengan pengkodean Base64 atau lebih disukai dengan sesuatu yang lebih rumit; bahkan mungkin kode asli. Seorang peretas kemudian harus secara terbalik merekayasa encoding Anda atau secara dinamis mencegat decoding di tempat yang tepat.

  4. Anda dapat menerapkan obfuscator komersial, seperti saudara khusus ProGuard, DexGuard . Selain itu dapat mengenkripsi / mengaburkan string dan kelas untuk Anda. Mengekstrak kunci kemudian membutuhkan lebih banyak waktu dan keahlian.

  5. Anda mungkin dapat menjalankan sebagian aplikasi Anda di server Anda sendiri. Jika Anda dapat menyimpan kunci di sana, mereka aman.

Pada akhirnya, ini adalah trade-off ekonomi yang harus Anda buat: seberapa penting kunci, berapa banyak waktu atau perangkat lunak yang Anda mampu, seberapa canggih peretas yang tertarik pada kunci, berapa banyak waktu yang mereka inginkan belanjakan, berapa nilainya penundaan sebelum kunci diretas, pada skala apa peretas yang berhasil akan mendistribusikan kunci, dll. Informasi kecil seperti kunci lebih sulit untuk dilindungi daripada seluruh aplikasi. Pada dasarnya, tidak ada yang ada di sisi klien yang tidak bisa dipecahkan, tetapi Anda tentu dapat meningkatkannya.

(Saya adalah pengembang ProGuard dan DexGuard)


2
@EricLafortune tidak membuat perbedaan jika string kunci pribadi disimpan di kelas Java vs di XML sumber daya string?
Alan

1
@EricLafortune Apakah sekarang mungkin menggunakan sistem Android Keystore untuk menyimpan kunci dengan aman? ( developer.android.com/training/articles/keystore.html )
David Thomas

1
@ Davidvidomas: Apakah Anda mencoba menggunakan keystore. Saya ingin mengaburkan kunci API yang ditulis dalam kelas Java. Harap balas
Sagar Trehan

1
Apakah Android KeyStore bermanfaat untuk ini? ( developer.android.com/training/articles/… )
Weishi Zeng

1
Saya tidak mengerti # 5. Tidakkah ia memiliki masalah yang sama persis dengan masalah aslinya?
pete

80

Beberapa ide, menurut saya hanya yang pertama memberikan jaminan:

  1. Simpan rahasia Anda di beberapa server di internet, dan bila perlu ambil saja dan gunakan. Jika pengguna akan menggunakan dropbox maka tidak ada yang menghentikan Anda dari membuat permintaan ke situs Anda dan mendapatkan kunci rahasia Anda.

  2. Masukkan rahasia Anda dalam kode jni, tambahkan beberapa kode variabel untuk membuat perpustakaan Anda lebih besar dan lebih sulit untuk didekompilasi. Anda juga dapat memisahkan string kunci menjadi beberapa bagian dan menyimpannya di berbagai tempat.

  3. menggunakan obfuscator, juga memasukkan kode hash rahasia dan kemudian melepasnya ketika dibutuhkan untuk digunakan.

  4. Masukkan kunci rahasia Anda sebagai piksel terakhir dari salah satu gambar Anda di aset. Kemudian ketika perlu membacanya di kode Anda. Mengacaukan kode Anda akan membantu menyembunyikan kode yang akan membacanya.

Jika Anda ingin melihat sekilas betapa mudahnya membaca kode apk Anda, lalu ambil APKAnalyser:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/


46
jika pengguna dapat mendekompilasi aplikasi meskipun mereka mungkin dapat menentukan permintaan yang dibuat ke server Anda sendiri dan hanya menjalankannya untuk mendapatkan rahasia. Tidak ada peluru perak di sini, tetapi ambil beberapa langkah dan saya yakin Anda akan baik-baik saja! Jika aplikasi Anda sangat populer meskipun mungkin tidak .. Ide bagus!
Matt Wolfe

3
ya, nomor 1 tidak memberikan jaminan.
marcinj

42
Saya sangat suka gagasan menyembunyikan kunci di dalam gambar. +1
Igor Čordaš

1
@ MarcinJędrzejewski Apakah Anda ingin menjelaskan lebih banyak (dengan sampel atau potongan kode) tentang solusi sebagainya? Terima kasih.
Dr.jacky

2
@ Mr.Hyde ini disebut steganografi, terlalu rumit untuk memberikan kode sampel di sini, Anda dapat menemukan contoh di google. Saya telah menemukan satu di sini: dreamincode.net/forums/topic/27950-steganography . Idenya bagus, tetapi karena kode apk dapat didekompilasi, ia merusak keindahannya.
marcinj

32

Pendekatan lain adalah tidak memiliki rahasia pada perangkat di tempat pertama! Lihat Teknik Keamanan API Seluler (terutama bagian 3).

Menggunakan tradisi tipuan waktu yang dihormati, bagikan rahasia antara titik akhir API Anda dan layanan otentikasi aplikasi.

Ketika klien Anda ingin membuat panggilan API , ia meminta layanan auth app untuk mengautentikasi (menggunakan teknik pengesahan jarak jauh yang kuat), dan menerima token waktu terbatas (biasanya JWT ) yang ditandatangani oleh rahasia.

Token dikirim dengan setiap panggilan API di mana titik akhir dapat memverifikasi tanda tangannya sebelum bertindak atas permintaan.

Rahasia sebenarnya tidak pernah ada pada perangkat; pada kenyataannya, aplikasi tidak pernah tahu apakah itu valid atau tidak, itu menjorok permintaan otentikasi dan meneruskan token yang dihasilkan. Sebagai manfaat bagus dari tipuan, jika Anda ingin mengubah rahasia, Anda dapat melakukannya tanpa mengharuskan pengguna untuk memperbarui aplikasi yang diinstal.

Jadi, jika Anda ingin melindungi rahasia Anda, tidak memilikinya di aplikasi Anda di tempat pertama adalah cara yang cukup baik untuk pergi.


5
Ini harus menjadi jawaban yang diterima.
ortonomy

4
Masalahnya berlanjut ketika Anda ingin mengakses layanan otentikasi. Ini akan memberi Anda id klien dan rahasia klien. Di mana kita harus menyelamatkan mereka?
Ashi

tidak menyelesaikan apis pribadi tempat Anda perlu mengautentikasi ke api Anda terlebih dahulu untuk menggunakannya. dari mana Anda mendapatkan kredensial untuk semua pengguna aplikasi?
Kibotu

25

Cara tidak aman lama:

Ikuti 3 langkah sederhana untuk mengamankan API / Kunci rahasia ( Jawaban lama )

Kita dapat menggunakan Gradle untuk mengamankan kunci API atau kunci Rahasia.

1. gradle.properties (Properti proyek): Buat variabel dengan kunci.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Module: app): Setel variabel di build.gradle untuk mengaksesnya dalam aktivitas atau fragmen. Tambahkan kode di bawah ini ke buildTypes {}.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Akses di Aktivitas / Fragmen oleh BuildConfig aplikasi:

BuildConfig.GoogleSecAPIKEY

Perbarui:

Solusi di atas sangat membantu dalam proyek open source untuk melakukan lebih dari Git. (Terima kasih kepada David Rawson dan riyaz-ali untuk komentar Anda).

Sesuai komentar Matthew dan Pablo Cegarra cara di atas tidak aman dan Decompiler akan memungkinkan seseorang untuk melihat BuildConfig dengan kunci rahasia kami.

Solusi:

Kita dapat menggunakan NDK untuk Mengamankan Kunci API. Kita bisa menyimpan kunci di kelas C / C ++ asli dan mengaksesnya di kelas Java kita.

Ikuti blog ini untuk mengamankan kunci API menggunakan NDK.

Tindak lanjut tentang cara menyimpan token dengan aman di Android


4
menyimpan kunci dalam file gradle aman?
Google

4
@Google gradle.propertiesseharusnya tidak masuk ke Git jadi ini adalah cara untuk menjaga rahasia dari kode sumber yang berkomitmen, setidaknya
David Rawson

4
Ini tidak mencegah kunci API dari digabungkan ke dalam hasil apk(itu akan ditambahkan ke BuildConfigfile yang dihasilkan ), meskipun ini jelas merupakan ide yang baik untuk mengelola kunci API yang berbeda (untuk misalnya dalam proyek open source)
riyaz-ali

5
Menggunakan Java Decompiler akan memungkinkan seseorang untuk melihat file BuildConfig dan "GoogleSecAPIKEY"
Matthew

3
BuildConfig.javaFile Anda akan memiliki kunci dalam bentuk teks biasa. Ini tidak lebih baik dari apa yang sudah dilakukan OP.
iceman

16

Kunci App-Secret harus dirahasiakan - tetapi ketika merilis aplikasi mereka dapat dibalik oleh beberapa orang.

bagi mereka yang tidak akan disembunyikan, kunci salah ProGuardsatu kode. Ini adalah refactor dan beberapa obfuscator berbayar memasukkan beberapa operator bitwise untuk mendapatkan kembali jk433g34hg3 String. Anda dapat membuat 5 -15 menit lebih lama peretasan jika Anda bekerja 3 hari :)

Cara terbaik adalah tetap seperti itu, imho.

Bahkan jika Anda menyimpan di sisi server (PC Anda) kuncinya dapat diretas dan dicetak. Mungkin ini yang paling lama? Bagaimanapun itu adalah masalah beberapa menit atau beberapa jam dalam kasus terbaik.

Pengguna normal tidak akan mendekompilasi kode Anda.


1
Yah - bukan jawaban yang saya harapkan =) ... Saya pikir Anda dapat mencapai keamanan yang hebat :(
Basic Coder

maaf itu bukan seperti yang Anda inginkan, solusi ultra aman brilian, tetapi bagi mereka yang dapat menggunakan kompiler, decompiler tidak ada kode java yang aman: bahkan kode asli dapat dilihat dengan hexa viewer dan didekripsi. Setidaknya patut dicoba ...

1
Proguard tidak akan mengaburkan kunci yang sebenarnya ..? Hal terbaik untuk dilakukan adalah beberapa rutin sederhana enkripsi / dekripsi, yang membingungkan akan disembunyikan.
Doomsknight

3
itu adalah "terlihat" rutin dekripsi, mudah untuk membuat kebalikannya dan Anda memiliki string asli

14

Salah satu solusi yang mungkin adalah menyandikan data di aplikasi Anda dan menggunakan decoding saat runtime (saat Anda ingin menggunakan data itu). Saya juga merekomendasikan untuk menggunakan progaurd untuk membuatnya sulit untuk membaca dan memahami kode sumber aplikasi Anda. misalnya saya meletakkan kunci yang dikodekan dalam aplikasi dan kemudian menggunakan metode decode di aplikasi saya untuk memecahkan kode kunci rahasia saya pada saat runtime:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

Kode sumber yang didekompilasi dari aplikasi proguard adalah ini:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

Setidaknya itu cukup rumit untukku. ini adalah cara yang saya lakukan ketika saya tidak punya pilihan selain menyimpan nilai dalam aplikasi saya. Tentu saja kita semua tahu Ini bukan cara terbaik tetapi ini bekerja untuk saya.

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Versi terdekompilasi:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

dan Anda dapat menemukan begitu banyak kelas enkripsi dengan sedikit pencarian di google.


13

Menambahkan ke solusi @Manohar Reddy, Firebase Database atau firebase RemoteConfig (dengan nilai default Null) dapat digunakan:

  1. Sandi kunci Anda
  2. Simpan di basis data firebase
  3. Dapatkan saat startup Aplikasi atau kapan pun diperlukan
  4. menguraikan kunci dan menggunakannya

Apa yang berbeda dalam solusi ini?

  • tidak ada kredibilitas untuk firebase
  • akses firebase dilindungi sehingga hanya aplikasi dengan sertifikat yang ditandatangani yang memiliki hak istimewa untuk melakukan panggilan API
  • ciphering / deciphering untuk mencegah intersepsi orang tengah. Namun panggilan sudah https ke firebase

dengan segala hormat terhadap solusi ini kami masih alun-alun pertama. Alih-alih menggunakan kredensial, Anda menyarankan untuk menggunakan sertifikat. Siapa pun yang mampu mencuri kredensial Anda, mampu mencuri sertifikat yang Anda tandatangani.
Ashi

Namun satu keuntungan, dengan solusi yang disarankan, kami menambahkan satu lagi komplikasi di depan peretas.
Ashi

11

Contoh ini memiliki sejumlah aspek berbeda. Saya akan menyebutkan beberapa poin yang saya pikir tidak secara eksplisit dibahas di tempat lain.

Melindungi rahasia dalam perjalanan

Hal pertama yang perlu diperhatikan adalah bahwa mengakses API dropbox menggunakan mekanisme autentikasi aplikasi mereka mengharuskan Anda untuk mengirimkan kunci dan rahasia Anda. Koneksi adalah HTTPS yang berarti bahwa Anda tidak dapat mencegat lalu lintas tanpa mengetahui sertifikat TLS. Ini untuk mencegah seseorang mencegat dan membaca paket-paket dalam perjalanan mereka dari perangkat seluler ke server. Untuk pengguna normal, ini adalah cara yang sangat baik untuk memastikan privasi lalu lintas mereka.

Apa yang tidak pandai, adalah mencegah orang jahat mengunduh aplikasi dan memeriksa lalu lintas. Sangat mudah untuk menggunakan proxy man-in-the-middle untuk semua lalu lintas masuk dan keluar dari perangkat seluler. Tidak diperlukan pembongkaran atau rekayasa balik kode untuk mengekstrak kunci aplikasi dan rahasia dalam hal ini karena sifat API Dropbox.

Anda dapat melakukan pinning yang memeriksa bahwa sertifikat TLS yang Anda terima dari server adalah yang Anda harapkan. Ini menambahkan cek ke klien dan membuatnya lebih sulit untuk mencegat lalu lintas. Ini akan membuat lebih sulit untuk memeriksa lalu lintas dalam penerbangan, tetapi pemeriksaan pinning terjadi pada klien, sehingga kemungkinan masih mungkin untuk menonaktifkan tes pinning. Itu memang membuatnya lebih sulit.

Melindungi rahasia saat istirahat

Sebagai langkah pertama, menggunakan sesuatu seperti proguard akan membantu memperjelas di mana rahasia disimpan. Anda juga dapat menggunakan NDK untuk menyimpan kunci dan rahasia dan mengirim permintaan secara langsung, yang akan sangat mengurangi jumlah orang dengan keterampilan yang sesuai untuk mengekstraksi informasi. Kebingungan lebih lanjut dapat dicapai dengan tidak menyimpan nilai-nilai secara langsung dalam memori untuk waktu yang lama, Anda dapat mengenkripsi dan mendekripsi mereka sebelum digunakan seperti yang disarankan oleh jawaban lain.

Opsi lebih lanjut

Jika Anda sekarang paranoid tentang menyimpan rahasia di mana saja di aplikasi Anda, dan Anda punya waktu dan uang untuk berinvestasi dalam solusi yang lebih komprehensif, maka Anda dapat mempertimbangkan menyimpan kredensial di server Anda (anggap Anda punya). Ini akan meningkatkan latensi panggilan apa pun ke API, karena harus berkomunikasi melalui server Anda, dan dapat meningkatkan biaya menjalankan layanan Anda karena peningkatan throughput data.

Anda kemudian harus memutuskan cara terbaik untuk berkomunikasi dengan server Anda untuk memastikan mereka terlindungi. Ini penting untuk mencegah semua masalah yang sama muncul lagi dengan API internal Anda. Aturan praktis terbaik yang bisa saya berikan adalah tidak mengirimkan rahasia apa pun secara langsung karena ancaman lelaki di tengah. Alih-alih, Anda dapat menandatangani lalu lintas menggunakan rahasia Anda dan memverifikasi integritas permintaan apa pun yang datang ke server Anda. Salah satu cara standar untuk melakukan ini adalah dengan menghitung HMAC dari pesan yang dikunci pada sebuah rahasia. Saya bekerja di sebuah perusahaan yang memiliki produk keamanan yang juga beroperasi di bidang ini yang mengapa hal semacam ini menarik minat saya. Sebenarnya, di sini ada artikel blog dari salah satu kolega saya yang membahas sebagian besar dari ini.

Berapa yang harus saya lakukan?

Dengan saran keamanan seperti ini, Anda perlu membuat keputusan biaya / manfaat tentang seberapa keras Anda ingin membuatnya agar bisa didobrak. Jika Anda bank yang melindungi jutaan pelanggan, anggaran Anda sama sekali berbeda dengan seseorang yang mendukung aplikasi di waktu luang. Sebenarnya tidak mungkin untuk mencegah seseorang merusak keamanan Anda, tetapi dalam praktiknya hanya sedikit orang yang membutuhkan semua lonceng dan peluit dan dengan beberapa tindakan pencegahan dasar Anda bisa menempuh jalan panjang.


1
Anda cukup menyalin dan menempel ini dari sini: hackernoon.com/mobile-api-security-technology-682a5da4fe10 tanpa mengakui sumbernya.
ortonomy

1
@ortonomy Saya setuju bahwa dia seharusnya mengutip artikel yang Anda tautkan, tetapi dia mungkin lupa karena keduanya bekerja di tempat yang sama ...
Exadra37

2
Juga artikel Skip dan posting blog mereka didasarkan keluar seminggu setelah jawaban saya.
ThePragmatist

8

Solusi paling aman adalah menyimpan kunci Anda di server dan merutekan semua permintaan yang membutuhkan kunci itu melalui server Anda. Dengan begitu kunci tidak pernah meninggalkan server Anda, jadi selama server Anda aman maka kunci Anda juga. Tentu saja ada biaya kinerja dengan solusi ini.


32
Masalahnya adalah - untuk mencapai server yang berisi semua rahasia saya harus menggunakan Kunci Rahasia lainnya - Saya ingin tahu di mana saya akan menyimpannya? ;) Yang ingin saya katakan adalah - Ini juga bukan solusi terbaik (jangan berpikir ada solusi ideal di sini)
Mercury

Itu tidak benar, server Anda sepenuhnya di bawah kendali Anda. Yang dibutuhkan sepenuhnya terserah Anda.
Bernard Igiri

5
Bisakah Anda jelaskan di sini bagaimana klien dapat mengenkripsi data yang ingin ia kirim ke server, sementara kuncinya ada di sisi server? dan jika jawaban Anda adalah - Server mengirim kunci ke klien - Jadi itu harus diamankan juga! jadi sekali lagi tidak ada solusi ajaib! tidak bisakah kamu melihat ?!
Merkurius

2
@BernardIgiri dan sekali lagi kita kembali ke titik 1. Mari kita asumsikan, telepon membuat login acak dan server menerima itu dan mengirimkan pin (Ini adalah server pribadi yang kita bicarakan). Kemudian orang yang membongkar aplikasi Anda melihat bahwa yang diperlukan untuk mengakses server pribadi Anda hanyalah beberapa login acak yang dapat ia buat sendiri. Katakan padaku apa yang membuatnya berhenti membuat dan mengakses server Anda? Sebenarnya apa perbedaan antara solusi Anda dan menyimpan kunci login atau api ke server utama (yang kredensialnya ingin kami simpan di server pribadi kami)
Ken

3
@ken Nomor acak diautentikasi dengan nomor telepon dan akses fisik ke pesan teksnya. Jika seseorang menipu Anda, Anda memiliki informasi mereka. Jika itu tidak cukup baik, paksakan mereka untuk membuat akun dan kata sandi pengguna penuh. Jika itu tidak cukup baik, dapatkan kartu kredit juga. Jika itu tidak cukup baik, mintalah mereka menelepon. Jika itu tidak cukup baik, temui mereka secara langsung. Seberapa aman / nyaman yang Anda inginkan?
Bernard Igiri

7

Jaga kerahasiaan firebase databasedan dapatkan darinya saat aplikasi dimulai, Ini jauh lebih baik daripada memanggil layanan web.


13
tapi bagaimana dengan kredensial ke firebase?
the_joric

2
Sayangnya, basis data Firebase tidak berfungsi di Tiongkok.
Konjengbam

9
tidak masuk akal, penyerang dapat melihat detail firebase Anda dari kode yang didekompilasi dan mendapatkan data dari datababse Anda
user924

3
Saya pikir ini adalah solusi terbaik karena Firebase Apps menggunakan SHA1 untuk memungkinkan akses ke server. Mengurai kode tidak akan membantu membuat panggilan ke firebase karena peretas aplikasi baru harus menggunakan stempel aplikasi yang tepat untuk mengakses firebase. Juga, kunci yang disimpan harus diacak sebelum disimpan di firebase DB dan diuraikan setelah diterima untuk menghindari intersepsi orang tengah.
Ayman Al-Absi

Ketika Anda mendapatkan rahasia dari basis data firebase melalui jaringan, bagaimana caranya lebih aman daripada mendapatkan rahasia yang sama dari layanan web lain melalui saluran aman (https)? Bisakah Anda jelaskan?
Csaba Toth

6

Apa pun yang Anda lakukan untuk mengamankan kunci rahasia Anda tidak akan menjadi solusi nyata. Jika pengembang dapat mendekompilasi aplikasi tidak ada cara untuk mengamankan kunci, menyembunyikan kunci hanya keamanan dengan ketidakjelasan dan begitu juga kode kebingungan. Masalah dengan pengamanan kunci rahasia adalah bahwa untuk mengamankannya Anda harus menggunakan kunci lain dan kunci itu juga harus diamankan. Pikirkan kunci yang disembunyikan di dalam kotak yang dikunci dengan kunci. Anda menempatkan kotak di dalam ruangan dan mengunci ruangan. Anda dibiarkan dengan kunci lain untuk mengamankan. Dan kunci itu masih akan dikodekan dalam aplikasi Anda.

Jadi, kecuali jika pengguna memasukkan PIN atau frasa, tidak ada cara untuk menyembunyikan kunci. Tetapi untuk melakukan itu Anda harus memiliki skema untuk mengelola PIN yang terjadi di luar jalur, yang berarti melalui saluran yang berbeda. Tentu tidak praktis untuk mengamankan kunci untuk layanan seperti Google API.


5

Posting lama, tapi masih cukup bagus. Saya pikir menyembunyikannya di perpustakaan .so akan menjadi besar, menggunakan NDK dan C ++ tentu saja. File .so dapat dilihat dalam hex editor, tetapi semoga berhasil mendekompilasi bahwa: P


9
Pengguna dapat dengan mudah melakukan panggilan fungsi ke perpustakaan bersama dan mendapatkan apa pun yang bersembunyi di sana. Tidak perlu men-decopile-kannya.
david72

5
Menurut androidauthority.com/... saat ini tidak ada cara aman untuk melakukannya di android.
david72

1
@AhmedAwad Tidak mengerti mengapa ini mengalami 3 peningkatan. siapa pun dapat dengan mudah mendekompilasi aplikasi dan melihat bagaimana titik masuk ndk dipanggil: /
Johny19

1
Jawaban ini hampir merupakan salah satu opsi terbaik, tetapi penulis harus menyebutkan bahwa sangat penting bahwa Anda harus menyertakan panggilan (di dalam perpustakaan NDK Anda) untuk melihat apakah checksum cocok dengan APK Anda karena jika tidak, seseorang dapat memanggil perpustakaan NDK Anda di luar aplikasi Anda
Stoycho Andreev

@Sniper itu bagus, kecuali ada masalah besar. Bagaimana Anda tahu file apa yang "memanggil" metode asli? Jika Anda sulit membuat kode nama apk untuk diperiksa, bagus, tetapi bagaimana jika saya membuat apk "retas" folder yang sama dengan apk "baik"? Itu akan memeriksa bahwa apk "baik" memiliki checksum yang baik, dan itu akan memungkinkan saya untuk mengeksekusi metode asli itu. Kecuali ada cara untuk mengetahui file pemanggil dari sisi JNI / C ++, maka itu tidak ada gunanya seperti opsi lainnya.
SocketByte

5

Satu-satunya cara sebenarnya untuk merahasiakan ini adalah dengan menyimpannya di server Anda, dan minta aplikasi mengirim apa pun itu ke server, dan server berinteraksi dengan Dropbox. Dengan begitu Anda TIDAK PERNAH mendistribusikan kunci pribadi Anda dalam format apa pun.


11
Tetapi bagaimana Anda mencegah orang lain memanggil server?
user2966445

Jika dengan "server" yang Anda maksud server web Anda di mana kredensial berada - Anda dapat menggunakan metode apa pun yang Anda inginkan. otentikasi sederhana dengan nama pengguna / kata sandi, oauth, direktori aktif, dll. Sangat tergantung pada aplikasi Anda.
Nick

Mungkin saya kehilangan sesuatu, tetapi tidakkah ini masih membutuhkan penyimpanan kredensial dalam aplikasi?
user2966445

3
Benar, tetapi Anda mengatakan aplikasi akan mengotentikasi dengan server terlebih dahulu. Tidakkah ini berarti menyimpan set kredensial lain dalam aplikasi? Saya mengerti server akan menangani panggilan dropbox yang sebenarnya.
user2966445

4
Yah, itu bisa berarti itu, tetapi itu otorisasi yang benar-benar terpisah. Tetapi Anda tidak harus melakukannya. Penggunaan kata kunci yang saya bicarakan adalah bahwa pengguna aplikasi Anda akan memiliki login ke aplikasi Anda, misalnya menggunakan facebook atau twitter. Anda tidak menyimpan kredensial mereka di aplikasi Anda, Anda bahkan tidak mengenalnya. Proses otorisasi itu memungkinkan mereka mengakses server api Anda, yang memiliki kredensial untuk dropbox, tetapi tidak ada aplikasi atau pengguna yang memiliki akses langsung ke mereka.
Nick

0

Berdasarkan pengalaman pahit, dan setelah berkonsultasi dengan ahli IDA-Pro solusi terbaik adalah memindahkan bagian kunci dari kode ke dalam DLL / SharedObject, kemudian mengambilnya dari server dan memuat saat runtime.

Data sensitif harus disandikan karena sangat mudah untuk melakukan sesuatu seperti ini:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD

3
Dan di mana Anda menyimpan kredensial untuk server tersebut?
ZX9
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.