¿Cómo las aplicaciones populares autentican las solicitudes de los usuarios desde su aplicación móvil a su servidor?


118

Digamos que tengo una aplicación de Android que se conecta a una API .Net para recibir / configurar datos. La confusión que tengo es sobre cómo registrar / iniciar sesión el usuario por primera vez y autenticarlo cada vez que realizan una solicitud a la API.

  • Si solo uso la autenticación basada en nombre de usuario / contraseña, ¿no serán lo suficientemente seguros?
  • ¿Y no puedo guardar ese nombre de usuario / contraseña en el dispositivo, por supuesto, por razones de seguridad?
  • ¿Debería emitir un GUID para cada usuario en el registro, guardarlo en su dispositivo y recuperarlo cada vez que se realiza una solicitud de API?

Qué otros patrones están disponibles y cuáles son los más eficientes y seguros, solo necesito un flujo de proceso para ello. ¿Alguien puede decirme qué método usan las aplicaciones de Android famosas como Facebook, FourSquare o Twitter para autenticar cada solicitud proveniente de su aplicación móvil en su servidor?

Lo siento de antemano si esa no es información pública.

Respuestas:


48

Me imagino que usan un sistema de seguridad basado en "token", por lo que la contraseña nunca se almacena en ningún lugar, solo se usa la primera vez para autenticarse. Entonces, la aplicación publica inicialmente el nombre de usuario / contraseña (a través de ssl) y el servidor devuelve un token que almacena la aplicación. Para los intentos de sincronización posteriores, el token se envía primero, el servidor verifica que sea válido y luego permite que se publiquen otros datos.

El token debe tener una caducidad para que el servidor pueda volver a solicitar un intento de autenticación.

Si se conecta al adaptador de sincronización desde el marco de Android, eso le dará la capacidad de sincronizar y autenticar todo bajo el capó.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

Si revisa las cuentas en Configuración en su dispositivo, verá lo que quiero decir.


19

Básicamente, estos famosos utilizan el protocolo OAuth (1) / framework (2). Aunque tiene que ser un estándar, cada uno de estos tenía diferentes implementaciones de este protocolo / marco. Por tanto, tenemos que tener mucho cuidado con la integración.

Ejemplo: Dropbox todavía usa OAuth 1 y recientemente se le ocurrió la compatibilidad con OAuth 2.

Volver a la respuesta, como, dijo peterpan, es una forma de autenticación basada en tokens que es única y está fuera de la ecuación. Estos tokens están vencidos o ese poder se le da al desarrollador en algunos casos.

Lo interesante detrás de esto es que, el alcance del acceso a los recursos se puede definir en lugar de permitir que la aplicación cliente mantenga los nombres de usuario, contraseñas que son peligrosas.

Esta es la ilustración básica de cómo funciona.

ingrese la descripción de la imagen aquí

Actualizaré la respuesta después de obtener más detalles sobre esto, ya que estoy trabajando en esta área estos días :)


13

Si solo uso la autenticación basada en nombre de usuario / contraseña, ¿no serán lo suficientemente seguros?

No, porque solo identifica el QUIÉN está accediendo al servidor API, pero no el QUÉ está accediendo a él.

La diferencia entre QUIÉN y QUÉ es acceder al servidor API

Para comprender mejor las diferencias entre la OMS y la QUÉ están accediendo a un servidor API, usemos esta imagen:

Hombre en el ataque medio

El canal de comunicación previsto representa la aplicación móvil utilizada como usted esperaba, por un usuario legítimo sin intenciones maliciosas, utilizando una versión sin manipular de la aplicación móvil y comunicándose directamente con el servidor API sin ser atacado por un intermediario.

El canal real puede representar varios escenarios diferentes, como un usuario legítimo con intenciones maliciosas que puede estar usando una versión reempaquetada de la aplicación móvil, un pirata informático que usa la versión genuina de la aplicación móvil, mientras que un hombre en el medio la ataca, para entender cómo la comunicación entre la aplicación móvil y el servidor de API se realiza para poder automatizar los ataques contra su API. Son posibles muchos otros escenarios, pero no enumeraremos cada uno aquí.

Espero que a estas alturas ya tenga una idea de por qué el QUIÉN y el QUÉ no son lo mismo, pero si no, se aclarará en un momento.

La OMS es el usuario de la aplicación móvil que podemos autenticar, autorizar e identificar de varias formas, como mediante OpenID Connect u OAUTH2.

OAUTH

Generalmente, OAuth proporciona a los clientes un "acceso delegado seguro" a los recursos del servidor en nombre del propietario del recurso. Especifica un proceso para que los propietarios de recursos autoricen el acceso de terceros a los recursos de su servidor sin compartir sus credenciales. Diseñado específicamente para trabajar con el Protocolo de transferencia de hipertexto (HTTP), OAuth esencialmente permite que un servidor de autorización emita tokens de acceso a clientes de terceros, con la aprobación del propietario del recurso. Luego, el tercero usa el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos.

Conexión OpenID

OpenID Connect 1.0 es una capa de identidad simple sobre el protocolo OAuth 2.0. Permite a los Clientes verificar la identidad del Usuario Final basándose en la autenticación realizada por un Servidor de Autorización, así como obtener información de perfil básica sobre el Usuario Final de una manera interoperable y similar a REST.

Si bien la autenticación de usuario puede permitir que el servidor de API sepa QUIÉN está usando la API, no puede garantizar que las solicitudes se hayan originado en LO que espera, la versión original de la aplicación móvil.

Ahora necesitamos una forma de identificar QUÉ está llamando al servidor API, y aquí las cosas se vuelven más complicadas de lo que la mayoría de los desarrolladores pueden pensar. El QUÉ es lo que hace la solicitud al servidor API. ¿Es realmente una instancia genuina de la aplicación móvil, o es un bot, un script automatizado o un atacante que hurga manualmente en el servidor API, utilizando una herramienta como Postman?

Para su sorpresa, puede terminar descubriendo que puede ser uno de los usuarios legítimos que usa una versión reempaquetada de la aplicación móvil o un script automatizado que está tratando de gamificar y aprovechar el servicio proporcionado por la aplicación.

Bueno, para identificar el QUÉ , los desarrolladores tienden a recurrir a una clave de API que generalmente codifican en el código de su aplicación móvil. Algunos desarrolladores hacen un esfuerzo adicional y calculan la clave en tiempo de ejecución en la aplicación móvil, por lo que se convierte en un secreto en tiempo de ejecución a diferencia del enfoque anterior cuando se incrusta un secreto estático en el código.

El artículo anterior se extrajo de un artículo que escribí, titulado ¿POR QUÉ SU APLICACIÓN MÓVIL NECESITA UNA CLAVE API? , y que puede leer en su totalidad aquí , ese es el primer artículo de una serie de artículos sobre claves API.

Almacenamiento de datos confidenciales en el dispositivo cliente

¿Y no puedo guardar ese nombre de usuario / contraseña en el dispositivo, por supuesto, por razones de seguridad? ¿Debería emitir un GUID para cada usuario en el registro, guardarlo en su dispositivo y recuperarlo cada vez que se realiza una solicitud de API?

Todo lo que guarde en el dispositivo, incluso si está cifrado, se puede realizar ingeniería inversa durante el tiempo de ejecución con herramientas como Frida o Xposed.

Frida

Inyecte sus propios scripts en procesos de caja negra. Enganche cualquier función, espíe las API de cifrado o rastree el código de la aplicación privada, sin necesidad de código fuente. Edite, presione guardar y vea los resultados al instante. Todo sin pasos de compilación ni reinicios del programa.

xPosed

Xposed es un marco para módulos que puede cambiar el comportamiento del sistema y las aplicaciones sin tocar ningún APK. Eso es genial porque significa que los módulos pueden funcionar para diferentes versiones e incluso ROM sin ningún cambio (siempre que el código original

En un dispositivo que controla el atacante, también puede usar un proxy para realizar un Ataque de hombre en el medio para extraer cualquier secreto que pueda usar para identificar el QUÉ o el QUIÉN, como muestro en el artículo Robar esa clave API con un hombre en el ataque. :

Si bien podemos utilizar técnicas avanzadas, como JNI / NDK, para ocultar la clave API en el código de la aplicación móvil, no impedirá que alguien realice un ataque MitM para robar la clave API. De hecho, un ataque MitM es fácil hasta el punto de que incluso los no desarrolladores pueden lograrlo.

Entonces, ¿ahora qué ... ¿Estoy condenado al punto en que no puedo proteger mi servidor API de ser abusado? No hay silencio así que ... ¡¡¡la esperanza todavía existe !!!

Soluciones posibles

¿Alguien puede decirme qué método usan las aplicaciones de Android famosas como Facebook, FourSquare o Twitter para autenticar cada solicitud proveniente de su aplicación móvil en su servidor?

Lo siento, pero no tengo suficiente conocimiento sobre estas aplicaciones para poder dilucidarlo, pero puedo señalarle algunos otros enfoques.

Qué otros patrones están disponibles y cuáles son los más eficientes y seguros, solo necesito un flujo de proceso para ello.

Entonces, cualquier cosa que se ejecute en el lado del cliente y necesite algún secreto para acceder a una API se puede abusar de diferentes maneras y puede obtener más información en esta serie de artículos sobre Técnicas de seguridad de API móviles. Estos artículos le enseñarán cómo las claves de API, los tokens de acceso de usuario, HMAC y TLS Pinning se pueden utilizar para proteger la API y cómo se pueden omitir.

Para resolver el problema de QUÉ es acceder a su aplicación móvil, debe utilizar una o todas las soluciones mencionadas en la serie de artículos sobre Técnicas de seguridad de API móviles que mencioné anteriormente y acepté que solo pueden dificultar el acceso no autorizado a su servidor de API. bypass pero no imposible.

Se puede emplear una mejor solución mediante el uso de una solución de atestación de aplicaciones móviles que permitirá que el servidor API sepa que solo recibe solicitudes de una aplicación móvil genuina.

Certificación de aplicación móvil

El uso de una solución de atestación de aplicaciones móviles permitirá que el servidor de API sepa QUÉ está enviando las solicitudes, lo que permitirá responder solo a las solicitudes de una aplicación móvil genuina y rechazar todas las demás solicitudes de fuentes inseguras.

El papel de una solución de atestación de aplicaciones móviles es garantizar en tiempo de ejecución que su aplicación móvil no fue manipulada, no se está ejecutando en un dispositivo rooteado, no está instrumentada por un marco como xPosed o Frida, no está siendo atacada por MitM, y esto se logra ejecutando un SDK en segundo plano. El servicio que se ejecuta en la nube desafiará a la aplicación y, según las respuestas, atestiguará la integridad de la aplicación móvil y el dispositivo en el que se está ejecutando, por lo que el SDK nunca será responsable de ninguna decisión.

Tras la certificación exitosa de la integridad de la aplicación móvil, se emite un token JWT de corta duración y se firma con un secreto que solo el servidor API y el servicio de certificación de la aplicación móvil en la nube conocen. En caso de falla en la certificación de la aplicación móvil, el token JWT se firma con un secreto que el servidor API no conoce.

Ahora, la aplicación debe enviar con cada llamada a la API el token JWT en los encabezados de la solicitud. Esto permitirá que el servidor de API solo atienda solicitudes cuando pueda verificar la firma y el tiempo de vencimiento en el token JWT y rechazarlas cuando falle la verificación.

Una vez que la aplicación móvil no conoce el secreto utilizado por el servicio de certificación de la aplicación móvil, no es posible realizar ingeniería inversa en el tiempo de ejecución, incluso cuando la aplicación está alterada, ejecutándose en un dispositivo rooteado o comunicándose a través de una conexión que está siendo la objetivo de un ataque de Hombre en el Medio.

El servicio de atestación de aplicaciones móviles ya existe como una solución SAAS en Approov (trabajo aquí) que proporciona SDK para varias plataformas, incluidas iOS, Android, React Native y otras. La integración también necesitará una pequeña verificación en el código del servidor API para verificar el token JWT emitido por el servicio en la nube. Esta verificación es necesaria para que el servidor API pueda decidir qué solicitudes atender y cuáles rechazar.

Conclusión

Al final, la solución a utilizar para proteger su servidor API debe elegirse de acuerdo con el valor de lo que está tratando de proteger y los requisitos legales para ese tipo de datos, como las regulaciones GDPR en Europa.

¿QUIERES HACER UNA MILLA EXTRA?

Proyecto de seguridad móvil OWASP: los 10 riesgos principales

El Proyecto de seguridad móvil de OWASP es un recurso centralizado destinado a brindar a los desarrolladores y equipos de seguridad los recursos que necesitan para crear y mantener aplicaciones móviles seguras. A través del proyecto, nuestro objetivo es clasificar los riesgos de seguridad móvil y proporcionar controles de desarrollo para reducir su impacto o probabilidad de explotación.



3

Soy un novato pero intentaré dar una solución lógica para la pregunta dada.

Habrá dos opciones, [1] Para cada URI, se realizará la autenticación http donde se verificarán las credenciales ingresadas por el usuario y el usuario deberá acceder a los recursos.

[2] Otro enfoque podría ser, un usuario debe autenticarse y en cada autenticación se generará un token único. Usando el token generado, el usuario deberá acceder a los recursos.

Aunque no estoy seguro de qué enfoque podría ser el más adecuado para aplicaciones móviles.


3

El ejemplo de autenticación es un buen punto de partida. Android almacena las credenciales en el Administrador de cuentas, puede ver las cuentas en la configuración de Android. Esto almacenará automáticamente los tokens, solicitará al usuario las credenciales si están caducadas o faltan, actualizará los tokens, etc. Encuentro que la parte http de este ejemplo falta o es antigua. La extensión de AccountAuthenticatorActivity de Android es una gran ayuda para analizar datos serializados en el diseño y volver a Internet.


-7

El nombre de usuario y las contraseñas pueden ser seguros cuando se colocan en SharedPreferences. Usar https para conectarse a un servidor también debería ser lo suficientemente bueno.


Puede utilizar SharedPreferences, pero sus datos no están cifrados de forma predeterminada. Si está preocupado por eso, vea, por ejemplo, esta discusión sobre SO: stackoverflow.com/questions/785973/…
Michael Helwig

3
SharedPreferences no es un lugar seguro para almacenar credenciales. Cualquier dispositivo rooteado (lo cual no es difícil de hacer) expondrá esas credenciales. En su lugar, utilice la API de cuenta integrada.
Brill Pappin

Las SharedPreferences también se pueden descargar desde dispositivos no rooteados, lo que, si no me equivoco, es posible a través del mecanismo de respaldo del sistema Android. Existen diferentes herramientas para obtener archivos legibles de un archivo de respaldo de Android.
Darthmail

@BrillPappin Pregunta sobre su comentario. Las credenciales que se almacenan son el correo electrónico y la contraseña del usuario, además de un token para enviar que representa la autenticación actual con ese correo electrónico. Si el usuario elige exponer sus propias credenciales a sí mismo, a través del enraizamiento, ¿cómo es eso un riesgo?
ToolmakerSteve

El riesgo es doble. 1) se accederá a cualquier dato sensible de fácil acceso que deba asumir. Puede que a usted realmente no le importe, pero a otra persona sí. 2) cualquier almacenamiento de una frase de contraseña es inseguro.
Brill Pappin
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.