Researcher says Saudi government app shipped bank key behind password '2'

Zachi (@iam_zachi) said a Saudi government mobile app with more than 10 million installs included a private key belonging to Saudi National Bank, protected by the single-character password "2."

The developer and security researcher published his account on September 8th, after saying the credential had been replaced and the exposure fixed. He did not publish the private key itself in the three-post thread.

In an earlier post, Zachi said he found a private bank certificate file, a client ID and a client secret while reverse engineering the government app. He claimed the credentials carried enough authority to empty the bank account connected to the integration. That impact claim remains Zachi's technical assessment rather than a demonstrated transaction.

The distinction matters because a private key's reach depends on what the receiving system lets its holder do. Private keys can authenticate a client or sign requests under that client's identity. The associated account, API permissions, transaction controls and server-side checks determine the resulting access. Exposure still requires immediate revocation because anyone who extracts a reusable key can attempt to act as the credential's legitimate owner.

The password offered little protection if both the encrypted certificate and the password needed to open it were recoverable from the same application package. Mobile apps run on devices outside the publisher's control, and their binaries can be downloaded, unpacked and inspected. Obfuscation may slow that work. It does not turn a distributed app package into secret storage.

OWASP's mobile security guidance classifies private keys embedded directly in an Android or iOS package as hardcoded sensitive data. Its testing guidance says client-certificate passwords should not be stored locally and certificates should not be shared across every installation. MITRE separately catalogs hardcoded cryptographic keys as CWE-321, a weakness that can allow an attacker to assume an identity or bypass access controls.

Zachi said the key was rotated before publication. Rotation is the decisive containment step. Removing a credential from the current app build stops new downloads from carrying it, but previously downloaded packages and archived versions can remain available for inspection. Replacing the server-side key invalidates the exposed credential wherever an old copy survives.

The reported 10M+ install figure establishes distribution, not the number of people exposed or the number of active users. It still changes the risk calculation. A credential included in a widely distributed package has effectively been copied millions of times, even when only a small number of researchers or attackers know where to look.

The disclosure also exposes a collapsed trust boundary between a government app and a bank integration. A banking credential with meaningful transaction authority should remain in controlled server infrastructure, with the mobile client sending narrowly scoped requests to that server. Placing the credential in the client transfers its secrecy to every phone receiving the app.

Saudi Arabia's National Cryptographic Standards cover public-key infrastructure and the full cryptographic key lifecycle. The National Cybersecurity Authority says national entities must select and implement protections appropriate to the sensitivity of their systems and data. A reusable bank key distributed inside a consumer application defeats that lifecycle before the app is opened.

The case is a basic mobile architecture failure with potentially financial consequences. Client applications must be treated as public artifacts. Secrets that confer server, banking or vendor privileges belong behind an API, where access can be scoped, monitored and revoked without shipping the credential to every user.