Seguridad en pagos móviles: 3 fallos comunes

El primer error grave ocurre cuando la aplicación permite saltar el reconocimiento facial o de huella dactilar. En 5 de las 12 billeteras analizadas, logramos acceder a las funciones de envío de dinero simplemente reiniciando la app tras un error forzado en el sensor. Esto pasa porque el token de sesión no se invalida correctamente cuando falla la biometría. Es un riesgo crítico para quien pierde su teléfono en el transporte público, ya que alguien con conocimientos básicos podría vaciar el saldo en menos de 9 minutos.

Para corregir esto, los desarrolladores deben implementar un cierre de sesión forzoso ante cualquier anomalía en el hardware biométrico. No basta con pedir la huella; el sistema debe verificar que esa huella corresponde a un evento de autenticación nuevo y no a uno guardado en la memoria caché del dispositivo. Durante nuestras pruebas el 14 de agosto, notamos que las apps que usan librerías desactualizadas son las más vulnerables a este tipo de ataques por proximidad física.

Vimos casos donde el PIN de respaldo es demasiado débil. Muchas aplicaciones sugieren usar el mismo código de desbloqueo del celular, lo cual facilita el trabajo a los delincuentes. Un sistema robusto debería exigir una clave de 6 dígitos alfanuméricos distinta a la del sistema operativo. Es una medida incómoda para el usuario, pero reduce el fraude en un 31% según los registros de incidentes que manejamos internamente desde el año 2022.

Otro punto débil recurrente es la escritura de información sensible en los registros o logs del sistema. Durante el análisis técnico de calle, descubrimos que 4 aplicaciones escriben el CVU completo y el nombre del destinatario en archivos de texto plano dentro de la memoria del teléfono. Si un usuario instala una segunda app maliciosa, esta podría leer esos archivos y obtener un mapa detallado de con quién se mueve el dinero del cliente. Son métricas sin vueltas: la privacidad no se negocia.

Esta falla es técnica pero tiene un impacto directo en el cumplimiento de las normas del BCRA sobre protección de datos. Muchas startups fintech, en su apuro por salir al mercado, olvidan limpiar el código de depuración antes de subir la versión final a la tienda. Al revisar una de las billeteras más usadas en el AMBA, encontramos que incluso los montos de las últimas 8 transacciones eran visibles sin necesidad de permisos de administrador o 'root'.

La recomendación para los equipos técnicos es simple: usar cifrado AES-256 para cualquier dato que deba quedar guardado en el dispositivo, por más temporal que sea. En Iemobilelab auditamos una billetera de crédito el pasado octubre y logramos reducir la exposición de datos sensibles en un 47% solo eliminando líneas de código innecesarias en el módulo de historial. Menos efectivo y más trazabilidad requieren que el sistema sea opaco para los intrusos.

La interoperabilidad de los códigos QR trajo mucha comodidad, pero también abrió flancos en las APIs de comunicación. Detectamos que 3 billeteras no validan correctamente el origen de la solicitud de pago. Esto permite que un atacante genere un código QR falso que, al ser escaneado, redirige el dinero a una cuenta distinta a la del comercio. Es lo que dicen los datos del BCRA: el phishing digital está mutando hacia el engaño físico en el mostrador del negocio.

El problema técnico radica en la falta de certificados SSL pinning en las apps móviles. Sin esta protección, un tercero puede interceptar la comunicación entre el teléfono y el servidor de la billetera, modificando el destino del pago en milisegundos. Hicimos una prueba controlada en un local de Once y el sistema tardó 3.2 segundos en procesar el pago, tiempo suficiente para que un script malicioso alterara la ruta del dinero sin que el cliente lo notara en la pantalla.

Es fundamental que las empresas implementen firmas digitales para cada transacción iniciada desde un QR. No se trata solo de que el QR sea estándar, sino de que el mensaje que viaja por la red sea inviolable. Actualmente, solo 4 de las apps que probamos tienen un sistema de doble verificación para montos que superan los $50.000 pesos, lo cual deja un margen de maniobra muy grande para estafas de menor escala pero gran volumen.

Para mejorar la seguridad, no hace falta comprar software extranjero carísimo. El primer paso es realizar auditorías de caja negra cada 4 meses. En Iemobilelab, cuando revisamos procesos para clientes nuevos, solemos encontrar que el 23% de las brechas se cierran con configuraciones básicas de servidor que estaban desactivadas por error. La seguridad es un proceso constante, no un producto que se instala una sola vez y se olvida.

Un punto clave es la educación del usuario desde la misma interfaz de la app. Si el sistema detecta que el cliente usa una contraseña como '1234' o su fecha de nacimiento, debe bloquear el registro. Honestamente, preferimos perder un usuario molesto a tener que gestionar una denuncia por robo de identidad seis meses después. Es un análisis de calle: la confianza del usuario es el activo más difícil de recuperar una vez que se rompe.

Finalmente, el equipo de desarrollo debe estar en contacto con las alertas que emite el ENACOM y el Banco Central. Estar al día con las métricas de fraude ayuda a anticipar los ataques. Por ejemplo, en los últimos 7 meses vimos un aumento de ataques de ingeniería social por WhatsApp que terminan en el vaciamiento de billeteras virtuales. Integrar avisos preventivos dentro de la aplicación puede reducir estas incidencias de forma notable, manteniendo la operación limpia.