it-swarm-id.com

Otentikasi berbasis Token - Mengamankan token

Saya telah mengembangkan backend REST API untuk aplikasi seluler dan sekarang saya sedang mencari untuk menerapkan otentikasi berbasis token untuk itu agar tidak harus Meminta pengguna untuk masuk pada setiap proses aplikasi.

Apa yang ada dalam pikiran saya adalah pada permintaan awal pengguna mengirimkan kredensial mereka menggunakan otentikasi Dasar melalui SSL. Setelah server mengautentikasi kredensial, ia membuat token yang aman dan mengirimkannya kembali ke pengguna sehingga mereka dapat menggunakannya dalam permintaan berikutnya sampai token baik kedaluwarsa atau dicabut.

Saya mencari beberapa saran tentang bagaimana saya dapat menghasilkan token yang tidak akan rentan terhadap hal-hal seperti serangan MoM/Putar ulang serta memastikan data yang disimpan dalam token tidak dapat diekstraksi.

Saya akan menggunakan yang berikut pendekatan untuk menghasilkan token yang saya pikir akan mencegah data diambil dari itu. Namun, saya masih perlu memastikan itu tidak rawan serangan lainnya.

API hanya akan dapat diakses melalui SSL tetapi saya tidak yakin apakah saya hanya dapat mengandalkan ini dari perspektif keamanan.

99
James

"Token otentikasi" berfungsi dengan cara server mengingatnya.

Token umum adalah string acak; server menyimpan dalam pemetaan pemetaan dari token yang dipancarkan ke nama pengguna terotentikasi. Token lama dapat dihapus secara otomatis untuk mencegah basis data server tumbuh tanpa batas. Token semacam itu cukup baik untuk keamanan selama penyerang tidak dapat membuat token yang valid dengan probabilitas yang tidak dapat diabaikan, "token yang valid" menjadi "token yang ada dalam database token yang dipancarkan". Ini cukup bahwa nilai-nilai token memiliki panjang setidaknya 16 byte dan diproduksi dengan kuat kriptografis PRNG (misalnya /dev/urandom, CryptGenRandom(), Java.security.SecureRandom ... tergantung pada platform Anda).

Dimungkinkan untuk membongkar persyaratan penyimpanan pada klien itu sendiri. Dalam paragraf di atas, "memori" apa yang harus dimiliki server dari token? Yaitu nama pengguna, dan tanggal pembuatan token. Jadi, buat token Anda seperti ini:

  • Server memiliki kunci rahasia [~ # ~] k [~ # ~] (urutan, katakanlah, 128 bit, yang dihasilkan oleh PRNG yang aman secara kriptografis aman ).
  • Token berisi nama pengguna ( [~ # ~] u [~ # ~] ), waktu penerbitan ( [~ # ~] t [~ # ~] ), dan pemeriksaan integritas kunci dihitung lebih dari [~ # ~] u [~ # ~] dan [~ # ~] t [~ # ~] (bersama-sama) , dikunci dengan [~ # ~] k [~ # ~] (secara default, gunakan HMAC dengan SHA-256 atau SHA-1).

Berkat pengetahuannya tentang [~ # ~] k [~ # ~] , server dapat memverifikasi bahwa token yang diberikan, dikirim kembali oleh pengguna, adalah salah satu miliknya atau tidak; tetapi penyerang tidak bisa memalsukan token semacam itu.

Jawaban yang Anda tautkan terlihat agak seperti itu, kecuali bahwa itu berbicara tentang enkripsi alih-alih MAC, dan itu:

  1. bingung;
  2. membingungkan;
  3. berpotensi tidak aman;

karena enkripsi bukan MAC.

82
Thomas Pornin

Singkatnya, Anda harus menggunakan token acak satu kali kekuatan kriptografi, dan mengaitnya dalam database.

Token

  • harus hanya boleh digunakan satu kali,
  • harus hanya dapat digunakan untuk pengguna yang membuatnya,
  • harus hanya dikirim melalui HTTPS,
  • harus memiliki tanggal kedaluwarsa (mis. 7 hari).

Setelah pengguna masuk dengan token, itu tidak valid dan token baru harus dibuat dan diberikan kepada pengguna. Dalam kasus token yang kedaluwarsa, pengguna harus masuk lagi, menggunakan kredensial asli mereka.

Deskripsi yang lebih pasti dan panjang mengenai aturan-aturan ini dapat ditemukan di bagian 2 dari Panduan Definitif Untuk Otentikasi Situs Web Berbasis Formulir :

Cookie Login Persisten (fungsionalitas "ingat saya") adalah zona berbahaya; di satu sisi, mereka sepenuhnya aman seperti login konvensional ketika pengguna mengerti cara menanganinya; dan di sisi lain, mereka adalah risiko keamanan yang sangat besar di tangan sebagian besar pengguna, yang menggunakannya di komputer umum, lupa untuk keluar, tidak tahu apa itu cookie atau bagaimana cara menghapusnya, dll.

[...]

Ikuti artikel 'Praktik Terbaik' Charles Miller . Jangan tergoda untuk mengikuti Praktik Terbaik 'Peningkatan' yang tertaut di akhir artikelnya. Sedihnya, 'perbaikan' pada skema dengan mudah digagalkan (semua yang harus dilakukan penyerang saat mencuri cookie 'yang ditingkatkan' adalah ingat untuk menghapus yang lama. Ini akan mengharuskan pengguna yang sah untuk login ulang, membuat pengenal seri baru dan membiarkan yang dicuri valid).

Dan JANGAN MENYIMPAN COOKIE LOGIST PERSISTEN (TOKEN) DI DATABASE ANDA, HANYA HASH OF IT! Token masuk adalah Kata Sandi Setara, jadi jika penyerang mendapatkan tangannya di database Anda, ia bisa menggunakan token untuk masuk ke akun apa pun, sama seperti jika itu adalah kombinasi kata sandi masuk-teks yang jelas. Oleh karena itu, gunakan hashing asin yang kuat (bcrypt/phpass) saat menyimpan token login persisten.


Pembaruan: Maaf, saya salah paham pertanyaannya. Metode yang Anda tautkan tampak masuk akal, tetapi itu tidak akan melindungi Anda dari serangan replay atau man-in-the-middle. Anda harus menggunakan SSL di sampingnya.

38
Polynomial

Layanan web API RESTful murni harus menggunakan fitur standar protokol yang mendasarinya:

  1. Untuk HTTP, RESTful API harus merangkul dan mematuhi header standar HTTP, kode status, dan metode. Menambahkan header HTTP baru melanggar prinsip-prinsip REST.

  2. Layanan yang tenang harus tanpa batas. Setiap trik, seperti otentikasi berbasis token yang mencoba mengingat keadaan REST permintaan sebelumnya di server melanggar prinsip-prinsip REST.

Intinya: Untuk tujuan otentikasi/otorisasi, Anda harus menggunakan header otorisasi HTTP. Dan Anda harus menambahkan header skema otorisasi HTTP khusus di setiap permintaan berikutnya yang perlu diautentikasi.

Saya telah mengembangkan layanan web RESTful untuk aplikasi Cisco Prime Performance Manager. Cari Google untuk Cisco Prime Performance Manager REST dokumen API yang saya tulis untuk aplikasi itu untuk detail lebih lanjut tentang kepatuhan API RESTFul - lihat di bawah. Untuk aplikasi ini, kami telah memilih untuk menggunakan HTTP "Basic "Skema otorisasi untuk mengotentikasi dan mengotorisasi permintaan. Dan jelas, kami menggunakan HTTPs untuk mengenkripsi semua data dalam perjalanan dari klien ke server saat menggunakan Otorisasi HTTP.

http://www.Cisco.com/c/en/us/support/cloud-systems-management/prime-performance-manager/products-programming-reference-guides-list.html

4
Rubens Gomes