Autenticación sin registro

1

Sea S un servidor y C un cliente móvil (aplicación iOS / Android). Supongamos que la comunicación entre S y C está cifrada con SSL (o cualquier otro protocolo estándar).

El sistema es una aplicación de votación, es decir, S envía algunos artículos a C, y C puede subir / votar y enviar su voto a S. Lo que pasa es que no quiero que C se registre / se inscriba para esto. pero tampoco quiero que vote más de una vez.

Uno podría pensar en algo como: cuando la aplicación se inicia por primera vez en C, S asigna un UUID a C y C lo almacena. Luego, cada vez que C quiere votar, envía el voto y su UUID y S comprueban si ese UUID ya ha votado.

Pero en ese caso, ¿qué impide a alguien crear un programa que siempre está pidiendo S para UUID y luego votar el mismo artículo tantas veces como se desee?

Todo lo que me viene a la mente es que S y C comparten una contraseña que está codificada y el sistema funcionará de esta manera:

  1. C pide a S por un UUID,
  2. S envía C a UUID,
  3. C almacena el UUID,
  4. Cuando C quiere votar, envía a S: {vote, crypt (UUID, sharedPwd)}

Por supuesto, en el momento en que alguien supiera esa contraseña (y tal vez sea fácil de obtener ya que en realidad está en el código del cliente ...) el sistema estaría en peligro ...

Entonces ... ¿Cómo puede mi servidor saber que las solicitudes provienen de la aplicación? O puede ser un enfoque diferente: ¿cómo realizan la autenticación algunas aplicaciones sin registro?

    
pregunta Carlos Navarro Astiasarán 09.10.2015 - 21:19
fuente

2 respuestas

2

Me temo que lo que estás pidiendo es imposible. Si desea que los nuevos usuarios puedan usar su aplicación, alguien encontrará la manera de hacerse pasar por un nuevo usuario cada vez y falsificar los votos de esa manera. La única solución es tener una parte confiable que certifique las identidades de todos, y eso no sucederá hasta que cada tarjeta de identificación sea una tarjeta inteligente estándar con un certificado de cliente. A partir de ahora, en teoría, podría confiar en una CA, pero eso sería una gran barrera de entrada y nadie utilizará su aplicación.

Aunque podrías hacerlo más difícil. Usar el anclaje de certificados en el lado de la aplicación por lo que el análisis del tráfico es más difícil, y ofuscar el binario ralentizará a los posibles atacantes que deseen replicar el comportamiento de su aplicación, pero incluso así, el atacante solo tiene que desinstalar / reinstalar su aplicación y Aparecerá como una nueva instalación en la mayoría de los dispositivos.

Si es posible en sus dispositivos de destino, debe confiar en un identificador proporcionado por el sistema operativo host o la tienda de aplicaciones, que es más difícil de replicar (o incluso imposible si su servidor se está comunicando con los servidores de la tienda de aplicaciones para validar la instalación de su aplicación) que replicar una aplicación, ya que el sistema operativo tiene formas de acceder al hardware y obtener las ID de cada dispositivo (la dirección MAC, IMEI, etc.), mientras que su aplicación no puede acceder a ellas directamente.

También puede vincular las ID de dispositivo únicas a algo más difícil de obtener, como los números de teléfono, solicitando una confirmación por SMS cada vez que se instala la aplicación. No detendrá el fraude (y, como tal, no es adecuado para una votación "formal" como las elecciones o cualquier cosa en la que esté involucrado el dinero), pero ayudará. Es como el DRM, no necesita ser a prueba de balas, solo tiene que ser más fuerte que las aplicaciones de la competencia y los atacantes perseguirán a la fruta que cuelga, dejando su solución en paz.

Finalmente, si lo único que quieres defender es el voto en masa de los robots, pero no te preocupes por el voto ocasional, basta con agregar un captcha. Por supuesto, esto solo funcionará mientras el dinero no esté involucrado, de lo contrario, podría ser rentable para los atacantes contratar humanos para escribir los captchas y cometer fraude de esa manera.

    
respondido por el André Borie 10.10.2015 - 02:50
fuente
0

Puede emitir una cookie cuando S envía el artículo a C, y C puede enviar la cookie al servidor junto con el UUID. Si la cookie es válida (lo que significa que la sesión es válida), deje que se realice la votación. Si alguien intenta enviar una solicitud utilizando el uuid de alguien, el atacante no tiene una cookie en la solicitud, por lo que sería un voto no válido, y puede dejarlo de forma segura.

Asegúrese de generar una cookie con la caducidad adecuada para que pueda aumentar la validez del voto del usuario.

    
respondido por el Saehun Sean Oh 10.10.2015 - 02:09
fuente

Lea otras preguntas en las etiquetas