it-swarm-id.com

Cara menerapkan Mekanisme API-Key

pertama-tama: Saya tidak yakin tentang judul pertanyaan, jadi jika Anda memiliki ide yang lebih baik, jangan ragu untuk memberi tahu (:

Saya ingin tahu tentang contoh praktik terbaik di mana layanan (seperti Twitter atau rekan) yang menawarkan API dan ingin Anda sebagai pengembang menggunakan beberapa API-Key mencegah pihak ketiga mendapatkan kunci itu.

Saya akan menjelaskan salam saya dengan contoh-contoh buruk:

Sejauh yang saya tahu, Twitter dan FB mengharuskan Anda untuk menggunakan API-Keys untuk permintaan API. Itu bagus untuk aplikasi sisi server, tetapi segera setelah Anda mengirimkan kunci dari aplikasi web atau aplikasi desktop, kuncinya dapat dilihat oleh orang lain.

Karena Anda harus mengirimkan kunci itu, tidak masuk akal untuk menyimpannya dengan super aman di dalam aplikasi Anda. Untuk permintaan, itu harus jelas.

Satu hal yang mungkin Anda lakukan adalah meng-host layanan web atau pembungkus Anda sendiri yang menambahkan sisi server utama dan kemudian merutekan permintaan itu ke server target.

Tetapi ini tidak mungkin jika Twitter/atau layanan apa pun yang Anda gunakan membatasi permintaan API per IP atau ingin membuat statistik berbasis IP.

Jadi untuk meringkasnya: Jika saya berada di posisi untuk membuat API untuk orang lain dan tidak ingin mereka menggunakan SSL, kemungkinan apa yang harus saya pastikan kunci mereka aman dan tidak dapat dengan mudah dicuri ?

34
user510083

Praktik terbaik adalah:

Ide dasarnya. Buat kunci API (kunci simetris 128-bit) untuk setiap akun pengguna yang terpisah. Kunci ini perlu disimpan dengan aman di server, dan juga disimpan dengan aman di klien pengguna.

Untuk setiap permintaan yang dibuat oleh klien, tambahkan parameter permintaan tambahan yang memiliki "tanda tangan" pada seluruh permintaan. "Tanda tangan" harus dihitung sebagai S = MAC ( [~ # ~] k [~ # ~], [~ # ~] r [~ # ~]), di mana [~ # ~] k [~ # ~] adalah kunci API dan [~ # ~] r [~ # ~] = adalah seluruh permintaan, termasuk semua parameter permintaan. Di sini MAC harus menjadi algoritma kode otentikasi pesan aman, seperti AES-CMAC atau SHA1-HMAC.

Adalah tanggung jawab klien untuk menghitung tanda tangan dan menambahkannya ke permintaan; server bertanggung jawab untuk memverifikasi tanda tangan dan mengabaikan permintaan apa pun dengan tanda tangan yang tidak valid. Anda juga mungkin perlu memasukkan parameter tambahan dengan permintaan yang mengidentifikasi akun pengguna yang membuat permintaan.

Ini akan memberikan otentikasi permintaan, tetapi bukan kerahasiaan atau pencegahan replay, dan klien memang menerima respons terotentikasi dari server.

Saya sarankan mengirim semua permintaan melalui https (bukan http). Ini akan memberikan tingkat keamanan tambahan terhadap sejumlah kasus rumit. Implikasi kinerja dari melakukan ini kurang dari yang Anda kira - SSL memiliki overhead kinerja lebih sedikit daripada yang dipikirkan kebanyakan orang - jadi jangan buang ide ini dengan alasan kinerja kecuali Anda sebenarnya terukur overhead kinerja dan ternyata tidak dapat diterima.

Hal-hal tambahan yang harus diperhatikan. Anda mungkin ingin menggunakan layanan sekali pakai, untuk mencegah pemutaran ulang permintaan yang diautentikasi. Saya sarankan menggunakan nilai acak kriptografi-kekuatan (setidaknya 64 bit panjang). Ini tidak perlu jika Anda menggunakan https.

Pastikan server Anda ditulis untuk bertahan terhadap serangan pencemaran parameter-host (HPP) . Misalnya, ia harus menolak permintaan apa pun dengan beberapa parameter permintaan dengan jenis yang sama (mis., http://example.com/foo.html?name=x&name=y). Juga, saat menulis kode server, berhati-hatilah saat membuat permintaan baru berdasarkan permintaan yang Anda terima. Misalnya, sebelum memproses setiap permintaan, kode server Anda mungkin memvalidasi bahwa permintaan hanya disertai daftar parameter yang diharapkan dan tidak lebih dari itu; buang parameter duplikat atau parameter tak terduga sebelum memproses permintaan.

Perhatikan kelemahan gabungan jika Anda memutuskan untuk melindungi beberapa nilai dengan kode otentikasi pesan.

37
D.W.