Çok oyunculu oyunlar kimlik doğrulamayı nasıl ele almalı?


27

Bir kimlik doğrulama sisteminin oyunlarda nasıl çalışacağını anlamak için etrafta dolaşıyordum, ancak birçok aramadan sonra, ssl / sertifikalarla çalışmanın MMO'dan çok daha az kapasiteye sahip çok oyunculu bir oyun için biraz karmaşık olabileceği görünüyor.

Başarılı çok oyunculu oyunların buna ihtiyacı olduğunu biliyorum, ancak diğer çok oyunculu oyunların bu önlemleri alıp almadığını kontrol etmek istiyorum.

EDIT : Aklımda olanı anlatacağım. Sunucu yalnızca oyun mantığını değil aynı zamanda kimlik doğrulamasını da idare eder. Bu nedenle, belirli bir sunucuda oynamak için (herkesin başlayabileceği), önce sunucuda bir hesap açmanız ve orada oynamak istediğiniz her zaman, her zamanki gibi giriş yapmanız gerekir (şifre / kullanıcı adı).

Sorum şu ki, bir hesaba giriş yapmak / kaydolmak için güvenli bir kanal sağlamayacak mı, bu bağlamda affedilebilir / anlaşılabilir mi? Ayrıca, benzer mimariye sahip oyunların bu konuyu nasıl idare edeceğini bilmek istiyorum.


SSL sertifikaları yönetimi karmaşık ve acı vericidir. Uzak durmanı öneririm.
ashes999

4
@ ashes999 Aslında acı onları CA yetkilileri tarafından imzalatmaktan kaynaklanıyor. Sunucuyla bir tarayıcı aracılığıyla iletişim kurmayan bir oyun için kendinden imzalı bir sonsuz sertifika kullanabilir, hatta müşterilerin doğru sertifikanın kullanıldığını doğrulamasını sağlayabilirsiniz. İyi bir kütüphane verildiğinde, kurulumu oldukça kolaydır.
aaaaaaaaaaaa 21

Alt etki alanları ve bunların joker kodları yoluyla ücretsiz SSL sağlayan uygulama barındırma çözümleri vardır. Dolayısıyla, HTTPS'yi SSL sertifikalarını kendileri düşünmeye bile gerek kalmadan kullanabilirsiniz. Sadece başka bir seçenek olarak.
Sean Middleditch

@ eBusiness haklısın.
ashes999

Yanıtlar:


41

Özellikle sorunuzun son kısmına ilişkin olarak: Hayır, güvenli olmayan bir kimlik doğrulama sistemine sahip olmak asla affedilmez. Kullanıcılar bilgisayar güvenliği söz konusu olduğunda nadiren aydınlatılmaktadır. Kullanıcılar küçük oyununuz için, Google hesapları, Facebook hesapları, banka hesapları vb. İle aynı şifreyi kullanır. Kötü İnternet güvenlik alışkanlıklarını kullanmanın onların suçu olduğunu iddia etseniz bile, oyununuzun kullanıcıların giriş bilgilerini çalmak için bir saldırı vektörü olarak kullanılması durumunda sorumlu tutulacaksınız. Daha iyisini bilen bir geliştirici olarak, tek etik seçenekleri kimlik doğrulama işleminizi uygun şekilde güvenceye almak veya hiç birine sahip olmamaktır.

İstenmeyen, ancak bazı ilgili önerilerde bulunduklarından, kullanıcıların yine de oyununuza kaydolmaları istenmez. Eğer oyununuzu yeterince kötü oynamak istiyorlarsa bunu yapabilirler, ancak kaydolmak için Yeterli Başka Giriş Girişi olması birçok potansiyel oyuncuyu uzaklaştıracaktır. Kullanıcılar, özellikle herhangi bir e-posta doğrulaması veya benzeri bir şey gerektiriyorsa , oradaki her site, hizmet ve oyun için yeni bir hesap oluşturmaktan bıktılar. İsterseniz, giriş yapmaktan kaçının ya da kullanıcıların zaten bir hesabı olan mevcut bir üçüncü taraf kimlik doğrulama servisini kullanabilirsiniz. Bu şekilde daha fazla oyuncunuz olacak. Herhangi bir uygulama içi satın alma işlemi yapmayı planlıyorsanız, bu üçlü olur.

Web Oyunlar

Popüler bir seçenek - özellikle Web oyunları için, geleneksel oyunlarda da çalışsa da - Web tabanlı bir üçüncü taraf kimlik doğrulama hizmeti kullanmaktır. Facebook ve Google’ın her ikisi de kimlik doğrulama için iyi belgelenmiş API'lere (her ikisi de standartlaştırılmış API'lere dayalı, iirc) sahiptir. Bir tarayıcı penceresi açıp kullanıcıyı hizmetlerine yönlendirmesini gerektiriyorlar, ancak çoğu konsol dışı platformda ve elbette Web oyunları için önemsiz şeyler yapmak oldukça kolay.

Bu hizmetler, giriş trafiğini tel üzerinden şifrelemek, giriş bilgilerini güvenli bir şekilde saklamak ve kullanıcı girişlerini doğrulamak için tüm karmaşık ayrıntılara dikkat eder. Oyun sunucunuzun daha sonra yalnızca kullanıcıdan bir çerez alan bir çerez alan protokolünü kullanması ve çerezin geçerli olup olmadığını ve çoğu durumda basit bir HTTP ile yapılabilmesi için kimlik doğrulama hizmetini sorması gerekir.

Geleneksel çok oyunculu oyunların çoğunun bunu yaptığını iddia etmiyorum, çünkü bunu yapmıyorlar ama çoğu çevrimiçi gündelik Web oyununun bunu yaptığını iddia edeceğim.

Geleneksel (Web dışı) oyunlar için, bu oturum açma prosedürünü kolaylaştırmak, bir tarayıcıyı (Awesomium, Chromium Gömülü Çerçeve veya doğrudan Webkit'in popüler seçimler haline gelmesiyle) ya da harici bir tarayıcıyı çağırmakla mümkündür (bu, biraz daha merak uyandırır) Gerektiği gibi tanımlama bilgisini alın ve yukarıda belirtilen kütüphanelerden birini gömmek kadar kolay değildir).

Bu yaklaşımın tipik bir örneği herhangi bir Facebook oyunudur.

HTTPS Kullanarak Geleneksel Oyunlar

Giriş için basit bir HTTPS servisine sahip olmak giderek daha normal hale geliyor. Pek çok oyun özel protokoller kullanır, ancak bunların çoğu tamamlanmamış (güvenli bir oturum açmaya sahipler, ancak bir hesap oluşturmak / güncellemek için güvenli bir yol bulunmuyorlar, bu nedenle HTTPS hizmetine zaten ihtiyaç duyuyorlar) veya sadece korkunç derecede güvensizler.

Özel bir SSL sertifikası almaya bile ihtiyacınız yok. Size bir alt etki alanı veren ve bir joker SSL sertifikası kullanan çevrimiçi uygulama barındırma sağlayıcıları vardır. Kimlik doğrulama hizmetinizi, Bazı Hizmetlerin koruduğu * .someservice.com joker sertifikası kapsamında olan mygame.someservice.com sitesine koyabilirsiniz ve gitmeniz iyi olur.

Buradaki fikir, kullanıcının daha sonra ana oyun sunucunuza aktarabileceği benzersiz bir oturum çerezi oluşturan hizmetinize giriş yapmış olmasıdır. Ardından sunucu, tanımlama bilgisinin istenen kullanıcı için geçerli olup olmadığını giriş sistemine sorar. Çerez üzerinde, genellikle saniye cinsinden (örneğin 15-30) çok kısa bir zaman aşımı süresi vardır ve genellikle bir kez kullanıldığında geçersiz kılınır ve tekrarlama saldırılarını imkansız hale getirir.

Müşterinin kendi içinden tel üzerinden ödeme bilgileri göndermeyi planlıyorsanız, HTTPS'nin en çok önerilen seçeneğim olduğunu unutmayın. Ancak, bunun için bir üçüncü taraf kullanmak daha iyi. Parola kadar basit bir şeyi güvenceye almanın çok fazla iş olduğunu düşünüyorsanız, kredi kartı numaralarını saklamak ve işlemek için minimum (ve gerçekten oldukça yetersiz) PCI uyumluluk kurallarına uymayı denemek bile istemezsiniz. Zaten kayıtlı oldukları güvenilir üçüncü taraf ödeme servislerini kullanıyorsanız, yine de daha iyi satış alımına sahip olacaksınız.

Giriş hizmetinizi ana oyun sunucusundan ayırmanın güçlü bir avantajı, harici işlevselliğin oyundan bağımsız olarak kullanıcı hesaplarına bağlanmasına izin vermesidir. Web sitenizde bazı hesap özelliklerine (avatarları veya benzerlerini görüntüleme) sahip olabilirsiniz ya da Facebook hesaplarını hesaplarınıza bağlamanıza izin verebilir veya belki de tek bir temel hesap platformunu paylaşan birden fazla oyununuz olabilir (örneğin, Mass Effect'in Mass Effect'teki özellikleri 3).

Kimlik doğrulama için HTTPS kullanan popüler bir örnek oyun Minecraft.

Yerel İstemci Oyunları ile Üçüncü Taraf Web Kimlik Doğrulama

Yerel bir müşteriyle Facebook Connect veya Google gibi üçüncü taraf servislerini kullanmak mümkündür. Örneğin Facebook, iOS ve Android için Google’da olduğu gibi yerel bir SDK’ya sahiptir. Bazı servisler, geleneksel PC istemcileri için yerel SDK'lara sahiptir.

Hedef hizmetin yerel bir SDK'sı yoksa ve bir Web tarayıcısının kullanılmasını gerektiriyorsa, oyununuza bir tarayıcı gömebilirsiniz. Bununla birlikte, bazı kullanıcılar giriş bilgilerini girmek için gömülü bir tarayıcı kullanmak konusunda güvensiz olabilirler.

Harici bir tarayıcı da kullanabilirsiniz. Bunu çıkarmanın birkaç yolu var. Bazıları diğerlerinden biraz daha fazla OS entegrasyonu gerektirir. Bazıları, ana oyun sunucunuzun yanında (veya en azından erişilebilir) çalışan harici bir Web servisine sahip olmanızı gerektirir. Facebook ve Google’ın genellikle kimliği doğrulanmış bir URL’yi gerektirdiğinden, bu protokolleri hemen hemen her durumda kullanabilmek için genel web sitesi açılış sayfasına ihtiyacınız olacağını unutmayın.

En kolay ve güvenilir, en kolay olmasa bile, giriş isteğinizi ana web siteniz üzerinden müşterinizden almaktır. Müşteriniz ana oyun sunucusuna kimliği doğrulanmış bir konuk kullanıcı olarak bağlanır ve benzersiz bir oturum belirteçleri alır. Oyun sunucusu, müşterinin bu durumda çok fazla şey yapmasına izin vermez; Oyun, oyuncunun kim olduğunu bilmediğinden, oyuncu henüz sohbet edemez, bir maç başlatamaz vb.

İstemci daha sonra, bu oturum belirtecini URL'de bir parametre olarak geçirerek oyununuzun etki alanının giriş URL'sini gösteren harici tarayıcıyı başlatır. Site daha sonra Facebook / Google için normal giriş anlaşması yapılıyor.

Bu noktada, web sunucunuz kullanıcının giriş yaptığını bilir ve bunu istemciden aldığı oturum belirteci ile ilişkilendirebilir. Bu doğrulama daha sonra oyun sunucusuna iletilerek müşterinin kimliği doğrulanmamış konuk bağlantısını kimliği doğrulanmış bir kullanıcı oturumuna yükseltir. Bu, mümkünse, web sunucusunun doğrudan oyun sunucusuyla iletişim kurmasını sağlayarak yapılabilir. Veya oyun sunucusu, bekleyen konuk bağlantılarının kimlik doğrulama durumu için web sunucusunu düzenli aralıklarla yoklayabilir. Veya müşteri, oturum açma işleminin tamamlanıp tamamlanmadığını görmek için web sunucusunu periyodik olarak sorgulayabilir ve bu durum olduğunda, oyun sunucusuna web sunucusundan doğrulama isteğinde bulunabilir.

Bunların tümü, oyun sunucunuzun ve web sunucunuzun iletişim kurabilmesini gerektirir, ancak herhangi bir üçüncü taraf kimlik doğrulama hizmeti, oyun sunucunuzun dış dünyayla iletişim kurabilmesini gerektirir, bu nedenle bu bir sürpriz olmamalıdır.

Bu kimlik doğrulama yöntemi, bazı küçük ila orta ölçekli MMO'larda bulunur.

Bunların hepsinin, PayPal, Amazon Ödemeleri, Google Cüzdan vb. Gibi harici bir servis aracılığıyla ödeme talepleri için de işe yaradığını unutmayın.

Doğrudan TLS Bağlantısı

Özel bir akış protokolü üzerinden bir TLS oturumu başlatmak çok zor değil. OpenSSL, GnuTLS, NSS ve çeşitli işletim sistemlerine özgü kütüphaneler gibi kütüphaneler, düşük seviyeli bir aktarım / protokol üzerinde katmanlaşan bir akış sarmalayıcı API sağlar. Genellikle sarmalayıcı API'si aracılığıyla baytları beslemeniz gerekir ve el sıkışma ve şifreleme ile ilgilidir.

Buradaki zorlu parçalar, TLS kullanımınızın güvenli olmasını sağlıyor. Örneğin ortak kütüphanelerden bazıları varsayılan olarak güvenilir bir otoriteden geçerli bir imzalı sertifika gerektirir. Ortak kütüphanelerden bazıları bunu gerektirir, ancak varsayılan olarak hiçbir yetkiliye güvenmeyin. Bazıları, sertifikanın geçerli olmasını gerektirmez.

Her zaman geçerli bir sertifika almanız önerilir. Geçersiz sertifikalara izin vermek, yalnızca bir şifre çalmak için gizlice arama yapan bir saldırgana izin vermez, ancak yine de ortadaki adam saldırılarına izin verir.

Bu yaklaşım, yine de maksimum güvenceye izin verirken, en azından dış bağımlılıklar açısından mutlak gerektirir.

Bunu kullanan oyunlara örnekler şimdi en büyük geleneksel MMO'ları içeriyor.

Güvenli (ish) Geleneksel Oyunlar

Ayrı bir servis kullanmayan ve TLS kullanmayan oyunların genellikle ana oyun protokollerinde bir tür olmayan temeli giriş protokolü uygulaması gerekir. Bu yöntemle, sunucu rasgele bir sayı (bir noce) üretir ve bunu müşteriye gönderir. İstemci daha sonra kullanıcının parolasıyla (ve kullanıcı adıyla, muhtemelen başka bir veriyle) ilgisi yoktur ve bu cevabı sunucuya gönderir. Sunucu daha sonra bu karma değeri, dosyadaki kimlik bilgileriyle karşılaştırır. Bu, kullanıcının şifresini tel üzerinden gizlice tutar ve diğer birçok zayıf karma tabanlı oturum açma planı gibi, karma şifreye basit bir tekrarlama saldırısı kullanmamanızı sağlar.

Bir sorun, kullanıcının bu protokol üzerinden güvenli bir şekilde servise yeni bir şifre göndermesinin hiçbir yolu olmamasıdır. Tipik uygulamalar da kullanıcı şifresini sunucuda düz metin olarak saklar; bu korkunç bir uygulamadır (sunucunuz hacklenirse, kullanıcı muhtemelen e-posta / facebook / banka şifresini çaldırmıştır, çünkü oyununuz için aynı şifreyi kullanıyordur) her yerde, çünkü kullanıcılar bunu yapmaya meyillidir).

Bu temel giriş planının geliştirilmiş versiyonları var. En temel - hala ideal olarak güvenli olmasa da - sunucunun oturum açma sırasında nonce değeri olan şifre karma tuzunu göndermesidir. Bu, sunucunun bir şifreleme (ve tuzlanmış) şifresini güvenli bir şekilde saklamasına ve müşterinin oturum açma sırasında aynı hash oluşturmasına izin verir. Bu, bir saldırganın belirli bir kullanıcının şifresi için tuz almasına izin verir, ancak orijinal karma şifreyi (oturum açma sırasında tel üzerinden gönderilmez) almadan da özellikle yararlı değildir. Şifrenin oluşturulması / güncellenmesi sırasında müşteri, saldırganın koklayabileceği tüm şifreli şifreyi (tuzlu) gönderir. Kullanılan karma işlevi yeterince güçlü ise (örneğin, sha-2/512), saf kaba zorlama mümkün değilse, Saldırgan zayıf parolaları kolayca kolayca zorlayabilse de (bu nedenle bazı minimum parola uzunluklarını zorlamak, minimum harf / sayı / simge dağıtımı yapmak ve bilinen / açık / zayıf parola sözlüğüyle karşılaştırmak önemlidir). Saldırganın hala şifreli parola alabilmesi gerçeği, parola değişiminin tamamını güvenli, şifreli bir kanal üzerinden yapmanın neden daha güvenli olduğunu gösteriyor.

Çok sayıda popüler oyun ağ kütüphanesi bu protokolün isteğe bağlı bazı formlarını uygular. SmartFox'un böyle bir örnek olduğuna inanıyorum, ancak derinlemesine bakmadım (genellikle bu tür herhangi bir kütüphane auth sistemini görmezden geliyorum ve HTTPS yöntemini kullanıyorum, çünkü uygulanması çok basit ve çok daha güçlü). Bazı Web dışı internet oyunları da, özellikle Steam, XBL vb. Gelmeden önce bu yaklaşımı kullandı.

Güvensiz Geleneksel Oyunlar

Maalesef pek çok oyun plaintext biçiminde bir kullanıcı adı / şifre gönderir. Belki de belli belirsiz bir şekilde kullanıcıların gerçek şifrelerini (neredeyse yeterince iyi değil) koruyan şifreleri vardır, ancak bir tekrarlama saldırısı oyun hizmetine giriş yapmayı önemsiz kılar.

Bunu yapma Sorumsuz ve tembel. Bu giriş yöntemlerini popülerleştiren 1990'lı yılların Internet safhası artık geçerli bir bahane değil.

Birçok Facebook öncesi Flash öncesi ve web oyunları bu yaklaşımı benimsemiştir. Kafamın üstündeki özel örnekleri bilmiyorum; Uzun zaman öldüklerine inanmak isterdim, ama dünya o kadar şanslı değil.

Kimlik doğrulama yok

Çoğu oyun sadece doğrulama yapmaz. Oyuncu bağlanır, kendini benzersiz bir şekilde tanımlamak için bir tutamaç gönderir ve bir maç başlar. Yalnızca gerçek bir insanın "CaptainMisterDude" olduğunu iddia edebileceğini doğrulamaya çalışan bir global sunucu yoktur. Yerel sunucu yalnızca şu anda bağlı bir oynatıcının belirli bir tanıtıcıya sahip olmasını sağlar ve bu da sonudur. Yerel sunucular, sorun yapanlar için ad tabanlı ve IP tabanlı kara liste kullanır. Bu, bugün bile FPS deathmatch tarzı oyunlar için yaygındır.

Hesaplar için kalıcı bir duruma ihtiyacınız yoksa, bu en kolay çözümdür ve oldukça "güvenlidir" çünkü orada çalınacak veya çalınacak hiçbir şey yoktur. Açıkça, oyun oturumları arasında hesap bilgilerini kaydetmeniz gerekiyorsa, bu çok iyi çalışmaz.

Quake, bu "kullanıcıların kimliğini doğrulama" yöntemini kullanan bir oyuna örnektir.


1
Neden HTTPS hakkında bu kadar çok yazıyorsunuz? HTTP özellikle bir oyun protokolü için uygun değildir. Bir TLS tünelinde bir amaca yönelik ikili protokol kullanılmalıdır.
aaaaaaaaaaaa

10
Giriş için mi? Mükemmel derecede uygun. Saniyede 30 kez giriş yapmazsınız. İstemciyi başlattığınızda bir kez giriş yaparsınız ve bitirdiniz. HTTPS girişi, amaca yönelik oluşturulmuş ikili protokolün, şifreye gerek kalmadan bağlantıyı doğrulamak için kullandığı bir tanımlama bilgisi döndürür.
Sean Middleditch

1
Bunun bir performans sorunu olmaması, gereksiz bir karmaşıklık katan şişirilmiş bir yaklaşım olmadığı anlamına gelmez.
aaaaaaaaaaaa

4
Önerilen yaklaşımını tarif etmek için de aynı kelimeleri kullanırdım. Herkesinki kendine. :)
Sean Middleditch

2
Öyleyse, 2 dizeyi tek yönlü göndermek ve 1 geri almak için bir HTTP kütüphanesinin tamamını ekler miydiniz, yoksa kaçış dizisi işleme dahil gerekli HTTP alt kümesini kendiniz mi uygularsınız?
aaaaaaaaaaaa

3

SSL, müşterilerin bilinen bir CA tarafından imzalanmış bir sunucu sertifikası kullanarak "sahte" sunucular gibi yasal sunucuları tanımlamalarına yardımcı olur. Oyunların çoğunun bunu yapmakla uğraşmadığından şüpheleniyorum.

Bununla birlikte, istemek için iyi sebepler var. Bazı lisanslamadan kaçınma / hile alma mekanizmaları, sahte bir sunucu veya "ortadaki bir adam" sunucusunu kullanarak çalışabilir.

Steam ve Microsoft gibi büyük çok oyunculu ağların böyle bir korumaya sahip olmasını bekliyorum.

Web tabanlı oyun basitçe HTTPS kullanabilir, ancak bunun Websockets için işe yarayıp yaramadığını bilmiyorum (önemsiz bir Google buna cevap vermelidir).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.