Esta es más una pregunta / desafío de diseño del sistema que una pregunta de codificación.
Básicamente, estoy pensando en armar un juego Bejeweled -esque en Facebook usando solo HTML, CSS y JavaScript. Esto es principalmente por el deseo de aprender todas las pequeñas advertencias de FBJS a través de un proyecto no trivial.
Así que aquí está el trato. Al desarrollar para Facebook, las llamadas API reales son muy costosas; no solo hay un POST adicional para los servidores de Facebook, también hay un límite de llamadas api y aceleración de las que preocuparse. En pocas palabras, cuantas menos llamadas a Facebook, mejor. Combine esto con las preocupaciones de sincronización incluso de este simple juego de acertijos, y hay buenas razones para minimizar agresivamente el número de devoluciones de llamadas en general.
Al no ser un experto en seguridad, aquí está el diseño que he ideado:
- Incruste una semilla aleatoria en la página del juego.
- Use esa semilla para crear el tablero de juego (así como piezas adicionales según sea necesario).
- Ajusta la semilla (xor, concatenate y hash, algo así) después de cada movimiento del jugador, en función del tiempo transcurrido desde el último movimiento. Editar: Probablemente también debería incluir el movimiento real en la mutación de la semilla.
- Al completar el juego, publique lo siguiente: la hora de inicio del juego, cada movimiento realizado y cuándo, y los resultados del lado del cliente.
- En el servidor, vuelva a ejecutar el juego con los datos proporcionados, la cordura controlando la hora de inicio y los tiempos de traslado, y luego confirme que los resultados coinciden.
- Para mitigar la denegación de servicio, el juego en sí será ajustado para tener una condición de victoria por turno X.
- Para desalentar el uso del servidor como un oráculo de tipo, un usuario que publique un juego inválido será prohibido por un tiempo constante X (siendo X del orden de minutos).
Este diseño requiere tres llamadas de Facebook por juego: una para almacenar la semilla aleatoria antes de que se juegue el juego, una para buscarla después de que el juego haya terminado, y otra para actualizar el puntaje del jugador si el juego es válido.
Lo que intento probar con el sistema es la suplantación de puntuación directa ( http: // ...? Myscore = 999999999 , o similar). También me gustaría mitigar los ataques de mirar hacia adelante, en los que el usuario puede decir qué piezas vendrán a continuación al tablero. Los ataques de denegación de servicio en el servidor de alojamiento (intencional o no) también deben evitarse.
La pregunta real, ¿alguien puede ver un defecto en este diseño? Equivalentemente, ¿hay un diseño más simple que cumpla con mis criterios?
Nota: soy consciente de lo innecesario que probablemente sea esto, pero es una pregunta interesante, no obstante.
Voy a tratar de arrojar algunos números aquí para ilustrar mejor mi razonamiento, estos son bastante difíciles, pero espero que sean útiles.
Suponiendo un tablero de juego 10x10, hay ~ 200 movimientos potenciales (intercambio de dos piezas adyacentes) la mayoría de los cuales no son válidos. Digamos que hay en promedio 5 movimientos válidos por turno. Si limitamos las acciones de los jugadores al marco de 50 a 30,000 milisegundos, hay 149,750 hashes nuevos potenciales siempre que el algoritmo tweaking no descarte bits; Me siento seguro al decir que hay al menos 10,000 nuevas hashes potenciales que deben ser calculadas por un atacante suponiendo que se utiliza un hash criptográficamente seguro. Si arroja un algoritmo min-max en esto, su árbol de decisión explota muy rápidamente. Lanza una caducidad de la sesión del juego en este momento, digamos 30 minutos, y creo que el ataque es equivalente en complejidad a la escritura de un pequeño programa bot para jugar para ti que no puede defenderse razonablemente.
