Idee per la progettazione di un metodo sicuro, "Low Cost" per la conferma del lato client i risultati dei giochi

voti
3

Questo è più un progetto di sistema domanda / sfida, di una domanda di codifica.

Fondamentalmente, io sto pensando di lanciare insieme una Bejeweled gioco -esque su Facebook utilizzando solo HTML, CSS e JavaScript. Questo è per lo più da un desiderio di imparare tutti i piccoli avvertimenti di FBJS tramite un progetto non banale.

Quindi, ecco l'affare. Quando si sviluppa per Facebook, chiamate API reali sono molto costosi; non solo non c'è un posto supplementare per i server di Facebook, c'è anche il limite di chiamata API e la limitazione di cui preoccuparsi. In poche parole, il minor numero di chiamate verso Facebook, meglio è. Combinate questo con le preoccupazioni di temporizzazione anche questo semplice gioco di puzzle, e c'è una buona ragione per ridurre al minimo in modo aggressivo il numero di callback in generale.

Non essendo un esperto di sicurezza, ecco il disegno mi è venuta in mente:

  1. Incorpora un seme casuale nella pagina del gioco.
  2. Utilizzare quel seme per creare il piano di gioco (così come pezzi aggiuntivi, se necessario).
  3. Tweak il seme (XOR, concatenare e hash, qualcosa di simile) dopo ogni mossa giocatore, in base al tempo dall'ultima mossa. Edit: Probabilmente dovrei comprendere anche il movimento reale presa in mutare il seme.
  4. Al termine del gioco post indietro il seguente: tempo di gioco si avvia, ogni mossa preso e quando, ed i risultati lato client.
  5. Sul server, eseguire nuovamente il gioco con i dati forniti, la sanità mentale controllando l'ora di inizio e spostare i tempi, e quindi confermare che i risultati partita.
  6. Per mitigare negazione del servizio, il gioco sarà ottimizzato per avere una vittoria da condizione di girare X.
  7. Per scoraggiare il server utilizzato come Oracle di sorta, un utente postback un gioco non valida sarà vietato per qualche tempo costante X (X essendo dell'ordine di minuti).

Questo disegno richiede tre Facebook chiamata al gioco giocato: di memorizzare il seme casuale prima che il gioco è giocato, uno a prenderlo dopo la partita è finita, e uno per aggiornare il punteggio del giocatore se il gioco è valido.

Quello che sto cercando di prova il sistema contro è verso l'alto punteggio spoofing ( http: // ... myScore = 999999999 , o simili). Mi piacerebbe anche a mitigare guardare avanti attacchi, in cui l'utente può dire quali pezzi stanno arrivando alla scheda successiva. Attacchi denial of service sul server di hosting (intenzionale o meno) dovrebbe anche essere evitata.

La domanda attuale, chiunque può vedere un difetto in questo progetto? Equivalentemente, c'è un disegno più semplice che soddisfa i miei criteri?

Nota: io sono consapevole di come inutile questo probabilmente è, ma la sua un'interessante domanda comunque.


Io vado a cercare di gettare un po 'i numeri fino qui per futher illustrare il mio ragionamento, questi sono piuttosto grezzi ma spero utile.

Assumendo un bordo 10x10 gioco, ci sono ~ 200 potenziali mosse (scambiando due pezzi adiacenti) la maggior parte dei quali non sono validi. Diciamo che ci sono in media 5 mosse validi per girare. Se limitare le azioni del giocatore al telaio 50 a 30.000 millisecondi, ci sono 149,750 potenziali nuovi hash fornite l'algoritmo ritocco non disfarsi bit; Mi sento fiducioso nel dire che ci sono almeno 10.000 potenziali nuovi hash che devono essere conteggiati da un utente malintenzionato assumendo un hash crittograficamente sicuro viene utilizzato. Se si lancia un algoritmo min-max a questo, la vostra decisione albero esplode molto rapidamente. Gettare un espirazione sessione di gioco a questo, diciamo 30 minuti, e credo che l'attacco in quanto equivalente in complessità a scrivere un piccolo programma bot a giocare per voi che non possono ragionevolmente essere difeso contro.

È pubblicato 26/05/2009 alle 22:04
fonte dall'utente
In altre lingue...                            


2 risposte

voti
3

Se il codice del client calcola il pezzo successivo e non si può nascondere questo algoritmo molto bene, poi qualche studente di college annoiato sarà questo numero. Di conseguenza, essi saranno in grado di generare un punteggio enorme e sconfiggere i tuoi propositi.

Risposto il 26/05/2009 a 22:14
fonte dall'utente

voti
0

Io tendo a dire che è impossibile da fare. Perché? Non si può fidare del cliente - ho potuto solo analizzare e completamente riscrivere il codice lato client e restituire tutto ciò che i valori che mi piace. L'unico modo per proteggere l'utente da truffe e tutti i tipi di attacchi è quello di eseguire la logica sul server - il cliente sarà solo raccogliere l'input dell'utente e visualizzare l'output del server. Ma questo è completamente contro il vostro obiettivo di progettazione per ridurre al minimo il numero di chiamate al server.

Risposto il 26/05/2009 a 22:20
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more