Aplicación nativa, autenticación de token sin inicio de sesión / contraseña

¿Cuál es tu modelo de amenaza?

Si todas las conexiones se envían a través de SSL, no tiene que preocuparse por que nadie pueda detectar sus comunicaciones. Esta es en realidad la parte más fuerte de su sistema. Buen trabajo eligiendo algo estándar.

Debido a que SSL garantiza que nadie esté escuchando sus comunicaciones, deberíamos mirar los puntos finales. Tu UUID es básicamente un secreto compartido. Cualquiera con este UUID podrá imitar a sus usuarios.

En cuanto a cifrarlo o codificarlo, no. No molestar. Si tienen acceso a su UUID cifrado, ciertamente tienen acceso al código fuente de su juego, que debería contener la contraseña. Cualquier cosa que pudiera impedir que un atacante se autentique también evitaría que un cliente se autentique.

Necesitas desarrollar un modelo de amenaza. ¿Qué haría un atacante si consiguieran un UUID? Si todo lo que pueden hacer es comprar juegos para esa cuenta, entonces es muy poco lo que pueden obtener al tener un UUID. Podrían intentar enojar a un cliente robando el UUID y usándolo para comprar un montón de cosas que el cliente no quería, pero si puedes reembolsarlo, tampoco pueden enojar a un cliente.

Por otro lado, si los UUID se pueden usar para comprar cosas que son útiles para otros, entonces tienes más incentivos para que los atacantes los roben. Si pueden ser útiles para la mafia, entonces tienes una amenaza aún mayor, ya que podrían lanzar una de sus botnets a tu sistema.

Toda la seguridad se basa en un modelo de amenaza. Nada es perfectamente seguro. Como dijo una vez Kevin Mitnick, "la única computadora completamente segura es una que está desconectada de Internet, apagada, encerrada en el cemento en la parte inferior de un silo protegido por guardias armados. Incluso entonces, lo revisaría una vez en una mientras. "

  

Este UUID se almacena en el dispositivo (¿debo cifrarlo o hacer un hash?):

• Para la aplicación de Android, puede utilizar esta library , que es una contenedor cifrado para SharedPreferences, porque SharedPreferences en Android almacena los datos en "texto simple", por lo que un atacante puede tener fácilmente acceso a estos datos.
• Para la aplicación iOS: Keychain es un lugar seguro de almacenamiento de credenciales y sensible información, pero no es difícil entrar en ella tampoco especialmente en dispositivos con jailbreak).

  

Cuando el usuario comienza el juego, lo autentico con un token   (UUID + marca de tiempo + hmac (sha256, nombre de usuario + marca de tiempo, K)). Es mejor   generar un token de sesión temporal (almacenado en la base de datos) o podría   ¿Usar el token anterior para todas las solicitudes después de la autenticación?

El token de acceso se debe administrar en el lado del servidor, ya que se puede modificar en el lado del cliente (por ejemplo: un atacante puede cambiar el valor de la marca de tiempo actual del dispositivo), y el token de acceso generalmente es temporal, por lo tanto, debe actualizarlos después de un cierto tiempo dependiendo de la criticidad de su aplicación.