¿Es esta solución RESTful y segura?

Nuestro producto registra nuevos jugadores en nuestro servicio, y hemos elegido alojarlo en Azure (estamos usando .NET) y queríamos que no tuviera estado (por escalabilidad) y relativamente seguro.

Dado que este es el primer REST WS que estoy escribiendo, quería obtener algunos comentarios sobre si es una solución sólida o no.

Algunas presunciones para saber sobre nuestra aplicación:

1. Los usuarios inician sesión en el servicio de forma anónima, sin requerir una contraseña de un usuario
2. El WS debe estar completamente sin estado para permitir el escalado horizontal
3. Nos estamos conectando usando HTTPS (SSL) para evitar la intromisión de terceros

EDITAR:

1. Apuntamos a dispositivos iOS / Android nativos
2. Nuestra principal preocupación es asegurarnos de que solo los clientes no manipulados puedan enviar solicitudes

Y el proceso de autenticación abstracta:

1. El cliente crea un hash simple (UDID: Timestamp) y lo encripta usando la marca de tiempo con algún algoritmo básico (por ejemplo, la clave secreta es cada segundo carácter del hash)
2. El cliente envía su UDID, marca de tiempo y hash al servidor
3. El servidor reconstruye el hash y descifra el hash cifrado enviado por el usuario
4. Si los dos son iguales, sabemos que en realidad fue enviado desde nuestro cliente (y con suerte no desde un remitente malicioso)

Cualquier entrada / sugerencia sería genial, obviamente, ya que es la primera vez que manejo este problema, podría haberlo diseñado incorrectamente.

¡Gracias!

2da actualización:

Al leer las especificaciones de seguridad para OAuth, parece que no hay una respuesta real a mi pregunta, ya que el cliente y el servidor deben conocer las claves secretas y el cliente se almacena localmente en los dispositivos móviles de nuestros usuarios (en lugar de una aplicación web).

De la guía de seguridad de OAuth ( http://hueniverse.com/oauth/guide/security/ ):

Al implementar OAuth, es fundamental comprender las limitaciones de los secretos compartidos, simétricos o asimétricos. El secreto del cliente (o clave privada) se utiliza para verificar la identidad del cliente por parte del servidor. En el caso de un cliente basado en la web, como un servidor web, es relativamente fácil mantener el secreto del cliente (o clave privada) confidencial.

Sin embargo, cuando el cliente es una aplicación de escritorio, una aplicación móvil o cualquier otro software del lado del cliente, como applets del navegador (Flash, Java, Silverlight) y scripts (JavaScript), las credenciales del cliente deben incluirse en cada copia de la aplicación . Esto significa que el secreto del cliente (o la clave privada) debe distribuirse con la aplicación, lo que los compromete de forma heredada.

Esto no impide el uso de OAuth dentro de dicha aplicación, pero limita la cantidad de confianza que el servidor puede tener en tales secretos públicos. Dado que no se puede confiar en los secretos, el servidor debe tratar dicha aplicación como entidades desconocidas y usar la identidad del cliente solo para actividades que no requieren ningún nivel de confianza, como la recopilación de estadísticas sobre las aplicaciones. Algunos servidores pueden optar por prohibir dicha aplicación u ofrecer diferentes protocolos o extensiones. Sin embargo, en este punto no existe una solución conocida para esta limitación.

Esto está algo fuera de lugar en una tangente pero, desde un punto de vista de seguridad, cualquier secreto que esté en un cliente no es un secreto. Usted declara en su pregunta que.

Nuestra principal preocupación es asegurarnos de que solo los clientes no manipulados puedan enviar solicitudes.

Como alguien que ha trabajado en la industria del juego, esta es una causa perdida. Si hay suficiente valor para poder enviar solicitudes arbitrarias, los usuarios descubrirán cómo enviar esas solicitudes. Nunca puede confiar en poder saber si una solicitud proviene de un cliente confiable. Aquí hay algunos consejos de mis experiencias.

• Mantenga la copia canónica del estado del juego en el servidor
• Calcule qué cambios en el estado puede hacer cada usuario y haga que el servidor compruebe si hay una violación.
• Tenga límites de velocidad sobre la rapidez con que los usuarios pueden subir de nivel o ganar divisas / artículos para atrapar guiones.
• Si el tramposo no puede afligirse, otros jugadores no los prohibirán. Muchos tramposos también gastan.
• Tenga controles sociales sobre los tramposos, es decir, para que los tramposos se vuelvan obvios para sus amigos. Si puedes tener una lógica coincidente, los tramposos serán eliminados de jugar contra sus amigos.

La clave sobre REST es que está utilizando las funciones inherentes en http:

• OBTENER: para simplemente recuperar datos
• POST: para insertar un nuevo punto de datos
• PUT: para actualizar un punto de datos
• ELIMINAR: para eliminar un punto de datos

Parte de la otra orientación es que sus urls deben ser intuitivas, es decir, si su url para jugadores es http://example.com/api/playeruna forma sensata de exponer su último historial de puntajes http://example.com/api/player/1/scores(es decir, los puntajes para la identificación del jugador 1).

En cuanto a la seguridad, lo que ha leído de la especificación OAuth es muy cierto ... si está incorporando algún tipo de clave privada en un binario que otras personas pueden tener en sus manos, no puede asumir que es completamente privado. Sugeriría que si tiene algún tipo de clave privada en su código, lo configura para que pueda expirarlo y luego envíe una actualización para cambiarlo. Por supuesto, aproveche la oportunidad para protegerlo con cifrado y todo lo demás, pero facilite la desactivación si se piratea. La realidad es que Twitter y otros sufren este mismo desafío, donde de vez en cuando se descubren y publican las claves secretas de sus aplicaciones oficiales en Internet, y tienen que actualizar sus aplicaciones.