Almacenar tokens API de forma segura en Android para identificar al desarrollador

Navega tus respuestas
1

Estamos creando una biblioteca de Android para nuestras API Rest para que los desarrolladores de aplicaciones puedan acceder con un token único. Ya que es un servicio pagado y es un modelo de precios por solicitud o por instalación, ¿cómo podemos proteger a nuestros desarrolladores pagados del abuso? Por ejemplo, si alguien, pero el desarrollador recibe el token de:

  • Descompilar la aplicación
  • Ejecutando un ataque de Man in the Middle (aunque sea HTTPS) y obtiene el token

Lo que estamos haciendo en este momento es lograr que cada desarrollador aloje su propio punto final (URL del servidor) que está codificado en la biblioteca cuando se los entregamos. Este punto final es un proxy inverso de nuestra API, y de esta manera, podemos limitar las solicitudes por IP y también diferenciar el tráfico. Sin embargo, realmente no resuelve la parte de abuso del problema, y también es demasiado doloroso si queremos escalar a un millón de aplicaciones.

¿Qué podemos hacer?

    
pregunta kouton 25.11.2015 - 09:20
fuente

3 respuestas

1

El desarrollador (su cliente) puede usar cualquier técnica de ofuscación para proteger la clave, pero no hay una garantía del 100% de ingeniería inversa.

Uno de los vectores de ataque sería un MITM. Si su aplicación está instalada en un dispositivo rooteado, todas las protecciones de https pueden ignorarse.

El desarrollador de la aplicación tiene a su disposición medios de seguridad mucho más sólidos. Por ejemplo, ella puede si la aplicación se instaló legítimamente (se puede pagar) y así sucesivamente. Google ofrece servicio de licencias de aplicaciones para tales casos. Incluso podría intentar excluir los dispositivos rooteados (las medidas y contramedidas para revelar el enraizamiento oculto son una carrera de armamentos eterna).

Para proteger mejor su token, el desarrollador de la aplicación solo puede entregarla a la aplicación después de que haya verificado todo esto.

Pero para ayudar aún más, puedes usar una verificación doble de tus llamadas a la API. Asegúrese de que dicha solicitud vaya acompañada de una llamada del servidor registrado del desarrollador (puede solicitar dicha verificación una vez por sesión o una vez por dispositivo, o usar alguna otra política que usted acepte).

    
respondido por el Alex Cohn 28.11.2015 - 17:19
fuente
2

¿Ha considerado un proceso de dos pasos, donde

  1. Un desarrollador se autentica en su servidor, que responderá con el token
  2. El token se usa para todas las sesiones subsiguientes y caduca después de un tiempo determinado de su elección

Todo lo anterior se hace en la aplicación. El token de sesión se almacena normalmente, pero dada su corta vida útil, es una información menos importante.

Esto te permite:

  • Revocar el acceso de alguien, por ejemplo. si no han pagado por el servicio
  • realizar un seguimiento del uso
  • Permitir que un desarrollador "cierre sesión en otras sesiones" de una manera similar a lo que Gmail hace
  • Permite que un desarrollador tenga más de un token
respondido por el lorenzog 25.11.2015 - 09:55
fuente
0

Personalmente, crearía un modo de desarrollador (como hago en todos mis trabajos recientes) Que cuando está marcado como en activaría tirar cheques adicionales.

Crearía tokens manualmente para que los desarrolladores los usaran, pero si estuvieran marcados como dev en la base de datos y el modo dev estuviera activado, se requeriría una contraseña para usar el token y crear dos sesiones de inicio de sesión ...

o simplemente recorta la capa adicional y usa el modo de desarrollador ...

¿otra posibilidad sería bloquear tokens a direcciones IP? Si hay un ataque MitM bueno para ellos ... no hará nada. podría dar a todos el token de desarrollador, pero solo los desarrolladores podrían usarlo

    
respondido por el TheHidden 25.11.2015 - 10:27
fuente

Lea otras preguntas en las etiquetas

¿Windows 10 [Protección de contraseña en la activación] está configurado como 'Requerido' relevante cuando la máquina está en reposo? ¿Qué son las cookies y el caché?