Mobile banking app security

Device binding ties a customer’s banking session to a specific handset. A credential registered on one device cannot be lifted and replayed from another, so stolen session material is worth much less.

Done properly, the binding key is generated inside the device’s secure hardware and is non-exportable, so the binding cannot be cloned even on a compromised device. Done poorly — a device identifier stored in application preferences — it is trivially copied and provides assurance the bank does not actually have.

The customer-facing decision is what happens on a new device. Requiring a full re-verification is more secure and more friction; the usual compromise is to allow re-binding through the same identity proofing used for other high-risk changes, and to notify the previous device when it happens.

Attestation answers a question the app cannot answer about itself: is this a genuine, unmodified build of the bank’s app, running on a device in a known-good state?

Both mobile platforms provide attestation services that produce a signed statement from the operating system or the platform vendor, verified on the bank’s server. The server-side verification is the part that matters: an attestation checked on the device can be patched out by whoever modified the app in the first place.

This is the control that detects a repackaged copy of your app — the same interface, rebuilt with additional code, distributed outside the official stores. Customers who install one have no way to tell, and the app behaves normally while forwarding everything they type.

On a rooted or jailbroken device, the isolation the operating system normally provides between applications no longer holds. Another application can read your app’s storage, inject into its process and observe what it displays.

Detection is a signal, not a verdict, and it is an arms race — determined users hide root effectively. The realistic posture is graduated rather than binary: allow the customer to view balances, require additional verification for payments, and decline the highest-risk actions. Blocking the app outright tends to push technically capable customers toward the browser or a repackaged build, which is worse for everyone.

Whatever the policy, tell the customer why plainly. A silent failure produces a call to the contact centre that nobody can explain.

Two related attacks: reading what is on the screen, and drawing something on top of it.

On Android, marking sensitive screens FLAG_SECURE keeps them out of screenshots, screen recordings and the recent-apps thumbnail, and prevents capture by screen-sharing software — which matters because remote-access scams work by talking a customer into installing a screen-sharing app and then walking them through a transfer. iOS exposes no equivalent public API for arbitrary interface, so the honest position is that this control is Android-only; claiming otherwise misrepresents the protection.

Overlay attacks draw a transparent or convincing window above the app to capture input or mislead about what is being approved. Detecting when another window is over your own during a sensitive step, and refusing to proceed, is the mitigation.

Malicious accessibility services deserve their own mention: they can read screen content and synthesise taps, which defeats interface-level protections. Detecting unexpected accessibility services during payment flows is worth doing, carefully — customers who genuinely rely on assistive technology must not be locked out, which means treating the signal as risk input rather than as grounds for a block.

Transport security is table stakes, but two specifics come up in examination.

• Certificate pinning. Pinning the expected server certificate or its issuer means an attacker who has installed their own trusted root on the device still cannot read the traffic. Pin with a rotation plan and a backup pin, or a certificate renewal will take your app offline.
• VPN, proxy and anonymiser detection. Not inherently malicious — many customers use a VPN routinely — but a useful risk signal, especially combined with a new device or an unusual amount. Treat it as one input to a step-up decision, not a reason to refuse service.

The strongest form of secure storage is storing nothing. A passkey-based design keeps the private key in hardware where the application itself cannot read it, and keeps no password, no PAN and no reusable token in application storage at all.

For what must be persisted, the platform keystore is the only appropriate place, with keys marked non-exportable and gated on user authentication. What consistently goes wrong is not the primary credential but the residue around it: tokens in preference files, account details in local caches, and — most commonly — sensitive values written to application logs, which are readable by other applications on a compromised device.

The wording differs by market, but examinations converge on the same questions. Is the application protected against tampering and repackaging, and is that verified server-side? Is a session bound to a device, and what happens on a new one? Are sensitive screens protected from capture and overlay? Is the device’s integrity assessed, and does the app respond proportionately? Is customer data at rest protected using platform hardware? And is there evidence — logs, tests, review records — rather than assertion?

That last point is the one that most often creates work late. Controls that exist but are not evidenced are treated as controls that do not exist. Per-market references are on the compliance pages.

FortAuth covers the client-side controls above as part of the SDK rather than as a separate hardening project: keys held in the device’s secure hardware and never exported, device binding, server-verified attestation, FLAG_SECURE on Android sign-in screens, and VPN and anonymiser detection feeding the step-up decision. Because the design keeps no shared secret on the device, the most valuable thing an attacker could read is not there to find.