¿Hay una manera de iniciar sesión en el servidor mediante identificación de voz cuando la verificación pasa a nivel local?

Pregunta hecha: hace 9 meses Ultima actividad: hace 9 meses
up 0 down

Si la verificación de huella de voz pasa a nivel local en una aplicación móvil, ¿cómo dejar que el servidor de forma segura saber que el usuario se verifica? Pensé en usar una clave de API de las clases, generando tal vez una cadena aleatoria y distribución que con la aplicación. Así que cuando la voz del usuario se verifica a nivel local, que le dirá al servidor. Y debido a que la solicitud incluye la clave de API, el servidor va a confiar en la solicitud y responder con un token de acceso.

Esa solución no es muy convincente sin embargo. ¿Hay una manera de iniciar la sesión utilizando huella de voz cuando la verificación ocurre dentro de una aplicación?

1 respuesta

Quizás tu proyecto necesite tarjetas de vector libre. Nuestro sitio tiene mapas para todos los países.

Publicación patrocinada

up 0 down accepted

Servidor de la API no puede confiar en las solicitudes

Y debido a que la solicitud incluye la clave de API, el servidor va a confiar en la solicitud y responder con un token de acceso.

El servidor de la API no se puede confiar en cualquier solicitud que reciben basada sólo en una clave de API, porque son tan fáciles de extraer de una aplicación móvil con herramientas de ingeniería inversa que podemos encontrar en la comunidad de código abierto.

Con el fin de comprender mejor por qué no podemos confiar ciegamente en las peticiones que llegan al servidor API tenemos que entender 2 conceptos, quién y qué se está comunicando con el servidor de la API.

Quién y qué está accediendo al servidor API

La OMS es el usuario de la aplicación móvil que se puede autenticar, autorizar y determinar de varias maneras, como el uso de OpenID, los flujos OAuth2 o la huella de voz.

Pero antes de darse la OMS necesita una manera de identificar lo que está llamando a su servidor de principios activos y de aquí las cosas se hacen más complicado que la mayoría de los desarrolladores pueden pensar. El ¿Qué es lo que hace la solicitud al servidor API, ¿es realmente su verdadera aplicación móvil o es un bot, un script automatizado o un atacante que empuja manualmente alrededor de su servidor de la API con una herramienta como cartero?

Bueno para identificar el lo que los desarrolladores tienden a recurrir a una clave de API que por lo general dura de código en el código de su aplicación móvil y algunos van más allá y calculan que en tiempo de ejecución de la aplicación móvil, se convierte así en un secreto dinámico en oposición al enfoque anterior que es un secreto estático incorporado en el código.

INGENIERÍA INVERSA A MOBILE APP binario es FÁCIL

Pensé en usar una clave de API de las clases, generando tal vez una cadena aleatoria y distribución que con la aplicación.

La verdad es que cualquier cosa que se ejecuta en el lado del cliente puede ser ingeniería inversa fácilmente por un atacante en un dispositivo que controla. Se utilizará como marcos de introspección Frida o xPOSED para interceptar en tiempo de ejecución del código de ejecución de la aplicación móvil o va a utilizar una herramienta de proxy como MiTM Proxy para la observación de las comunicaciones entre la aplicación móvil y el servidor API. Normalmente su primer paso en la ingeniería inversa de una aplicación móvil será el uso de la Marco Mobile Security realizar ingeniería inversa del binario de ustedes aplicación móvil para extraer todos los secretos estáticos, también conocido como la clave de la API, y para identificar otros tipos de ataque.

Si la verificación de huella de voz pasa a nivel local en una aplicación móvil, ¿cómo dejar que el servidor de forma segura saber que el usuario se verifica?

Al hacerlo de esta verificación en el lado del cliente abre el vector de ataque de la utilización de XPOSED, Frida o incluso MobSF en tiempo de ejecución para la manipulación de los resultados de la verificación de voz.

Recuerde que los usuarios con el fin de obtener conexión Wi-Fi pueden ser engañados para instalar aplicaciones de malware o certificados SSL personalizados, que permitirá a un atacante introspección, interceptar y modificar las decisiones que se toman en el dispositivo y la manipulación de los datos que se envían a través del cable al servidor API, por otras palabras que son capaces de pasar por alto los resultados de reconocimiento de registro de voz.

Marco Mobile Security

Marco Mobile Security es una automatizado, todo en una sola aplicación móvil (Android Windows/IOS /) marco de pruebas de lápiz capaz de realizar el análisis estático, análisis dinámico, análisis de malware y las pruebas API web.

Frida

Inyectar sus propios scripts en los procesos de caja negra. Enganche cualquier función, espiar a las API de cifrado o trazar código de la aplicación privada, no hay código fuente necesario. Editar, guardar golpeado, y al instante ver los resultados. Todo ello sin pasos de compilación o reinicia el programa.

xPOSED

Xposed es un marco para módulos que pueden cambiar el comportamiento del sistema y las aplicaciones sin tocar ningún APK. Eso es muy bueno porque significa que los módulos pueden trabajar para diferentes versiones e incluso ROM sin ningún cambio (siempre y cuando el código original no fue cambiado demasiado). También es fácil de deshacer.

MiTM Proxy

Un TLS con capacidad de interceptación de proxy HTTP interactivo para pruebas de penetración y desarrolladores de software.

Una posible solución

Así que cualquier cosa que se ejecuta en el lado del cliente y que utiliza un secreto para acceder a un servidor de la API puede ser objeto de abuso, y se puede aprender más en estas series de artículos sobre técnicas móvil API de seguridad. En este artículo le enseñará cómo claves de la API, tokens de acceso de usuario, HMAC y TLS Clavado se pueden utilizar para proteger a la API y cómo pueden ser anuladas.

Esa solución no es muy convincente sin embargo.

Para resolver el problema de lo que es el acceso a su aplicación móvil es necesario utilizar una o todas las soluciones mencionadas en la serie de artículos sobre técnicas API de seguridad móvil que he mencionado anteriormente y aceptado que sólo pueden hacer que el acceso no autorizado al servidor API más difícil de de derivación, pero no imposible. Esto significa que mientras más difícil aún es posible pasar por alto el resultado de reconocimiento de huella de voz.

¿Hay una manera de iniciar la sesión utilizando huella de voz cuando la verificación ocurre dentro de una aplicación?

Como ya he mencionado anteriormente las decisiones tomadas en el dispositivo pueden ser manipulados en tiempo de ejecución, teniendo así la comunicación móvil con el servidor de la API para iniciar la sesión del usuario en función de esa decisión hay que tener en cuenta que puede ser manipulado para evitar el reconocimiento de huella de voz.

Para que quede claro el bypass puede suceder en el propio dispositivo mediante la manipulación en tiempo de ejecución el resultado devuelto de la verificación de huella de voz para estar siempre true o mediante la interceptación de la comunicación con el servidor de la API y cambiar el resultado del reconocimiento de huella de voz para estar siempre true.

A partir de sus comentarios en la pregunta:

Tiene que hacerse en el dispositivo. Evitamos el envío de datos de voz al servidor para la privacidad del usuario. Si alguien puede robar su contraseña sólo puede cambiarlo. Pero no se puede hacer exactamente lo mismo con su voz.

Ahora que ya sabe que durante la ejecución del reconocimiento de huella de voz puede ser manipulado, haciendo que el malware también puede extraer los resultados y enviarlos de vuelta al atacante, comprometiendo así es la huella digital de voz, que como bien dice correctamente el usuario no puede cambiar.

Todavía no está convencido, por favor, darle una lectura La biometría podría reemplazar nuestras contraseñas - y de hecho hay un gran problema con eso donde se puede leer, por ejemplo:

Pero una violación biometría tiene consecuencias aún más graves. Si alguien se adueña de sus huellas digitales, que posiblemente puede robar su identidad.

Para ayudar con la comunicación de los resultados de reconocimiento de registro de voz al servidor de la API, una solución de certificación de aplicaciones para móviles puede ser empleado. Se permitirá que el servidor de la API saber está recibiendo solamente las peticiones de una verdadera aplicación móvil que no se ejecuta en un dispositivo dañado raíz o la cárcel, que se adjunta a la introspección marcos o en modo de depuración.

Aplicación Móvil Certificación

Use una solución de certificación de aplicaciones para móviles para habilitar el servidor API para saber lo que está enviando las solicitudes, lo que le permitió responder sólo a las peticiones de una verdadera aplicación móvil.

El papel de un servicio de certificación de aplicaciones para móviles es garantizar en tiempo de ejecución que su aplicación móvil no se ha alterado o no se está ejecutando en un dispositivo de raíces mediante la ejecución de un SDK en el fondo que se comunicará con un servicio en ejecución en la nube para dar fe de la integridad de la aplicación móvil y el dispositivo se está ejecutando.

En certificación exitosa de la integridad aplicación móvil de un corto tiempo vivido token de JWT es emitido y firmado con un secreto que sólo el servidor de la API y el servicio de certificación de aplicaciones para móviles en la nube son conscientes. En el caso de un fallo en la certificación de aplicaciones móviles el token JWT está firmado con un secreto que el servidor de la API no sabe.

Ahora el mosto App enviado con cada llamada de API token JWT en las cabeceras de la petición. Esto permitirá que el servidor de la API sólo responde a la solicitud cuando se puede verificar la firma y el tiempo de expiración en el token JWT y rechazarlos cuando falla la verificación.

Una vez que el secreto utilizado por el servicio de certificación de aplicaciones para móviles no se conoce por la aplicación móvil, no es posible realizar ingeniería inversa que en tiempo de ejecución, incluso cuando se altera la aplicación, que se ejecuta en un dispositivo con raíces o comunicarse a través de una conexión que está siendo el blanco de un hombre en el centro Atacar.

el servidor confiará en la solicitud y responder con un token de acceso.

Así que con esta solución en su lugar el servidor API puede confiar en la solicitud de aplicación móvil diciendo que el reconocimiento de huella de voz es válida, por lo que puede emitir un token de autenticación de usuario para ser utilizado en las comunicaciones posteriores con el servidor de la API.

El servicio de certificación de aplicaciones para móviles ya existe como una solución SAAS en Approov (yo trabajo aquí) que proporciona SDK para varias plataformas, incluyendo iOS, Android, Reaccionar nativo y otros. La integración también necesitará una pequeña comprobación en el código del servidor API para verificar el token JWT emitido por el servicio en la nube. Esta comprobación es necesario que el servidor API para poder decidir lo que solicita a servir y lo que las negar.