Improper Credential Usage: Batten Down the Hatches
Share
Commentary
Improper Credential Usage: Batten Down the Hatches
July 18, 2024
Table of Contents
In the first installment of a series of posts designed to address some of the top vulnerabilities listed in the latest OWASP Mobile Top 10, we’re taking a look at threats surrounding improper credential usage.
After all, no mobile app manufacturer wants to be singled out for exactly that, like a well-known residential smart access control system app owner experienced. The large company ended up bearing the brunt of warnings from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and subsequent follow-up clarifications that were published surrounding the warning.
With an eye on homing in on the specifics within individual OWASP-listed vulnerabilities and to help mobile app developers safeguard their apps against improper use of credentials, here are some suggestions to consider:
1. Simply avoid hard-coding credentials
Hard-coding sensitive information such as API keys, passwords, or encryption keys directly in an app’s source code or configuration files shouldn’t just be extremely discouraged; it shouldn’t be done at all whenever possible.
These credentials, once embedded in the app, become extremely difficult to change and pose a significant security risk if discovered. OWASP’s guideline for storing data, if stored locally, is to encrypt it using a key derived from the user’s login credentials.
Do not store user passwords on the device. Instead, use device-specific tokens that can be revoked. Avoid using spoofable values, like device identifiers, for authentication. If possible, use secure vaults or a key management system to store the credentials. Enforcing the passkey solutions that modern mobile platforms offer is a good way to realize that.
These systems provide a way to manage credentials without modifying the mobile app’s actual code, or changes are minimal to conduct enforcement.
2. Use code obfuscation and encrypt sensitive data
It’s highly recommended that developers use code and string obfuscation techniques to make code extremely difficult to understand and to reverse engineer.
If code and data are transformed for obfuscation and partially encrypted, attacks and theft of intellectual property become significantly more difficult, as long as proper commercial obfuscation technologies are applied. Freely available technologies often do not provide full obfuscation. With proper obfuscation being applied, thieves aren’t likely to invest their time, and they’ll simply move on to the next potential target.
To get fully efficient obfuscation, it needs to be accompanied by runtime protection like anti-tampering, anti-debugging, and anti-hooking, as well as environmental checks like anti-emulating and rooting protection, since all these additional protections cover the attack vectors that obfuscation alone will still leave open.
3. Strip your binary
A very basic recommendation is to remove debugging information before releasing the binary. This information would help attackers easily reverse, instrument, and modify a software product.
4. Always get the whole package
When applying app protection, use a whole suite of networked protection technologies with a multitude of protection approaches that all cover the backs of each other. This includes obfuscation, encryption, anti-debugging, anti-hooking, anti-tampering, anti-rooting, anti-virtualization, and anti-lifting.
5. Use strong authentication
Another basic recommendation is to use strong authentication when connecting the app to the server. This includes the use of the latest TLS version and mutually authenticated TLS with certificate rotation and individual certificates on the client.
If mTLS is not possible, use strong authentication based on the mentioned passkey solutions or by using rotating and locally protected API keys.
6. Other possible safeguards
Use security measures that include monitoring for screen overlays or other abuse of the accessibility API, which are used by attackers to steal user credentials by displaying a fake interface over the legitimate app.
For connected applications, protection against Man-in-the-Middle (MiTM) attacks is important, and it’s best with solutions that pin the certificates and have active detection of malicious redirects and malicious proxies.
Regularly update and patch the app to address known vulnerabilities and stay compliant with security best practices and standards, especially from organizations such as OWASP.
By following these suggested steps, mobile app developers can meaningfully and powerfully enhance the security of their mobile applications and protect sensitive user data from potential threats, further differentiating not only their app but their brand and business overall. The next installment in our OWASP-listed vulnerabilities will look at inadequate supply chain security.
Stay informed and secure
Get the latest insights on emerging cyber threats and in-app security measures to protect your financial institution. Stay one step ahead of hackers by signing up for our newsletter now!
Written by
Dr. Klaus Schenk
Dr. Klaus Schenk is senior vice president of security and threat research at Verimatrix and serves as head of its VMX Labs.
Commentary
Improper Credential Usage: Batten Down the Hatches
Table of Contents
In the first installment of a series of posts designed to address some of the top vulnerabilities listed in the latest OWASP Mobile Top 10, we’re taking a look at threats surrounding improper credential usage.
After all, no mobile app manufacturer wants to be singled out for exactly that, like a well-known residential smart access control system app owner experienced. The large company ended up bearing the brunt of warnings from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and subsequent follow-up clarifications that were published surrounding the warning.
With an eye on homing in on the specifics within individual OWASP-listed vulnerabilities and to help mobile app developers safeguard their apps against improper use of credentials, here are some suggestions to consider:
1. Simply avoid hard-coding credentials
Hard-coding sensitive information such as API keys, passwords, or encryption keys directly in an app’s source code or configuration files shouldn’t just be extremely discouraged; it shouldn’t be done at all whenever possible.
These credentials, once embedded in the app, become extremely difficult to change and pose a significant security risk if discovered. OWASP’s guideline for storing data, if stored locally, is to encrypt it using a key derived from the user’s login credentials.
Do not store user passwords on the device. Instead, use device-specific tokens that can be revoked. Avoid using spoofable values, like device identifiers, for authentication. If possible, use secure vaults or a key management system to store the credentials. Enforcing the passkey solutions that modern mobile platforms offer is a good way to realize that.
These systems provide a way to manage credentials without modifying the mobile app’s actual code, or changes are minimal to conduct enforcement.
2. Use code obfuscation and encrypt sensitive data
It’s highly recommended that developers use code and string obfuscation techniques to make code extremely difficult to understand and to reverse engineer.
If code and data are transformed for obfuscation and partially encrypted, attacks and theft of intellectual property become significantly more difficult, as long as proper commercial obfuscation technologies are applied. Freely available technologies often do not provide full obfuscation. With proper obfuscation being applied, thieves aren’t likely to invest their time, and they’ll simply move on to the next potential target.
To get fully efficient obfuscation, it needs to be accompanied by runtime protection like anti-tampering, anti-debugging, and anti-hooking, as well as environmental checks like anti-emulating and rooting protection, since all these additional protections cover the attack vectors that obfuscation alone will still leave open.
3. Strip your binary
A very basic recommendation is to remove debugging information before releasing the binary. This information would help attackers easily reverse, instrument, and modify a software product.
4. Always get the whole package
When applying app protection, use a whole suite of networked protection technologies with a multitude of protection approaches that all cover the backs of each other. This includes obfuscation, encryption, anti-debugging, anti-hooking, anti-tampering, anti-rooting, anti-virtualization, and anti-lifting.
5. Use strong authentication
Another basic recommendation is to use strong authentication when connecting the app to the server. This includes the use of the latest TLS version and mutually authenticated TLS with certificate rotation and individual certificates on the client.
If mTLS is not possible, use strong authentication based on the mentioned passkey solutions or by using rotating and locally protected API keys.
6. Other possible safeguards
Use security measures that include monitoring for screen overlays or other abuse of the accessibility API, which are used by attackers to steal user credentials by displaying a fake interface over the legitimate app.
For connected applications, protection against Man-in-the-Middle (MiTM) attacks is important, and it’s best with solutions that pin the certificates and have active detection of malicious redirects and malicious proxies.
Regularly update and patch the app to address known vulnerabilities and stay compliant with security best practices and standards, especially from organizations such as OWASP.
By following these suggested steps, mobile app developers can meaningfully and powerfully enhance the security of their mobile applications and protect sensitive user data from potential threats, further differentiating not only their app but their brand and business overall. The next installment in our OWASP-listed vulnerabilities will look at inadequate supply chain security.
Stay informed and secure
Written by
Dr. Klaus Schenk
Dr. Klaus Schenk is senior vice president of security and threat research at Verimatrix and serves as head of its VMX Labs.
Share this cybersecurity insight
Other cybersecurity insights
Salt Typhoon Exposes Critical Gaps in Mobile Security: CISA Reacts
When Apps Attack: HGS Hack, F@c! Messages and Bitcoin Ransoms
BoneSpy & PlainGnome: The Spyware Duo Disguised as Trusted Apps
Decoding Remo: The Evolving Android Banking Trojan