Cómo ocultar las claves del cliente de la intercepción de la red o MITM

0

Para utilizar nuestra plataforma y API, un cliente requiere la integración de iOS y Android SDK en sus aplicaciones móviles. Cada uno de los clientes recibe una clave de API, como cualquier otra plataforma como Crashlytics, MixPanel, etc., para comunicarse con el servidor.

Estamos intentando ocultar las claves durante cualquier tipo de intercepción de red o MITM. Sin embargo, esto parece ser un trabajo difícil.

Hasta ahora hemos intentado seguir:
1. Almacenar las claves del cliente en el almacén de claves, llavero.
2. Cambie el encabezado, los nombres de los parámetros JSON para confundir al atacante.
3. Colocar las claves en un archivo y luego transmitirlas a través de la red.
4. El primer y último método de llamada. Estamos marcando la primera marca de tiempo de solicitud y luego comparándola con las siguientes llamadas consecutivas. Si la marca de tiempo es mayor que la primera, entonces podemos suponer que un atacante no está intentando reproducir las llamadas por abusar de la plataforma.

No podemos permitir que el atacante vea las claves por una razón, todas y cada una de las llamadas se facturan al cliente, y cualquier persona que conozca nuestra plataforma puede causar un daño tremendo a nuestros clientes con solo repetir las solicitudes a nuestro servidor.

¿Cómo garantizamos que las claves se transmitan de forma segura y no sean visibles para el atacante?

Nota: una vez que el SDK de una aplicación móvil se active, para un cliente, estamos actualizando las claves a diferentes horas del día y almacenándolas en el llavero, almacén de claves.

Gracias
Fennec

    
pregunta Fennec 07.12.2016 - 12:06
fuente

1 respuesta

4

Esto depende del tipo de ataque que esperas:

  • Si el atacante está puramente en la red intentando hacer un hombre en el ataque central, entonces proteger la conexión con TLS (es decir, HTTPS) debería ser suficiente. Se puede agregar protección adicional utilizando el certificado o fijación de clave pública .
  • Si TLS / HTTPS no es una opción, puede utilizar autenticación basada en el resumen para comprobar que el cliente posee el token. . Por supuesto, también puede combinarlo con TLS.
  • Si teme que el atacante pueda acceder a la aplicación y extraer la clave que perdió de todos modos. En este caso, solo puede intentar limitar el impacto, es decir, usar la ofuscación de código para hacer ingeniería inversa y extraer la clave con más fuerza, emplear la limitación de la tasa para limitar el abuso y cambiar la clave de acceso y la estrategia de ofuscación con la suficiente frecuencia, es decir, idealmente antes de que se exponga la clave .
respondido por el Steffen Ullrich 07.12.2016 - 12:34
fuente

Lea otras preguntas en las etiquetas