¿Es este un esquema de intercambio de datos seguro para un juego?

En primer lugar, crypto es difícil, y no deberías crear tu propio .

Vulnerabilidades

Su inicio de sesión parece sufrir un pase la vulnerabilidad de hash . Un atacante no necesita descifrar el hash para iniciar sesión, solo puede pasar el hash y se conectará. Esto anula el propósito de hash de la contraseña en primer lugar.

sha512 no se recomienda para almacenar contraseñas, ya que es demasiado rápido . Utilice algo como bcrypt en su lugar.

HTTPS y cifrado

Usted dice que RSA es demasiado caro. Pero, en general, RSA solo se usa para intercambiar una clave, que luego se usa con un sistema de cifrado de claves privadas mucho menos costoso.

Como aclaró que utiliza HTTPS, debe tener en cuenta que ya utiliza RSA. HTTPS usa RSA o diffie hellman para el intercambio de claves y algunos cifrados de secuencia o de bloque para el cifrado de datos real.

A medida que usa HTTPS, ya tiene confidencialidad e integridad de los datos (y la autenticación del servidor y, opcionalmente, la autenticación del cliente), no es necesario un cifrado adicional en el nivel de la aplicación.

¿Ventajas de tu esquema?

Tu esquema realmente no parece servir a ningún propósito. Ya estás seguro de las escuchas ilegales y la manipulación de datos a través de HTTPS (y tu esquema no lo habría impedido de todos modos).

Por lo tanto, su esquema no parece tener que ver con el intercambio de datos, sino con la autenticación.

En general, la autenticación se maneja así:

Login:

• El cliente envía el nombre de usuario y la contraseña (sin formato)
• La contraseña del hash del servidor y compara el hash con el hash en db
• El servidor envía el ID de sesión de vuelta

Otras solicitudes:

• El cliente envía el ID de sesión
• El servidor valida el ID de sesión
• (opcional) cuando el estado de la sesión cambia, el servidor regenera el ID de sesión

Su enfoque es similar, pero introdujo el pase la vulnerabilidad de hash y contiene una semilla, que parece ser innecesaria y por lo tanto solo complica el esquema. También regenera el ID de sesión en cada solicitud, que no es realmente necesaria y solo parece causar una sobrecarga innecesaria.

  

... El cliente envía una solicitud de "inicio de sesión" con nombre de usuario, hash y semilla al servidor.

Dado que el cliente crea la semilla, la combinación de semilla y hash forma efectivamente una contraseña equivalente que puede repetirse una y otra vez. Probablemente estés intentando implementar algo similar a Autenticación de resumen aquí. Pero con la autenticación de resumen, el nonce (es decir, su "semilla") está determinado por el servidor y no por el cliente y, por lo tanto, es seguro contra los ataques de repetición.

Aparte de eso: ya está utilizando HTTPS, que protege el tráfico contra el rastreo y la modificación. ¿Por qué construir otro mecanismo de seguridad encima? La autenticación implícita se usa generalmente para conexiones que no están cifradas y tiene el problema de que necesita tener la contraseña en claro (o equivalente) en el servidor. Si la conexión ya está protegida contra el rastreo, no necesita protección adicional para la contraseña y puede enviarla de forma clara. Esto tiene la ventaja de que puede almacenar la contraseña como un hash irreversible en el servidor.