Asegúrese de que solo las aplicaciones autorizadas acceden al servicio web

La conclusión es que necesitará incrustar un secreto en su aplicación. Es una verdad desafortunada que DRM (que es más o menos lo que estás tratando de lograr) es imposible. Una persona con acceso a tu aplicación siempre podrá recuperar el secreto incorporado, sin importar lo que hagas para protegerla.

Dicho esto, hay muchas cosas que puedes hacer para que tu secreto incrustado sea muy difícil de recuperar.

• Constrúyalo en tiempo de ejecución : no almacene el secreto en una cadena o archivo de configuración en ninguna parte de su aplicación. En su lugar, derivarlo de una serie de cálculos en tiempo de ejecución. Esto evita que los atacantes simplemente naveguen su aplicación con un hexeditor.

• Nunca lo envíe por el cable : use un sistema de respuesta-desafío de algún tipo con un > 128bit nonce, de esa manera un atacante no puede mitigar el flujo SSL (lo cual es fácil cuando controla el dispositivo móvil, recuerda) y ve el secreto a la vista.

En cualquier caso, intente encontrar un mecanismo de cifrado de claves y un protocolo de autenticación probados y probados. No ruedes el tuyo.

La mayoría de las veces no puede comprobar que esta es "su aplicación": ingeniería inversa funciona, por lo que quienquiera tenga acceso a su aplicación. (por ejemplo, puede descargarlo en su teléfono) puede tirar de sus entrañas y emularlo con su PC. @Lynks le da algunos consejos sobre cómo esta ingeniería inversa se puede convertir en un esfuerzo más frustrante, pero no se engañe: si el atacante está lo suficientemente motivado, estos mecanismos lo reducirán al menos un par de días. >

Cuando no hay una buena respuesta para una pregunta, puede valer la pena cambiar el terreno para que la pregunta cambie. Aquí, el problema central al tratar de asegurarse de que "su aplicación" es lo que se ejecuta en el lado del cliente es que existe tal cosa como "su aplicación": si alguien abre el contenido de esa aplicación, aprende todo lo que es para conocer todas las instancias de esa aplicación en todas partes.

Así que aquí hay un intento de solución a su problema. Etiquete cada instancia de aplicación con un valor distinto. "Etiquetar" aquí significa que cuando el usuario descarga la aplicación, se inserta un token en la aplicación y se crea un nuevo valor de token para cada descarga. Para que cada usuario obtenga su propia aplicación con token. La idea es que el token deberá presentarse a su servidor para la creación de la cuenta, y si su servidor ve demasiadas solicitudes con el mismo token, entonces puede rechazarlas automáticamente, prohibiendo ese token específico.

Luego, para seguir creando muchas cuentas automáticamente, el atacante también tendría que automatizar la descarga de nuevas instancias de la aplicación (cada una con su propio valor de token) y la recuperación del valor del token de la aplicación descargada. Suponiendo que su servidor se encuentra en el otro extremo de la descarga de la aplicación, también puede detectar dicha descarga masiva y bloquearla desde allí.

Para que este esquema funcione, debe poder crear valores de token en el servidor de descarga de aplicaciones, a pedido (esto podría ser difícil de configurar con el sistema de instalación de aplicaciones en los teléfonos inteligentes existentes), y tal que la cuenta El servidor de creación puede decidir si un valor de token es genuino o no. HMAC es la herramienta criptográfica adecuada para eso.

Tenga en cuenta que este tipo de solución no es ni mucho menos perfecta. Estos son juegos y trucos para "elevar el listón" para el atacante: si diseña e instala un sistema como el que describo, entonces un atacante exitoso tendrá que automatizar la descarga de la aplicación desde muchas direcciones IP distintas, para mantenerse bajo el radar. de sus heurísticas para detectar tales cosas; luego, también automatice la ingeniería inversa para recuperar los valores de token (use las técnicas explicadas por @Lynks para eso); Luego reenvíe los valores a sus bots que crean cuentas. Todo esto todavía es teóricamente factible: después de todo, usuarios humanos pueden descargar la aplicación y crear cuentas, y no hay manera de realmente hacer la diferencia, desde el exterior, entre un usuario humano promedio, un chimpancé y un bot.

Pero si puedes hacer el ataque lo suficientemente complejo como para que el atacante considere que "no vale la pena el esfuerzo", ganas.

  

Si estuviera escribiendo un sitio web, usaría Captcha para evitar que mi base de datos se llene con cuentas falsas a través de un script.

Incluya eso en la API. Cuando un usuario quiere crear una cuenta:

1. El cliente solicita un CAPTCHA.
2. El servidor genera un CAPTCHA, lo almacena y envía una copia al cliente.
3. El cliente presenta el formulario de creación de cuenta, junto con el CAPTCHA.
4. El usuario rellena el formulario y responde a la CAPTCHA.

5. El cliente solicita que se cree la nueva cuenta y envía la respuesta CAPTCHA con esa solicitud.

   • Si la respuesta de CAPTCHA es incorrecta, el servidor elimina su copia de CAPTCHA (por lo que el cliente no puede volver a intentarlo) y responde con un error.

También puedes usar algo como HashCash para hacer más difícil que alguien realice un ataque de fuerza bruta, solo haz Asegúrese de que el HashCash se pueda generar más rápido de lo que un usuario podría completar razonablemente el formulario.

Lo que necesitas es una autenticación de aplicación similar. Es el mismo concepto que la autenticación que realiza para las llamadas a la API en sitios como Twitter, Facebook y Foursquare. No permiten que nadie solo consulte su API. En su lugar, generan una clave de API y un secreto de API para su aplicación. Si su aplicación presenta esas claves al servidor, puede utilizar sus API.

"Tener a los usuarios autenticados en lugar de autenticar las aplicaciones instaladas" es más confiable .
Generaré un nombre de usuario / pase en el momento en que descarguen la aplicación. Y pida al tema que inserte el nombre de usuario ya pasado / pase después de instalarlo. Y guárdalo para las próximas llamadas al servidor.
Por lo tanto, los usuarios deben insertar el nombre de usuario / la primera vez que instalan la aplicación.
Para deshacerme de los robots, también obtengo un captcha justo antes de generar el nombre de usuario / pase y descargar la aplicación.