Create More Secure Applications – Don’t Hard Code Credentials; Instead, Use Application Hardening

Credentials are a problem for your app. Why? Because they’re a critical access gateway: If attackers get their hands on working usernames and passwords they can cause havoc — everything from stealing user accounts to compromising high-level application functions.

It’s big business; Sensor Tech Forum notes that 85 malicious apps on Google Play were stealing login credentials, while Verizon’s 2018 Data Breach Investigation Report found that 81 percent of hacking incidents used weak or stolen passwords.

And while part of the problem rests with users choosing username and password combinations that are easy to remember and easy for attackers to guess, applications have their own issue: Hard coding. From smart city software to stock trading applications, the use of hard-coded credentials saves time upfront but significantly impacts security.

Don’t become an easy mark for hackers: Here are six ways to boost credential control and reduce total risk.

Cancel the Hard Code

Hard coding is the practice of storing user credentials on the client side of applications. It’s a popular method for managing usernames and passwords because it provides utility for users — they enter their information once into a trusted service and the application takes care of the rest.

It’s also popular among hackers, since storing credentials on the client provides a stationary target: If they compromise your application, they could obtain full access to user accounts. This is especially problematic if you’re not encrypting your passwords — 10 of 80 stock trading apps tested by IOActive stored passwords on the client completely unencrypted. Even more worrisome? Tech Crunch notes that satellite communication systems across the globe use hard-coded passwords for their control systems.

The takeaway we’re hammering at here? Never store hard-coded passwords on the client-side of any application. Sure, it might save time — but it’s not worth the risk.

Opt for User Input

What’s the alternative to hard coding credentials? Have users provide them at runtime. If back-end app services require credentials for access, make them user-specific instead of service-specific. This means writing code that doesn’t store usernames or passwords — ever — and asks for this data time users access the application. Also a good idea? Double up with two-factor authentication. By adding one-time passcodes or USB keys, companies can significantly reduce the value of stolen passwords.

Disable Debugging

Debugging code is useful for developers to ensure apps are working as intended. But what happens when extra debugging information is still included once apps go live? As noted by Threat Post, leftover debugging code on HP laptops made it possible to deploy keylogging malware; app attackers can use debugging tools to view unencrypted data in memory during runtime. Even if you don’t leave the extra debugging information, consider hardening your application with anti-debug protection to make it even harder to inspect. Even if you’re not hard coding passwords, hackers could gain access to user information during runtime if they can leverage debugging tools.

Restrict Rooting

Rooted devices are risky for your applications. Why? Because attackers may root or jailbreak devices to run toolsets capable of mining your app for data or uncovering application flaws. And because rooting devices allows access to unapproved app stores and services, even legitimate users with rooted phones could compromise your application thanks to hidden keyloggers or other malware.

The result? Utilize anti-root mobile app hardening that detect the presence of rooted or jailbroken devices and prevent your app from running.

Manage Man-in-the-Middle Attacks

Attackers are always looking for ways to appear as legitimate users and evade in-app protections by using man-in-the-middle attacks. One such attack involves using false (or fraudulently obtained) security certificates to gain application access. Because your app recognizes the certificate as belonging to a trusted CA, secure request are granted and attackers may gain access. Minimize the impact of this issue with certificate pinning — associate hosts with expected public keys rather than general classification.

Attackers may also attempt to tamper with your application by adding or removing code that isn’t critical to daily operation but may provide lateral access to critical data. Since tampering takes different forms depending on malicious actor intent and specific app function, it’s worth deploying anti-tamper app hardening capable of shutting down apps or causing random crashes if tampering is detected.

Obfuscate Operations

If attackers can see code, they can modify it. They’re constantly looking for ways to discover the location of sensitive application code or disable key app protections. This is made more problematic by the rise of open-source and custom-built mobile APIs which enable developers to quickly build and deploy applications but may also come with easily-exploitable vulnerabilities that provide accidental app transparency.

Here, the name of the game is obfuscation. Code obfuscation tools can help protect your application by renaming files to encrypting strings, inserting dummy code and introducing false conditional statements, in turn frustrating attackers hoping to access and manipulate critical data such as runtime user credentials.

Harden Your App, Protect its Credentials

Harden your application to make it a difficult target for hackers by eliminating the use of hard-coded credentials and leveraging user-provided data at runtime. Add anti-debug, anti-tamper, and anti-root protection to any apps running in an untrusted environment (mobile, client, or public server). Also, manage man-in-the-middle attacks to shore up defense and obfuscate operations to frustrate hacker efforts.