Seguridad para apps de banca móvil

El perfil de ataque

Contra una app de banca no se lanza un ataque genérico. Lo habitual es una combinación de credenciales filtradas de otros servicios, automatización distribuida entre proxies residenciales para evitar el bloqueo por IP, y clientes que imitan a la app real leyendo su tráfico o recompilando el binario.

El objetivo intermedio casi nunca es transferir dinero de inmediato: primero se valida qué credenciales funcionan, y esa lista depurada tiene valor por sí sola.

Lo que pide el marco regulatorio europeo

La PSD2 y sus normas técnicas de regulación exigen autenticación reforzada de cliente y elementos que vinculen la operación con el dispositivo, además de la trazabilidad de los accesos.

Un certificado único por dispositivo encaja de forma natural en ese requisito de vinculación, porque convierte al dispositivo en un elemento verificable criptográficamente y no en un identificador declarado por el propio cliente. La conformidad concreta depende de tu implementación y de tu supervisor: esto es una pieza técnica, no un dictamen de cumplimiento.

Dónde encaja en una defensa por capas

mTLS por dispositivo no sustituye a tu motor antifraude, ni a tu 2FA, ni a la monitorización de operaciones. Se coloca antes que todos ellos y les quita trabajo: filtra en el handshake el tráfico que ni siquiera procede de tu app.

• Antes del login: solo llegan clientes que presentan un certificado emitido para una instalación registrada.
• Durante la sesión: el certificado sigue vinculando cada petición a ese dispositivo concreto.
• Tras un incidente: revocar el certificado corta el acceso de ese dispositivo sin afectar al resto de usuarios.

Qué no resuelve

Conviene decirlo con claridad. Un certificado por dispositivo no protege frente a la ingeniería social sobre el usuario, ni frente a un troyano bancario que opere dentro del dispositivo legítimo, ni frente a credenciales robadas usadas desde la app auténtica de la propia víctima. Para eso están las otras capas.