Khusus mengenai bagian terakhir dari pertanyaan Anda: Tidak, tidak dapat dimaafkan memiliki sistem autentikasi tidak aman. Pengguna jarang tercerahkan dalam hal keamanan komputer. Pengguna menggunakan kata sandi yang sama untuk permainan kecil Anda seperti yang mereka lakukan untuk akun Google, akun Facebook, rekening bank, dan sebagainya. Bahkan jika Anda dapat mengklaim bahwa itu adalah kesalahan mereka karena menggunakan kebiasaan keamanan Internet yang buruk, Andalah yang akan bertanggung jawab jika game Anda digunakan sebagai vektor serangan untuk mencuri kredensial login pengguna. Sebagai pengembang yang lebih tahu, satu-satunya pilihan etis adalah mengamankan proses otentikasi Anda dengan benar atau tidak memilikinya sama sekali.
Seperti beberapa saran yang tidak diminta tetapi terkait, pengguna tetap tidak perlu diminta untuk mendaftar untuk game Anda. Mereka mungkin melakukannya jika mereka ingin memainkan permainan Anda dengan cukup buruk, tetapi memiliki Namun Login Freaking Lain untuk mendaftar akan hanya mengusir banyak pemain potensial. Pengguna sakit sampai mati membuat akun baru untuk setiap situs, layanan, dan permainan di luar sana, terutama jika mereka memerlukan segala jenis validasi email atau sejenisnya. Jika Anda bisa, hindari login sama sekali, atau gunakan layanan otentikasi pihak ketiga yang sudah ada yang kemungkinan besar sudah dimiliki pengguna. Anda akan memiliki lebih banyak pemain dengan cara itu. Ini menjadi tiga kali lipat jika Anda berencana melakukan segala jenis pembelian dalam aplikasi.
Game Web
Opsi populer - terutama untuk game Web, meskipun juga berfungsi untuk game tradisional - adalah menggunakan layanan otentikasi pihak ketiga berbasis-Web. Facebook dan Google keduanya memiliki API yang terdokumentasi dengan baik (keduanya didasarkan pada API standar, iirc) untuk otentikasi. Mereka memang membutuhkan kemampuan untuk membuka jendela browser dan mengarahkan pengguna ke layanan mereka, tetapi ini cukup mudah dilakukan pada sebagian besar platform non-konsol, dan tentu saja sepele untuk permainan Web.
Layanan tersebut menangani semua detail berantakan mengenkripsi lalu lintas masuk melalui kabel, menyimpan kredensial login dengan aman, dan memvalidasi login pengguna. Server permainan Anda hanya perlu mengimplementasikan bagian protokol yang menerima cookie dari pengguna dan menanyakan layanan otentikasi apakah cookie tersebut valid atau tidak, yang dapat dilakukan dengan HTTP sederhana dalam kebanyakan kasus.
Saya tidak akan mengklaim sebagian besar game multi-pemain tradisional melakukan ini, karena mereka tidak melakukannya, tetapi saya akan mengklaim bahwa sebagian besar game online kasual melakukan ini.
Untuk permainan tradisional (non-Web), memfasilitasi prosedur login ini dimungkinkan dengan menanamkan browser (Awesomium, Chromium Embedded Framework, atau langsung menjadikan Webkit sebagai pilihan populer) atau dengan memanggil browser eksternal (ini membutuhkan lebih banyak lagi keluarkan cookie autent dari, dan tidak benar-benar lebih mudah daripada menanamkan salah satu perpustakaan yang disebutkan sebelumnya).
Contoh khas dari pendekatan ini adalah setiap game Facebook.
Game Tradisional menggunakan HTTPS
Memiliki layanan HTTPS sederhana untuk login semakin normal. Banyak game menggunakan protokol khusus, tetapi sebagian besar tidak lengkap (mereka memiliki login yang aman, tetapi tidak ada cara aman untuk membuat / memperbarui akun, jadi mereka tetap membutuhkan layanan HTTPS) atau hanya merasa tidak aman.
Anda bahkan tidak perlu mencari sertifikat SSL khusus. Ada penyedia hosting aplikasi online yang memberi Anda subdomain dan menggunakan sertifikat wildcard SSL. Anda dapat menempatkan layanan autentikasi di mygame.someservice.com, yang dicakup oleh wildcard * .someservice.com cert yang dipelihara oleh Beberapa Layanan, dan Anda dapat melakukannya.
Idenya di sini adalah bahwa pengguna masuk ke layanan Anda, yang menghasilkan cookie sesi unik, yang kemudian dapat dilewatkan pengguna ke server permainan utama Anda. Server kemudian menanyakan sistem login apakah cookie tersebut valid untuk pengguna yang diminta. Biasanya ada batas waktu yang sangat singkat pada cookie, pada urutan detik (15-30, misalnya), dan itu umumnya tidak berlaku setelah digunakan, membuat serangan replay tidak mungkin.
Perhatikan bahwa HTTPS adalah opsi yang paling saya rekomendasikan jika Anda berencana mengirim informasi pembayaran melalui kawat dari dalam klien itu sendiri. Namun, lebih baik menggunakan pihak ketiga untuk ini. Jika Anda berpikir bahwa mengamankan sesuatu yang sederhana seperti kata sandi terlalu banyak berhasil, Anda bahkan tidak ingin berpikir untuk mencoba memenuhi aturan kepatuhan PCI minimum (dan sejujurnya tidak memadai) untuk menyimpan dan memproses nomor kartu kredit. Lagi pula, Anda akan memiliki serapan penjualan yang lebih baik jika Anda memiliki pengguna yang menggunakan layanan pembayaran pihak ketiga tepercaya yang sudah ada dalam arsip mereka.
Salah satu keuntungan kuat memisahkan layanan login Anda dari server game utama adalah memungkinkan layanan eksternal untuk dikaitkan dengan akun pengguna yang tidak tergantung pada game. Anda mungkin memiliki beberapa fitur akun (melihat avatar atau semacamnya) di situs web Anda, atau mungkin Anda mengizinkan menautkan akun Facebook ke akun Anda, atau mungkin Anda memiliki beberapa game yang berbagi platform akun yang mendasari tunggal (misalnya, fitur Galaxy at War dari Mass Effect 3).
Contoh game yang populer menggunakan HTTPS untuk otentikasi adalah Minecraft.
Otentikasi Web Pihak Ketiga dengan Permainan Klien Asli
Dimungkinkan untuk menggunakan layanan pihak ketiga seperti Facebook Connect atau Google dengan klien asli. Facebook misalnya memiliki SDK asli untuk iOS dan Android, seperti halnya Google. Beberapa layanan juga memiliki SDK asli untuk klien PC tradisional.
Jika layanan target tidak memiliki SDK asli dan memerlukan penggunaan browser Web, Anda bisa menyematkan browser di game Anda. Namun, beberapa pengguna mungkin tidak percaya menggunakan browser yang tertanam untuk memasukkan informasi login.
Anda juga dapat menggunakan browser eksternal. Ada beberapa cara untuk melakukan ini. Beberapa membutuhkan sedikit lebih banyak integrasi OS daripada yang lain. Beberapa mengharuskan Anda untuk memiliki layanan Web eksternal berjalan bersama (atau setidaknya dapat dijangkau oleh) server permainan utama Anda. Perhatikan bahwa karena Facebook dan Google umumnya memerlukan URL yang diautentikasi, Anda akan memerlukan halaman arahan situs web publik untuk menggunakan protokol ini di (hampir) semua kasus.
Yang paling bodoh dan dapat diandalkan, jika bukan yang paling mudah, adalah untuk memantulkan permintaan login Anda dari klien Anda melalui situs web utama Anda. Klien Anda terhubung ke server permainan utama sebagai pengguna tamu yang diautentikasi dan menerima token sesi unik. Server permainan tidak memungkinkan klien untuk benar-benar melakukan banyak hal dalam kondisi ini; permainan tidak tahu siapa pemainnya, jadi pemain belum bisa mengobrol, memulai pertandingan, atau sebagainya.
Klien kemudian meluncurkan browser eksternal yang menunjuk pada URL login domain game Anda, dengan meneruskan token sesi ini sebagai parameter dalam URL. Situs kemudian melalui jabat tangan login yang biasa untuk Facebook / Google.
Pada titik ini, server web Anda tahu bahwa pengguna telah masuk, dan dapat mengaitkannya dengan token sesi yang diterima dari klien. Verifikasi ini kemudian dapat dikomunikasikan ke server permainan, meningkatkan koneksi tamu yang tidak diautentikasi klien ke dalam sesi pengguna yang diautentikasi. Ini dapat dilakukan dengan meminta server web berkomunikasi langsung dengan server game, jika memungkinkan. Atau server game dapat secara berkala melakukan polling server web untuk status otentikasi koneksi tamu yang tertunda. Atau klien dapat secara berkala polling server web untuk melihat apakah login selesai dan, ketika itu, memberi sinyal server game untuk meminta verifikasi dari server web.
Semua ini mengharuskan server game dan server web Anda untuk dapat berkomunikasi, tetapi setiap layanan otentikasi pihak ketiga akan mengharuskan server game Anda untuk dapat berkomunikasi dengan dunia luar, jadi ini seharusnya tidak mengejutkan.
Metode otentikasi ini ditemukan di beberapa MMO kecil hingga menengah.
Perhatikan bahwa ini semua juga berfungsi untuk melakukan permintaan pembayaran melalui layanan eksternal, seperti PayPal, Pembayaran Amazon, Google Wallet, dll.
Koneksi TLS langsung
Tidak terlalu sulit untuk memulai sesi TLS melalui protokol streaming khusus. Perpustakaan seperti OpenSSL, GnuTLS, NSS, dan berbagai perpustakaan khusus-OS menyediakan API pembungkus aliran yang berlapis-lapis pada transport / protokol tingkat rendah. Anda biasanya hanya perlu memberi makan byte melalui API wrapper dan itu berkaitan dengan jabat tangan dan enkripsi.
Bagian yang sulit di sini adalah memastikan penggunaan TLS Anda aman. Beberapa perpustakaan umum misalnya akan secara default memerlukan sertifikat yang ditandatangani sah dari otoritas tepercaya. Beberapa perpustakaan umum mengharuskan itu, tetapi secara default tidak percaya otoritas apa pun. Beberapa dari mereka tidak mensyaratkan bahwa sertifikat itu berlaku sama sekali.
Disarankan agar Anda selalu memerlukan sertifikat yang valid. Mengizinkan sertifikat yang tidak valid tidak akan memungkinkan penyerang yang hanya menguping mencuri kata sandi, tetapi itu masih akan memungkinkan serangan man-in-the-middle.
Pendekatan ini membutuhkan paling tidak absolut dalam hal ketergantungan eksternal sambil tetap memungkinkan keamanan maksimum.
Contoh permainan yang menggunakan ini sekarang termasuk sebagian besar MMO tradisional besar.
Mengamankan (ish) Permainan Tradisional
Gim yang tidak menggunakan layanan terpisah dan tidak menggunakan TLS biasanya harus menerapkan beberapa jenis protokol masuk non-berbasis dalam protokol gim utama mereka. Dengan metode ini, server menghasilkan nomor acak (nonce) dan mengirimkannya ke klien. Klien kemudian memilah-milah itu dengan kata sandi pengguna (dan nama pengguna, mungkin beberapa data lain) dan mengirimkan respons itu ke server. Server kemudian membandingkan nilai hash ini dengan kredensial yang ada di file. Hal ini membuat sandi pengguna tetap rahasia di atas kawat dan memastikan bahwa Anda tidak dapat menggunakan serangan replay sederhana pada kata sandi hash, seperti banyak skema masuk berbasis hash lainnya yang lemah.
Masalahnya adalah bahwa pengguna tidak memiliki cara untuk mengirimkan kata sandi baru ke layanan melalui protokol ini dengan aman. Implementasi umum juga menyimpan kata sandi pengguna dalam plaintext di server, yang merupakan praktik yang mengerikan (jika server Anda diretas, pengguna Anda mungkin baru saja mencuri email / facebook / kata sandi banknya, karena ia menggunakan kata sandi yang sama untuk permainan Anda sebagai di tempat lain, karena pengguna cenderung melakukan itu).
Ada versi yang disempurnakan dari skema login dasar tersebut. Yang paling mendasar - meskipun masih tidak aman secara idealnya - adalah untuk server mengirimkan garam hash kata sandi dengan nilai nonce saat login. Ini memungkinkan server untuk menyimpan kata sandi hash (dan asin) dengan aman sementara memungkinkan klien untuk menghasilkan hash yang sama selama login. Ini memungkinkan penyerang mendapatkan garam untuk kata sandi pengguna tertentu, tetapi ini tidak terlalu berguna tanpa juga mendapatkan kata sandi hash asli (yang tidak dikirim melalui kawat saat login). Selama pembuatan / pembaruan kata sandi, klien mengirim seluruh kata sandi hash (dengan garam), yang dapat diserang oleh penyerang. Jika fungsi hash yang digunakan cukup kuat (katakanlah, sha-2/512) maka pemaksaan brute murni tidak layak, meskipun penyerang masih dapat dengan mudah memaksa kata sandi yang lemah (itulah sebabnya menegakkan beberapa panjang kata sandi minimum, distribusi minimum huruf / angka / simbol, dan membandingkan dengan kamus kata sandi yang diketahui / jelas / lemah adalah penting). Fakta bahwa penyerang masih bisa mendapatkan kata sandi hash adalah mengapa masih lebih aman untuk melakukan seluruh pertukaran kata sandi melalui saluran terenkripsi yang aman.
Sejumlah pustaka jaringan permainan populer menerapkan beberapa bentuk opsional protokol ini. Saya percaya SmartFox adalah salah satu contohnya, meskipun saya belum melihatnya secara mendalam (saya biasanya mengabaikan sistem autentikasi pustaka semacam itu dan menggunakan metode HTTPS, karena sangat mudah diterapkan dan jauh lebih kuat). Sejumlah game Internet non-Web awal juga menggunakan pendekatan ini, terutama sebelum Steam, XBL, dan sebagainya muncul.
Permainan Tradisional Tidak Aman
Sayangnya, banyak game yang hanya mengirim nama pengguna / kata sandi dalam plaintext. Mungkin mereka memiliki kata sandi, yang samar-samar semacam melindungi kata sandi pengguna yang sebenarnya (hampir tidak cukup baik) tetapi serangan replay membuat masuk ke layanan game sepele.
Jangan lakukan ini. Tidak bertanggung jawab dan malas. Kenaifan internet pada 1990-an yang mempopulerkan metode login ini bukan lagi alasan yang masuk akal.
Banyak game Flash dan web pra-Facebook awal mengambil pendekatan ini. Saya tidak tahu ada contoh spesifik dari atas kepala saya; Saya ingin percaya mereka semua sudah lama mati, tetapi dunia tidak seberuntung itu.
Tidak Ada Otentikasi
Sebagian besar game tidak melakukan otentikasi. Pemain menghubungkan, mengirim beberapa pegangan untuk mengidentifikasi dirinya secara unik, dan pertandingan dimulai. Tidak ada server global yang mencoba memvalidasi bahwa hanya satu manusia nyata yang diizinkan untuk mengaku sebagai "CaptainMisterDude". Server lokal hanya memastikan bahwa hanya satu pemain yang terhubung saat ini yang memiliki pegangan khusus, dan itulah akhirnya. Server lokal menggunakan daftar hitam berbasis nama dan berbasis IP untuk pembuat masalah. Ini umum untuk game gaya FPS deathmatch bahkan hari ini.
Jika Anda tidak memerlukan status permanen untuk akun, ini adalah solusi termudah, dan cukup "aman" karena tidak ada yang bisa diretas atau dicuri. Jelas ini tidak berfungsi dengan baik jika Anda perlu menyimpan informasi akun di antara sesi permainan.
Gempa adalah contoh permainan menggunakan metode "otentikasi" pengguna.