Otentikasi untuk game multi-pemain melalui soket


11

Saya menerapkan protokol biner khusus untuk gim multipemain yang baru saya kerjakan. Ini adalah permainan strategi berbasis giliran sehingga waktu tidak terlalu penting. Saat ini saya sudah mendapatkan bagian sinkronisasi data dasar dari sistem yang lengkap, dan saya bertanya-tanya bagaimana cara masuk / keluar pengguna dan enkripsi biasanya dilakukan untuk game MMORPG atau sejenisnya.

  • Bisakah Anda merekomendasikan skema untuk transmisi kata sandi aman / rahasia selama login? (Pertukaran kunci Diffie-Hellman?)
  • Bagaimana cara menerapkan enkripsi kuat untuk paket data? (AES 128-bit? .. atau skema apa pun yang pos ini sebut sebagai "enkripsi lebih kuat daripada kemungkinan Anda akan retak")
  • Apakah ada skema format datagram yang membantu mengeraskan server game untuk memutar ulang serangan, paket data yang tidak valid dan sejenisnya?

Jawaban:


15

Jawaban

  • SRP - Secure Remote Password - Ini didasarkan pada Diffie-Hellman. Idenya adalah Anda dapat melakukan pemeriksaan kata sandi timbal balik tanpa benar-benar pernah mentransfer kata sandi atau informasi apa pun yang dapat digunakan untuk memperolehnya. Meskipun aman melalui kabel, Anda tetap harus mengacak-acak kata sandi Anda karena server Anda tidak boleh menyimpannya dalam teks biasa .
  • Keuntungan dari SRP adalah bahwa begitu selesai, itu juga memberi Anda kunci enkripsi yang dinegosiasikan bersama bahwa penyerang tidak akan dapat menyimpulkan mengingat data yang telah Anda transfer. Ini berarti Anda bebas menggunakan algoritma enkripsi simetris (seperti AES) setelah pengguna diautentikasi.
  • Dengan asumsi Anda menggunakan UDP dengan implementasi terpercaya Anda sendiri / dipesan (berorientasi koneksi) di atasnya: mengenkripsi seluruh muatan UDP - termasuk 'nomor urutan paket' Anda. Jika sistem Anda dirancang dengan benar, maka secara otomatis akan menolak pesan yang diputar ulang dan penyusup tidak akan dapat mengubah nomor urutan paket karena itu dienkripsi (sehingga replay mungkin - tetapi akan diabaikan secara otomatis).

Pikiran

Haruskah otentikasi Anda aman? Benar. Jangan berkompromi dalam hal keamanan saat kata sandi dipertanyakan. Jadi Anda harus mempertimbangkan peluru pertama dalam jawaban saya.

Haruskah data Anda aman? Hanya jika ini merupakan pembelian / transaksi mikro dalam gim - dan mengapa tidak menggunakan sesuatu yang dicoba dan benar seperti HTTPS. Mengenkripsi lalu lintas game Anda kemungkinan besar bukan solusi yang layak karena alasan berikut:

  • Ini paranoia lengkap.
  • Ini akan menambah overhead waktu CPU pada server Anda, kecuali jika Anda dapat membeli modul enkripsi perangkat keras (mahal).
  • Tidak masalah seberapa besar keamanan yang Anda berikan untuk data Anda melalui kabel - seseorang dapat membajak proses klien dan mencegat pesan sesaat sebelum mereka dienkripsi dan dikirim. Ini bukan hanya suatu kemungkinan tetapi jauh lebih mungkin karena secara substansial lebih mudah untuk menyuntikkan kode dibandingkan dengan paket intersepsi. Jika Anda melakukan ini untuk pencegahan cheat, Anda benar-benar dan benar-benar membuang-buang waktu Anda.
    • Dalam hal keamanan kata sandi, sayangnya tidak ada yang dapat Anda lakukan secara wajar mengenai sistem yang dibajak, klien menjadi tidak bersahabat. Badai salju WoW dong dirancang untuk menangani hal ini - tetapi saya tidak yakin seberapa aman itu (terutama jika Anda membiarkannya terpasang).

Tolong, jika Anda mengenkripsi untuk mencegah cheat, abaikan saja. Anda akan datang pendek - saya memberi Anda memiliki informasi jika Anda tidak. Ingat bahwa Anda dapat mengenkripsi paket secara selektif dengan byte pertama dalam paket dan indikator apakah sisanya dienkripsi: walaupun, sekali lagi, saya akan tetap menggunakan HTTPS jika Anda perlu melakukan hal-hal seperti transaksi kartu kredit: mereka sangat jarang dan HTTPS dirancang oleh para ahli - tidak seperti sesuatu yang Anda atau saya dirancang.

Semua itu mengatakan, Blizzard benar-benar mengenkripsi lalu lintas WoW mereka. Alasan utama pecahnya ini adalah karena seseorang, yang kemungkinan adalah seorang amatir yang lengkap, memutuskan bahwa mereka akan mencoba tangan mereka pada algoritma enkripsi buatan sendiri; ini berhasil dengan sangat baik . Bahkan jika Anda menggunakan algoritme standar industri, ada peluang bagus bahwa seseorang akan merekayasa balik kode Anda dan mensimulasikannya - begitu klien memasukkan kata sandi mereka, tidak ada yang tahu bahwa sistem yang tidak didukung terhubung.


2
+1 untuk mengatakan bahwa mengenkripsi paket data untuk pencegahan cheat tidak berguna. OP: lakukan verifikasi semua yang Anda terima dari klien, jalankan pemeriksaan kewarasan, periksa ulang apakah tindakan yang diminta klien mungkin, periksa rentang senjata, kecepatan gerakan dll. Tapi jangan buang waktu mengamankan klien Anda karena akan diretas jika gim Anda sepadan. Beberapa perusahaan MMO mengenkripsi dan mengaburkan klien / protokol mereka tetapi itu bukan untuk mencegah kecurangan tetapi untuk membuatnya lebih sulit misalnya pembuat bot untuk mendapatkan hasil yang baik, dan bahkan ini dilakukan oleh tim ahli yang berdedikasi.
Gilead

1
Sebuah pertengkaran kecil tentang jawaban ketiga Anda: hanya mengenkripsi paket mungkin tidak cukup untuk mencegah gangguan, karena banyak skema enkripsi setidaknya agak lunak . Untuk melindungi integritas pesan, Anda memerlukan MAC atau mode enkripsi yang diautentikasi .
Ilmari Karonen

+1 Terima kasih atas jawaban yang sangat lengkap. Melihat ke dalam mengimplementasikan SRP sekarang. Apa rekomendasi Anda mengenai fungsi hash yang digunakan untuk kata sandi? MD5? Bagaimana protokol OTR (Off the Record) untuk kasus penggunaan seperti itu? apakah ini akan bekerja dengan baik untuk auth / crypto bukan SRP? Jika saya menggunakan SRP, apakah saya perlu menggunakan salah satu dari mode "enkripsi terotentikasi" berikut? (OCB 2.0, Bungkus Utama, CCM, EAX, Enkripsi-lalu-MAC dan GCM)
Robinicks

1
@Jenko menggunakan keluarga algoritma SHA (kemungkinan SHA1) - Anda harus menghindari MD5 hari ini. OTR sebenarnya bukan sesuatu yang harus Anda perhatikan - OTR tidak dirancang untuk aman / tidak jelas (sebenarnya ini dirancang agar seseorang dapat lebih mudah memalsukan paket) itu juga dirancang untuk pengiriman pesan instan dan bukan komunikasi mesin. Tidak satu pun dari mode tersebut yang diperlukan, cukup gunakan SRP: begitu Anda memiliki kunci simetris yang dinegosiasikan bersama hanya dengan dapat mengenkripsi sesuatu adalah cukup jaminan bahwa Anda berbicara dengan pihak ketiga yang benar. Juga, sekali lagi, baca kembali dua paragraf terakhir saya.
Jonathan Dickinson

1
Sebenarnya, saya punya saran yang lebih baik lagi: gunakan DTLS yang ada di atas implementasi UDP dan jangan coba gulung sendiri. Ini akan menghemat waktu Anda, dan ada banyak detail kecil namun penting yang mudah salah jika Anda mencoba merancang lapisan enkripsi datagram Anda sendiri.
Ilmari Karonen

2

Saya pikir komentar terakhir saya untuk jawaban Jonathan sebaliknya sangat baik layak diperluas menjadi jawaban sendiri:

Jika Anda tidak memiliki banyak pengalaman kripto, Anda tidak harus mencoba merancang lapisan enkripsi Anda sendiri jika Anda bisa menghindarinya. Jika Anda melakukan memiliki banyak pengalaman kripto, Anda harus tahu lebih baik daripada untuk merancang lapisan enkripsi Anda sendiri jika Anda bisa menghindarinya.

Alih-alih, cobalah mencari pustaka crypto yang ada, terstandarisasi dan teruji dengan baik yang memenuhi kebutuhan Anda. Dalam kasus Anda, saya akan merekomendasikan GnuTLS , yang, menurut Wikipedia , menyediakan otentikasi TLS-SRP ( RFC 5054 ) dan mengamankan komunikasi UDP dengan DTLS ( RFC 6347 ). Yang pertama menjaga login, sedangkan yang kedua melindungi saluran aman sehingga terbentuk dari kedua serangan menguping dan aktif, dan bahkan dapat melindungi Anda dari serangan replay .


Saya menggunakan TCP. Ini adalah jenis permainan yang sangat berbeda untuk klien tertentu. Mirip dengan perjudian / taruhan, semua informasi yang dapat digunakan untuk membajak proses meningkatkan kemungkinan kerugian yang tidak perlu oleh rumah. Kami perlu menjaga data sangat aman, karena informasi adalah uang dalam kasus ini.
Robinicks

OK, jika Anda menggunakan TCP, maka itu bahkan lebih mudah: Anda dapat menggunakan TLS 1.2 normal daripada DTLS, yang memberi Anda lebih banyak opsi untuk dipilih. Saya masih merekomendasikan perpustakaan GnuTLS.
Ilmari Karonen

Saya akan melakukan sedikit riset dan melihat apakah saya bisa merujuk ke kode sumber TLS di kedua sisi klien dan server, dan mendasarkan protokol saya di sekitar apa yang dilakukannya. Apakah ini cukup kuat? Intinya hanya enkripsi paket dengan beberapa cipher / mode, benar?
Robinicks

Tidak, ada lebih banyak protokol TLS dari itu. Itulah sebabnya Anda ingin menggunakan perpustakaan standar yang mengimplementasikannya, alih-alih menggulir perpustakaan Anda sendiri.
Ilmari Karonen
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.