For zero trust mobile apps and APIs, credentials aren’t nearly enough.
By late 2016, mobile internet usage surpassed desktop usage. Whether mobile consumers, mobile workers, or mobile services, parts of many business transactions are done on the move.
Trust on the go starts with authentication, but it is not just user IDs and passwords. Are you really who you say you are? Can you trust the service you want to use? Can you trust the app you are using to access that service? Is your device safe? When you are on the go, zero trust means every link in the engagement chain, whether person, software, or hardware, must be authenticated.
More and more of our activities and information are being stored and conducted on mobile devices. Hackers certainly haven’t missed this trend. Crowdstrike reports in 2019 that a range of criminal and targeted adversary groups are increasing their attacks on mobile platforms while mobile security maturity levels lag behind that of traditional platforms, leading to protracted attacker dwell times on compromised mobile devices.
At the same time, the last five years have witnessed a surge in API traffic across the internet., In 2014, Akamai reported that 47% of traffic through their secure CDN was API packets, while in 2018, those API packets had grown to 83% of the secure traffic.
In traditional browser-based applications, data processing is done server side, and the resulting web page is presented with little state or structured data stored in the browser.
In contrast, mobile apps use APIs to send and receive data with the app managing the UI and maintaining state and much more data on device.
Recognizing the growing use of APIs in modern application architectures, OWASP launched the API Security project and published the OWASP Top 10 in 2019:
APIs expose sensitive data such as Personally Identifiable Information (PII), as well as critical business functions, so naturally authentication and authorization play a prominent role in the top 10 risks. Note carefully, if only authenticated apps with authenticated users are authorized to make API calls, then other API security flaws, even those not yet discovered, will be protected against exploitation.
Too often, people assume that authentication means just user authentication. If that were the case, then hackers would work hard to amass user credentials, take over accounts, and infiltrate back-end services, calling APIs at will from any device or bot.
Well, according to Akamai, that’s just what they do:
Over eight months in 2018, Akamai detected 27,985,920,324 credential abuse attempts.
Relying solely on user credentials is clearly a bad idea. There are many other indicators which can be considered: the identity of the app making the API call, the time and location of the device, the sequence of previous API calls, CAPTCHAs, human behavior sensing, biometrics, and so on.
Some of these factors, such as time and location habits, push privacy limits, while others, such as recaptchas, can be a significant user inconvenience. No one factor is enough, but authenticating more of the context surrounding the API call will result in a more resilient authentication.
Authenticating the user who is calling is important, but knowing and trusting which application is calling, even knowing that it’s a real app and not a bot, is a significant context indicator.
If you can ensure that the calling app is genuine, that it has not been tampered with and is running in a secure environment, then you have restricted the payloads and sequences of API calls to those of the valid app, and external bot attacks using stolen user credentials are shut down.
Unfortunately, API keys are the common practice used to identify an app as genuine. API keys are too easily stolen, and once stolen, they can be easily used outside the app to make any API calls with any data in any sequence.
Starbucks learned this the hard way when an important API key was exposed. A researcher used the key to show how hackers could penetrate Starbuck’s internal systems, obtain user information, and control Amazon Web Services. Starbucks conceded that it demonstrated "significant information disclosure" and paid the maximum bug bounty.
Even when API keys are secure, they offer no protection from app tampering, nor do they assess the safety of the run time environment. App authentication needs to be extended beyond static identification, and the integrity of the app must be evaluated continuously.
When app authentication is more comprehensive and dynamic, it is commonly referred to as ‘software attestation’ or in this case, ‘mobile app attestation’. For example, in 2019, a new PCI Security Standard for software-based PIN entry on commercial off-the-shelf devices (SPOC) was announced which supports a customer PIN being entered into a commercial device like a phone, or tablet while the payment card is processed via small secure device. Software attestation checks are used rather than relying on static authentication data.
Source: PCI SPOC Security Requirements
Look for attestation to become more common, especially in mobile environments, to ensure the authenticity of the client application.
As the cliche goes, a chain is only as strong as its weakest link, so every link should be properly authenticated. This is reflected in the growing push for more contextual factors than just basic ID and password credentials. For API security app authentication techniques must be enhanced. Like the PCI SPOC specification, software attestation, especially in mobile devices, will become a growing requirement for zero-trust API security.