In particolare per quanto riguarda l'ultima parte della tua domanda: No, non è mai perdonabile avere un sistema di autenticazione non sicuro. Gli utenti sono raramente illuminati quando si tratta di sicurezza del computer. Gli utenti usano la stessa password per il tuo gioco come per il loro account Google, account Facebook, conto bancario e così via. Anche se puoi affermare che è colpa loro se usano cattive abitudini di sicurezza in Internet, sei tu quello che sarà ritenuto responsabile se il tuo gioco viene utilizzato come vettore di attacco per rubare le credenziali di accesso degli utenti. Come sviluppatore che conosce meglio, le uniche opzioni etiche sono di proteggere adeguatamente il processo di autenticazione o di non averne affatto.
Come alcuni consigli non richiesti ma correlati, gli utenti non vogliono essere comunque tenuti a registrarsi al gioco. Potrebbero farlo se vogliono giocare abbastanza male al tuo gioco, ma avere l'ennesimo login di Freaking per iscriversi sta per scacciare molti potenziali giocatori. Gli utenti sono stanchi di creare un nuovo account per ogni singolo sito, servizio e gioco, specialmente se richiedono qualsiasi tipo di convalida e-mail o simili. Se possibile, evitare di avere un accesso o utilizzare un servizio di autenticazione di terze parti con cui gli utenti probabilmente hanno già un account. Avrai più giocatori in quel modo. Questo è triplo se prevedi di avere qualsiasi tipo di acquisti in-app.
Giochi Web
Un'opzione popolare, in particolare per i giochi Web, sebbene funzioni anche per i giochi tradizionali, è quella di utilizzare un servizio di autenticazione di terze parti basato sul Web. Facebook e Google hanno entrambe API ben documentate (entrambe basate su API standardizzate, iirc) per l'autenticazione. Richiedono la possibilità di aprire una finestra del browser e indirizzare l'utente verso i loro servizi, ma questo è abbastanza facile da fare sulla maggior parte delle piattaforme non console, e ovviamente banale per i giochi Web.
Tali servizi si occupano di tutti i dettagli disordinati della crittografia del traffico di accesso via cavo, dell'archiviazione sicura delle credenziali di accesso e della convalida degli accessi utente. Il tuo server di gioco deve quindi implementare solo la parte del protocollo che riceve un cookie dall'utente e chiede al servizio di autenticazione se il cookie è valido o meno, il che può essere fatto con un semplice HTTP nella maggior parte dei casi.
Non pretenderò che la maggior parte dei giochi multiplayer tradizionali faccia questo, perché non lo fanno, ma affermerò che la maggior parte dei giochi Web casuali online lo fanno.
Per i giochi tradizionali (non Web), facilitare questa procedura di accesso è possibile incorporando un browser (Awesomium, Chromium Embedded Framework o direttamente Webkit essendo scelte popolari) o chiamando a un browser esterno (questo richiede un po 'più di fanagling per estrarre il cookie di autenticazione da, tuttavia, e non è affatto più semplice che incorporare una delle librerie sopra menzionate).
Un tipico esempio di questo approccio è qualsiasi gioco di Facebook.
Giochi tradizionali che utilizzano HTTPS
Avere un semplice servizio HTTPS per l'accesso è sempre più normale. Molti giochi usano protocolli personalizzati, ma la maggior parte di questi sono incompleti (hanno un accesso sicuro, ma non hanno un modo sicuro per creare / aggiornare un account, quindi necessitano comunque del servizio HTTPS) o sono semplicemente terribilmente insicuri.
Non è nemmeno necessario richiedere un certificato SSL personalizzato. Esistono provider di hosting di app online che offrono un sottodominio e utilizzano un certificato SSL con caratteri jolly. Puoi mettere il tuo servizio di autenticazione su mygame.someservice.com, che è coperto dal carattere jolly * .someservice.com che certi servizi mantengono e sei a posto.
L'idea qui è che l'utente acceda al tuo servizio, che genera un cookie di sessione univoco, che l'utente può quindi passare al tuo server di gioco principale. Il server quindi chiede al sistema di accesso se il cookie è valido per l'utente richiesto. Di solito c'è un timeout molto breve sul cookie, nell'ordine dei secondi (15-30, per esempio), ed è generalmente invalidato una volta usato, rendendo impossibili gli attacchi di replay.
Si noti che HTTPS è la mia opzione più consigliata se si prevede di inviare informazioni di pagamento via cavo dall'interno del client stesso. Tuttavia, è significativamente meglio utilizzare una terza parte per questo. Se ritieni che proteggere qualcosa di semplice come una password sia troppo impegnativo, non vorrai nemmeno pensare di provare a soddisfare le regole di conformità PCI minime (e onestamente del tutto inadeguate) per l'archiviazione e l'elaborazione dei numeri di carta di credito. Avrai comunque un migliore assorbimento delle vendite se hai utenti che utilizzano servizi di pagamento di terze parti affidabili con cui sono già in archivio.
Un grande vantaggio di separare il tuo servizio di accesso dal server di gioco principale è che consente di collegare funzionalità esterne agli account utente indipendentemente dal gioco. Potresti avere alcune funzionalità dell'account (visualizzazione di avatar o simili) sul tuo sito Web, o forse permetti di collegare account Facebook ai tuoi account, o forse hai più giochi che condividono una singola piattaforma di account sottostante (ad esempio, le funzionalità Galaxy at War di Mass Effect 3).
Un gioco di esempio popolare che utilizza HTTPS per l'autenticazione è Minecraft.
Autenticazione Web di terze parti con giochi Native Client
È possibile utilizzare servizi di terze parti come Facebook Connect o Google con un client nativo. Facebook ad esempio ha un SDK nativo per iOS e Android, così come Google. Alcuni servizi hanno anche SDK nativi per client PC tradizionali.
Se il servizio di destinazione non ha un SDK nativo e richiede l'uso di un browser Web, è possibile incorporare un browser nel gioco. Tuttavia, alcuni utenti potrebbero non avere fiducia nell'uso di un browser incorporato per inserire le informazioni di accesso.
Puoi anche usare un browser esterno. Ci sono alcuni modi per farlo. Alcuni richiedono un po 'più di integrazione del sistema operativo rispetto ad altri. Alcuni richiedono che tu abbia un servizio Web esterno in esecuzione accanto (o almeno raggiungibile dal) server di gioco principale. Tieni presente che poiché Facebook e Google richiedono generalmente un URL autenticato, avrai bisogno di una pagina di destinazione del sito Web pubblica per utilizzare questi protocolli in (quasi) tutti i casi.
Il più sicuro e affidabile, se non addirittura il più semplice, è far rimbalzare la tua richiesta di accesso dal tuo client attraverso il tuo sito Web principale. Il client si connette al server di gioco principale come utente guest autenticato e riceve un token di sessione univoco. Il server di gioco non consente al client di fare davvero molto mentre si trova in questo stato; il gioco non sa chi sia il giocatore, quindi il giocatore non può ancora chattare, iniziare una partita o così via.
Il client avvia quindi il browser esterno che punta all'URL di accesso del dominio del gioco, passando questo token di sessione come parametro nell'URL. Il sito passa quindi attraverso la consueta stretta di mano di accesso per Facebook / Google.
A questo punto, il tuo server web sa che l'utente ha effettuato l'accesso e può associarlo al token di sessione ricevuto dal client. Questa verifica può quindi essere comunicata al server di gioco, elevando la connessione guest non autenticata del client in una sessione utente autenticata. Questo può essere fatto facendo in modo che il server web comunichi direttamente con il server di gioco, se possibile. Oppure il server di gioco può eseguire periodicamente il polling del server Web per verificare lo stato di autenticazione delle connessioni guest in sospeso. Oppure il client può periodicamente eseguire il polling del server web per vedere se l'accesso è completo e, quando lo è, segnalare al server di gioco di richiedere la verifica dal server web.
Tutti questi richiedono che il server di gioco e il server web siano in grado di comunicare, ma qualsiasi servizio di autenticazione di terze parti richiederà che il server di gioco sia in grado di comunicare con il mondo esterno, quindi non dovrebbe essere una sorpresa.
Questo metodo di autenticazione si trova in alcuni MMO di dimensioni medio-piccole.
Nota che tutto ciò funziona anche per effettuare richieste di pagamento tramite un servizio esterno, come PayPal, Amazon Payments, Google Wallet, ecc.
Connessione TLS diretta
Non è troppo difficile avviare una sessione TLS su un protocollo di flusso personalizzato. Librerie come OpenSSL, GnuTLS, NSS e varie librerie specifiche del sistema operativo forniscono un'API wrapper di flusso che si sovrappone a un protocollo / trasporto di basso livello. In genere è sufficiente alimentare i byte tramite l'API wrapper e si occupa dell'handshake e della crittografia.
Le parti difficili qui assicurano che l'utilizzo di TLS sia sicuro. Alcune delle librerie comuni, ad esempio, richiedono per impostazione predefinita un certificato firmato valido da un'autorità attendibile. Alcune delle librerie comuni lo richiedono, ma per impostazione predefinita non si fidano di alcuna autorità. Alcuni di essi non richiedono affatto che il certificato sia valido.
Si consiglia di richiedere sempre un certificato valido. Consentire certificati non validi non consentirà a un utente malintenzionato che sta semplicemente intercettando di rubare una password, ma consentirà comunque attacchi man-in-the-middle.
Questo approccio richiede il minimo assoluto in termini di dipendenze esterne pur garantendo la massima sicurezza.
Esempi di giochi che usano questo includono ora i MMO tradizionali più grandi.
Giochi tradizionali sicuri (ish)
I giochi che non usano un servizio separato e che non usano TLS in genere devono implementare una sorta di protocollo di accesso nonce-based nel loro protocollo di gioco principale. Con questo metodo, il server genera un numero casuale (un nonce) e lo invia al client. Il client quindi esegue l'hashing di quel nonce con la password dell'utente (e il nome utente, possibilmente alcuni altri dati) e invia tale risposta al server. Il server quindi confronta questo valore con hash con le credenziali presenti nel file. Ciò mantiene la password dell'utente segreta via cavo e garantisce che non è possibile utilizzare un semplice attacco di riproduzione sulla password con hash, come molti altri schemi di accesso basati su hash deboli.
Un problema è che l'utente non ha modo di inviare una nuova password al servizio tramite questo protocollo in modo sicuro. Le implementazioni tipiche memorizzano anche la password dell'utente in chiaro sul server, il che è una pratica orribile (se il tuo server viene violato, probabilmente è stata rubata la sua password email / facebook / bank, perché stava usando la stessa password per il tuo gioco come ovunque, perché gli utenti tendono a farlo).
Esistono versioni avanzate di quello schema di accesso di base. Il più semplice, sebbene non sia idealmente sicuro, è che il server invii la password hash salt con il valore nonce durante il login. Ciò consente al server di archiviare una password con hash (e salata) in modo sicuro consentendo al client di generare lo stesso hash durante l'accesso. Ciò consente a un utente malintenzionato di ottenere il salt per la password di un determinato utente, ma ciò non è particolarmente utile senza ottenere anche la password con hash originale (che non viene inviata via cavo durante l'accesso). Durante la creazione / aggiornamento della password, il client invia l'intera password con hash (con salt), che l'utente malintenzionato può annusare. Se la funzione hash utilizzata è abbastanza potente (diciamo, sha-2/512), la forzatura bruta pura non è fattibile, sebbene l'attaccante possa ancora facilmente forzare le password deboli (motivo per cui è importante imporre una lunghezza minima della password, una distribuzione minima di lettere / numeri / simboli e il confronto con un dizionario di password conosciute / ovvie / deboli). Il fatto che l'attaccante possa ancora ottenere la password con hash è il motivo per cui è ancora più sicuro eseguire l'intero scambio di password su un canale crittografato e protetto.
Numerose librerie di rete di giochi popolari implementano una forma opzionale di questo protocollo. Credo che SmartFox ne sia un esempio, sebbene non lo abbia esaminato in modo approfondito (generalmente ignoro qualsiasi sistema di autenticazione della libreria e utilizzo il metodo HTTPS, poiché è molto semplice da implementare e significativamente più potente). Anche alcuni dei primi giochi Internet non Web utilizzavano questo approccio, in particolare prima che arrivassero Steam, XBL e così via.
Giochi tradizionali non sicuri
Molti giochi sfortunatamente inviano semplicemente un nome utente / password in chiaro. Forse hanno la password, che in qualche modo protegge la password effettiva dell'utente (non abbastanza bene) ma un attacco di replay rende banale l'accesso al servizio di gioco.
Non farlo È irresponsabile e pigro. L'ingenuità su Internet degli anni '90 che ha reso popolari questi metodi di accesso non è più una scusa praticabile.
Molti dei primi giochi Flash e web pre-Facebook hanno adottato questo approccio. Non conosco esempi specifici dalla parte superiore della mia testa; Mi piacerebbe credere che siano tutti morti da molto tempo, ma il mondo non è poi così fortunato.
Nessuna autenticazione
La maggior parte dei giochi non esegue l'autenticazione. Il giocatore si connette, manda un po 'di maniglia per identificarsi in modo univoco e inizia una partita. Non esiste un server globale che tenti di convalidare che solo un vero essere umano può mai rivendicare di essere "CaptainMisterDude". Il server locale garantisce che solo un giocatore attualmente connesso abbia un handle particolare, e questa è la fine. I server locali utilizzano la blacklist basata su nomi e basata su IP per i piantagrane. Questo è comune per i giochi in stile deathmatch FPS anche oggi.
Se non hai bisogno di uno stato permanente per gli account, questa è di gran lunga la soluzione più semplice e abbastanza "sicura" dal momento che non c'è nulla lì per hackerare o rubare. Ovviamente questo non funziona troppo bene se è necessario memorizzare le informazioni sull'account tra le sessioni di gioco.
Quake è un esempio di gioco che utilizza questo metodo di "autenticazione" degli utenti.