Kami sedang mengerjakan proyek baru, kami adalah dua pengembang utama dan mendapatkan persimpangan tentang cara menggunakan token untuk mengamankan komunikasi antara server dan klien.

Saran Pertama: (Token Statis satu kali AKA)

1. klien meminta token utama, dengan mengirim nama pengguna dan kata sandi dan current_time (variabel ini akan disimpan dalam database server dan sisi klien juga) ke api, server menginterpretasikan input, dan merender tohed token (mis: 58f52c075aca5d3e07869598c4d66648) menyimpannya di database dan mengembalikannya ke klien.

2. Klien sekarang menyimpan token utama, dan membuat token hash baru menggunakan token primer + variabel current_time yang dikirim dalam permintaan otentikasi (sebut saja token baru ini, main_token) juga server melakukan hal yang sama dan membuat token yang sama menggunakan algoritma yang sama .

3. Setiap kali klien menanyakan API server, ia mengirimkan main_token ke server, sekarang server membandingkan token yang dihasilkan di dalamnya, dengan main_token yang dikirim oleh klien, jika cocok, itu berarti pengguna itu nyata

Saran Kedua: (Token Dinamis)

1. Klien menghasilkan dua kunci acak ($ ​​key1 = rand (10000.90000); $ key2 = rand (10000.900.000);) Pada setiap permintaan pada API, klien membuat hash menggunakan tipe kueri, dan dua kunci dengan algoritma yang kompleks, dan mengirimkan dua kunci ini + hash ke server

2. Server, menggunakan Algoritma yang sama yang digunakan dalam klien, membuat hash, dan membandingkannya dengan yang dikirim oleh klien, jika cocok, server melanjutkan untuk berurusan dengan kueri

Sekarang, pertanyaannya adalah, Mana yang merupakan cara paling logis, dan aman untuk digunakan untuk mengamankan permintaan API?

Saya sangat suka pendekatan pertama secara umum.

• mudah dimengerti dan diimplementasikan
• aman (setahu saya)
• ini adalah pendekatan yang tidak biasa yang pernah saya lihat digunakan di masa lalu

Satu hal yang saya tidak melihat disebutkan tentang yang pertama yang harus Anda ingat, cap waktu yang digunakan untuk hash token perlu memiliki kedaluwarsa TTL yang sangat singkat (seperti 1 detik) sehingga Anda memverifikasi pesan tidak dikirim dengan cap waktu dan token yang sama dari pesan 12 jam sebelumnya; jelas itu akan dihitung sebagai sah tetapi tidak dalam kasus ini.

Jika ini adalah hanya dua opsi yang Anda pertimbangkan, namun saya ingin memastikan Anda telah melihat pendekatan lain juga, karena ada banyak. Lebih dari saya akan daftar sebenarnya. Ini adalah beberapa pendekatan autentik umum yang layak dipelajari hanya untuk melihat apakah pendekatan tersebut sesuai dengan tujuan Anda dengan lebih baik, dan jika tidak ada yang memahaminya dapat memberi Anda beberapa ide untuk membantu memperketat pendekatan mana pun yang Anda gunakan.

Perhatikan, saya bukan ahli keamanan.

OAuth / Federasi

Dalam pendekatan ini Anda memiliki penjamin pihak ke-3 di mana kode konsumsi meminta token / cert / apa yang Anda dapatkan dari mereka dan menyampaikannya kepada Anda, pada titik ini yang perlu Anda lakukan adalah bertanya kepada pihak ke-3 jika kunci yang Anda berikan adalah sah.

Pro:

• Berbasis standar
• Masalah akan ditemukan oleh orang lain di sistem orang lain sehingga Anda akan mengetahui jika rasa tidak aman itu terjadi
• Apalagi pekerjaan autentik dibutuhkan oleh Anda

Menipu:

• Anda harus berurusan dengan penyedia layanan pihak ke-3 dan API mereka, atau membuat dan menjadi tuan rumah "pihak ke-3" Anda sendiri untuk memisahkan autentikasi dari layanan utama Anda.
• Untuk banyak layanan yang berlebihan, tetapi secara konseptual layak dipertimbangkan

Sertifikat Asinkron

Di sini Anda akan meminta klien Anda mengenkripsi komunikasi mereka dengan sertifikat publik yang telah Anda bagikan dengan mereka ketika mereka menciptakan pengguna. Di sisi Anda, Anda akan mendekripsi menggunakan kunci pribadi yang terkait dengan pengguna di sana. Secara umum Anda akan memulai komunikasi dengan respons tantangan untuk menunjukkan bahwa mereka dapat mengenkripsi / mendekripsi seperti yang Anda harapkan mengidentifikasi mereka sebagai siapa yang mereka klaim. Meskipun pendekatan "sinkron" mungkin dilakukan yang tidak menggunakan tantangan-respons, mereka memiliki sedikit keamanan yang kurang dan beberapa masalah sinkronisasi waktu yang dapat membuatnya lebih rumit.

dari Novell (yeah I know, novell? really?)

Token menggunakan variabel sebagai dasar untuk menghasilkan kata sandi satu kali. Variabel ini disebut tantangan. Dua metode utama untuk menentukan variabel yang digunakan untuk menghasilkan kata sandi adalah asinkron atau sinkron.

Dengan metode asinkron atau tantangan-respons, perangkat lunak server mengirimkan token tantangan eksternal --- variabel yang dibuat secara acak --- untuk perangkat token untuk mengenkripsi. Token menggunakan variabel tantangan ini, algoritma enkripsi, dan rahasia bersama untuk menghasilkan respons --- kata sandi yang dienkripsi dengan benar.

Dengan metode sinkron, variabel tantangan yang digunakan untuk menghasilkan kata sandi ditentukan secara internal oleh token dan server. Penghitung waktu, penghitung acara, atau kombinasi penghitung waktu dan acara dalam setiap perangkat digunakan sebagai dasar untuk variabel tantangan. Karena token dan server masing-masing secara terpisah dan internal menentukan variabel tantangan dari penghitung mereka sendiri, sangat penting bagi penghitung waktu mereka dan penghitung acara untuk tetap tersinkronisasi. Karena sangat mudah bagi server dan token untuk keluar dari sinkronisasi, sebagian besar implementasi memungkinkan sejumlah penyimpangan di antara penghitung. Biasanya, rentang kecil atau jendela nilai penghitung ini digunakan untuk menghitung kata sandi. Namun, jika token dan server keluar dari sinkronisasi di luar jendela ini,

Pro:

• Sertifikat memiliki akar CA yang membuatnya dapat dipercaya dan sulit dipalsukan
• Ada fasilitas standar dalam sistem operasi untuk mengelola dan memelihara toko sertifikat dengan mudah
• Pendekatan yang dipelajari dengan baik, banyak informasi tersedia di sana
• Kadaluwarsa bersama dengan berbagai hal lainnya adalah fasilitas built-in dari sertifikat standar, mereka umumnya kuat

Menipu:

• Sertifikat bisa rumit untuk dikerjakan secara terprogram
• Tergantung pada jika Anda memerlukan CA eksternal, mungkin tidak gratis
• Mungkin perlu mempertahankan toko sertifikat secara manual untuk memastikan trust root yang diharapkan dikonfigurasikan

NTLM

Jangan tertawa, jika ini adalah layanan yang lebih kecil atau internal saja dan Anda berada di lingkungan windows, tidak ada yang salah dengan menggunakan otentikasi NTLM standar untuk menjamin akses. Terutama jika Anda bekerja dengan IIS, ini adalah pendekatan yang paling sederhana. Mudah dirawat dan dikonfigurasikan juga di web.config.

Pro:

• Sangat mudah untuk mengkonfigurasi, mengimplementasikan, dan memelihara

Menipu:

• Interoperabilitas minimal
• Tidak cukup untuk otentikasi yang dihadapi publik

Nonces

Ketika bekerja dengan nonces dalam pendekatan otentikasi Anda, Anda menyediakan metode untuk mendapatkan nonce pada layanan. Metode ini mengembalikan string sewenang-wenang unik atau sepotong data ("a nonce") pada setiap permintaan. Setiap permintaan ke metode lain sekarang membutuhkan nonce untuk diambil, dan digunakan dalam algoritma crypto untuk permintaan tersebut. Nilai di sini adalah bahwa server melacak nonces yang digunakan, dan tidak pernah mengizinkan penggunaan kembali suatuce, ini benar-benar mencegah serangan replay karena sekali permintaan dengan satuce dibuat, permintaan dengance itu tidak pernah dapat dibuat lagi. Ketika nonces diminta, mereka ditambahkan ke daftar nonces yang tersedia, karena mereka digunakan, mereka dipindahkan dari daftar yang tersedia ke daftar yang digunakan.

Pro:

• Menggagalkan serangan replay dengan cukup baik
• Tidak sepenuhnya sulit untuk diimplementasikan atau dipahami

Menipu:

• Membutuhkan klien membuat dua permintaan untuk setiap satu permintaan (meskipun dapat dikurangi dengan meminta nonces hanya untuk permintaan tertentu )
• Membutuhkan manajemen nonces, yang harus bersifat transaksional
• Mempengaruhi kinerja secara negatif dengan meminta permintaan tambahan untuk nonces (transaksionalitas selanjutnya meningkatkan biaya sumber daya untuk bekerja dengan nonces)