Background
Estoy diseñando un juego para varios jugadores con un solo servidor que maneja múltiples mundos. Cada jugador inicia sesión en el servidor inicialmente antes de solicitar a qué mundo unirse.
El servidor tiene una dirección IP fija que actualmente es la misma que la dirección IP del sitio. Esto puede cambiar en el futuro si los servidores necesitan ejecutarse en paralelo, sin embargo, a partir de ahora es una suposición segura de que el servidor es, de hecho, el servidor y no un impostor.
Las contraseñas en mi sitio se procesan mediante bcrypt y a salt, y se almacenan en una base de datos MySQL.
Actualmente no tengo un certificado SSL, aunque estoy planeando obtener uno lo antes posible y sin duda antes de que el sitio maneje los detalles de pago, pero es probable que el juego se conecte a través de una conexión TCP abierta, por lo que mi seguridad Las necesidades con respecto a la autenticación de los usuarios del juego deben manejarse manualmente.
Audiencia
El público principal del juego son los adolescentes jóvenes, pero especialmente aquellos que pueden escribir un pequeño código, por lo que puedo esperar que una pequeña cantidad de ellos sean programadores relativamente competentes y un subconjunto más pequeño para poder realizar ingeniería inversa y entrar en Un sistema inseguro.
Mi enfoque actualmente considerado
Pasé un rato pensando en este problema y encontré una solución que parece estar clasificada bajo un algoritmo de "desafío-respuesta", es decir:
- El cliente envía un nombre de usuario
- El servidor recibe & verifica el nombre de usuario y envía una solicitud de datos de contraseña junto con un token único . Mi idea actual para esto. El token único es generar una cadena aleatoria, MD5, luego anteponer una Único entero incremental para asegurar que tanto el mismo hash es Nunca se envía, y eso no es predecible.
- El cliente recibe el token y la contraseña de hashes usando bcrypt con lo conocido sal para obtener el valor en la base de datos del sitio web, y luego agrega la token antes de ejecutarlo de nuevo a través de bcrypt.
- El cliente envía este nuevo hash a través del socket
- El servidor lee esto, lo verifica y notifica al cliente que está ahora autenticado como el nombre de usuario que enviaron inicialmente.
Aims
Ningún dispositivo, pero el cliente verdadero y el servidor deberían poder encontrar la contraseña, o autenticarse a escondidas para intercambiar datos confidenciales.
Preocupaciones
Tengo un problema particular con este enfoque, ya que ahora los clientes deben conocer la sal secreta que he estado usando en mi sitio web para hacer hash de las contraseñas. Estoy luchando para piense en una razón por la cual esto compromete mi seguridad, pero se siente mal. Supongo que, en teoría, ahora pueden generar previamente las tablas del arco iris y luego, si consiguieran obtener una copia de mi base de datos, habría un tiempo mucho menor entre ellos para obtenerla y descifrar un número decente de contraseñas de usuarios, lo que significa que las cuentas de mis usuarios corren un mayor riesgo ya que tendrán menos advertencias en caso de que ocurra algo.
Fuera de esto, sin embargo, también apreciaría enormemente una evaluación de mi enfoque considerado y cualquier sugerencia o enlace que pueda ser útil para asegurarlo más.
¡Estoy más que feliz de responder cualquier pregunta! Gracias!