Barclays says that credential stuffing remains a major mobile banking risk in 2022. Ok, understood.
Knowing that, how can mobile app developers and security professionals prevent credential stuffing attacks? Here are 5 easy steps mobile developers and security professionals can take to protect mobile banking businesses and stop credential stuffing attacks fast.
What is Credential Stuffing?
OWASP describes Credential Stuffing as “the automated injection of breached username/password pairs to fraudulently gain access to user accounts.” According to OWASP, a credential stuffing attack is “a subset of the brute force attack.” However, credential stuffing attacks don’t need breached username/password pairs. In reality, attackers merely use automation to send large numbers of properly formatted but random username/password pairs into a targeted system until a match to an existing account is achieved. With a match achieved, the attacker can then execute the next step of the attack, performing an account takeover the victim’s account.
Some organizations try to stop credential stuffing attacks at the network level, hoping to catch the attacker that sends the malicious requests to the server in the act. Attackers spoof their IP addresses, Device IDs, use fake devices, emulators and more to launch and hide their attacks. Defenders often play whack a mole chasing the attackers as they move, change and morph their attacks. Network level protections don’t stop a credential stuffing attacks.
Anatomy of a Mobile Credential Stuffing Attack
Mobile credential stuffing attacks aren’t sophisticated attacks. They are brute force attacks that rely on guessing username/password pairs correctly. Attackers don’t need leaked, compromised, or stolen credentials. All the attacker needs to carry out a credential stuffing attack is (1) the format of username/password pairs used in, or used by legitimate users of, the app, (2) the address or location of the servers that will receive the fake credentials, (3) the proper query-response expected by the mobile application servers, and (4) an automated method to send the 100,000s of fake credential guesses to the targeted server. Credential stuffing attackers aren’t interested in exploiting a single account holder account. In credential stuffing, breaking into hundreds or thousands of accounts is the goal. Credential stuffing is a numbers game.
I met with a banking customer recently and they were looking to stop credential stuffing attacks. They tried the network level protections and even tried changing the mobile banking API server information each time they released a new version of their mobile applications to prevent the attacks. Only a few days after the new mobile app (with the new server info stored inside) was released to the App Store, the attacks would be back. The culprit? All the information needed to carry out the attack was inside the mobile app itself. The app made the attack easy.
5 Easy Ways to Prevent a Mobile Credential Stuffing Attack in Banking Apps
Here are the 5 easy ways to prevent a mobile credential stuffing attack in mobile banking apps.
-
Prevent Weaponization From Emulators, Simulators, and Virtualized Devices
One of the easiest things developers and security teams can do to prevent a mobile credential stuffing attack in Android and iOS apps is to stop the mobile banking app from being weaponized against the organization’s mobile app servers and backend by preventing the app from running on emulators, simulators, in virtualized environments, on players, in debugging tools and other automation systems that can turn the logic of the app against you. Remember, the easiest way to stop the credential stuffing attack is to eliminate the means of carrying out the attack – namely using the mobile banking app itself against the back-end servers.
-
Protect the Server APIs Stored in Mobile Banking Apps
For mobile banking apps to connect to application servers, the app must have the API endpoints inside the logic of the app. In general, there are two ways an attacker can get the server address, server passwords and API keys needed to launch a credential stuffing attack: (a) extract the information from the app itself, or (b) capture the information in a man-in-the-middle attack. Best practice for mobile banking apps is to use AES-256 encryption to encrypt all the valuable API information stored inside the app and protect the app against MiTM attacks when the app connects to the backend. This safeguards the critical API data in the app and prevents it from being used in a credential stuffing attack.
-
Protect Usernames/Passwords in Mobile Banking Apps Using Data Encryption
To launch a credential stuffing attack, the attacker needs either end-user credentials or the proper format of end-user credentials used by the app. These credentials can be acquired from the Dark Web (buy them), via malware against an unprotected mobile app, or reverse engineering (hacking) the code of the app. Best practice for mobile banking apps is to use AES-256 encryption to encrypt all usernames/passwords stored inside the app and protect the app against MiTM attacks when the app connects to the backend. This safeguards the critical username/password data in the app and prevent it from being used in a credential stuffing attack.
-
Allow Only Trusted Mobile Apps to Connect to Your Mobile Banking Servers (Bot Defense)
If you’ve prevented the app from being weaponized against you, the next step is to block Non-human traffic (aka Invalid Traffic or IVT), scripts and fake apps from being used to launch the attack. The easiest way to do this is to watermark the legitimate mobile banking app using secure Mobile Client Certificates when the mobile banking app connects to the back end. For this, you don’t need an SDK or API gateway or AI engine. Just a secure and secret certificate that the mobile app will present with every connection. This works because the application presents its unique certificate along with a unique password/secret to the server for inspection and validation as part of the SSL/TLS handshake. The server then inspects the certificate using its private key to ensure that it matches, in which case the server knows it can trust the client/app and allow the traffic. No cert? No connection. Simple.
-
Use Code Obfuscation to Protect Source Code & App Logic
The last part of a sound strategy to prevent credential stuffing attacks is to obfuscate the app logic inside the mobile banking app. Most obfuscation tools only obfuscate class name. To prevent a credential stuffing attack, developers and security teams have to go beyond obfuscating class names, obfuscating deeper inside the app. What you really want to do is obfuscate the app logic to prevent an attacker from creating a script that mirrors the sign up or authentication logic of the app. As most all credential stuffing attacks are aimed at the login page of the app, blocking static analysis used by the attacker to figure out how to craft the attack is a key defense in stopping the credential stuffing attack.
As mobile banking threats continuously evolve, check out the 2022 requirements for mobile banking app security to learn how to best protect your mobile banking apps against a credential stuffing attack.
I’d be happy to discuss these recommendations with you or to design a perfect defense strategy to mobile credential stuffing attacks on your Android and iOS banking apps. Request a demo for more information!
