servicios web: cómo evitar accesos ilegales

Debe definir con alta precisión qué es lo que desea exactamente .

Aquí, usted desea permitir accesos de usted, personalmente. El negocio con la clave secreta significa que se otorgará acceso a quienquiera / lo que sepa la clave secreta . Incrustar la clave en la aplicación significa que la aplicación conoce la clave, no usted; y, como observas, los secretos incrustados en una aplicación ampliamente publicada no son realmente secretos.

Por lo tanto, tienes que ser claro contigo mismo. Primero, defina a quién se le debe otorgar acceso y por "a quién" me refiero a "los humanos". Cada persona en este conjunto debe "saber" un valor secreto que es utilizado por el servidor para autenticar a dicha persona. Si varios humanos usan el mismo valor secreto, entonces el manejo de este secreto se vuelve complejo, porque no puedes imponer el olvido: no puedes expulsar a un usuario del conjunto de personas que "conocen el secreto" porque él lo recordará de todas formas.

Por lo tanto, debes tener secretos específicos del usuario. Cada persona debe tener su propio valor secreto y enviarlo al servidor para que se le otorgue acceso (ya que estamos hablando de enviar secretos a través de una red, asumo que todo esto sucede bajo la égida de SSL). Luego viene la pregunta de cómo técnicamente un usuario almacenará su valor secreto. Si lo almacena en su cabeza y lo pone a disposición de la aplicación que usa al escribirlo cuando sea necesario, entonces este secreto es una contraseña . Pero otros modelos son posibles, por ejemplo. el secreto podría ser un grupo de bytes generados aleatoriamente que el usuario almacena en un archivo a lo largo de su aplicación.

No puede impedir que un usuario que tiene acceso a su servidor "comparta" ese acceso con otra persona; pero con los secretos específicos del usuario puedes al menos:

1. saber en el servidor que (supuestamente) se está conectando, y así modular el conjunto de operaciones que el servidor permitirá o no permitirá;
2. expulsa a usuarios específicos, eliminando el lado del servidor secreto, sin afectar a otros usuarios.

Lo que no puedes hacer es tener una aplicación que todos los usuarios del mundo puedan descargar e instalar y usar para acceder a tu servidor, mientras que previene de manera confiable cualquier acceso que no use la aplicación exacta que publicaste . Este sería el Santo Grial de la prevención de la piratería, y resulta tan difícil de alcanzar como su contraparte teológica.

Replanteando tu pregunta.

Tienes una aplicación móvil instalada en un teléfono de un cliente que no es de confianza.

La aplicación móvil tiene que recuperar / enviar datos a su servicio web; Sin embargo, si desea restringir el acceso a su servicio web a aplicaciones móviles, no a usuarios aleatorios (puede que esté usando un dispositivo de escritorio, publíquelo en la web).

Su solución actual es codificar una clave secreta dentro de la aplicación, que se pasa al servicio web con cada solicitud; solo se procesan las solicitudes con la clave secreta correcta.

La solución perfecta no es viable

Primero, tu objetivo no es factible contra los atacantes sofisticados. Podrán descompilar el código de bytes de tu aplicación de Android, ver qué está haciendo tu aplicación y luego hacer lo que hace tu aplicación sin conexión.

Sin embargo, es posible que pueda utilizar la funcionalidad licencia de aplicaciones de Android para hacer casi todo lo que usted quiere.

Básicamente, puede generar una ID única para su aplicación cuando se instala por primera vez. Luego, su aplicación envía una consulta al "Market License Server" de Google Play que comprueba que el usuario compró la aplicación para este dispositivo y devuelve el estado de la licencia (firmado criptográficamente con el certificado de Google). Su aplicación devuelve este estado de licencia firmado a su servidor, que lo verifica y genera una clave secreta (vinculada a la ID única) para ese dispositivo.

Ahora, si alguna aplicación usa su servicio web con demasiada frecuencia (por ejemplo, cree que está fuera de línea), puede prohibir su clave secreta única.

¿El usuario tiene que iniciar sesión en la aplicación? Si es así, puede hacer que se usen las credenciales para validar las solicitudes. Si no, el hecho de tener algún tipo de secreto compartido entre la aplicación y el servicio web es lo mejor que puedes hacer.