iOS App Security: Essential Steps to Take

My name is Daria Chastokolenko, and I have been in iOS development for four years. I work in the Geniusee team, and among the company's latest favorite projects is the development of a neobank for our partner. I want to share our team's recommendations on the security of the iOS application in 2024, which we used in this project. Also, I will be happy to hear your tips on mobile application security.

In this article:

The case extracts

First, I will talk a little about the project. Our client is a US-based fintech company that develops neobank for gamers, and Generation Z. Its primary mission is to create a digital alternative to the traditional financial system and enable each client to have more control over their finances.

The project started almost two years ago, and the Geniusee team joined a year ago in the Dedicated Team format. When the stages of business analysis and the Discovery phase ended, the solution's active transformation began. We took the first steps to create iOS and Android mobile applications and to form a new team.

Our team included two iOS developers, two Android developers, three DevOps engineers, three backend developers, a business analyst, two project managers, three QA engineers, a technologist, and a CTO. We worked with our client's in-house team based in California. By the way, the locations of the teams helped us follow the “Follow the sun” model, with which product development is carried out almost 24 hours a day :)

Security risks in iOS

60% of financial companies now develop applications for phones, as most mobile users spend 90% of their time on mobile applications. Thus, it is becoming increasingly important to ensure the iOS App transport security and guarantee that user information remains protected.

Any violations in the mobile application can potentially damage the entire system, so it is essential to know how to ensure security. Of course, the process of identifying all threats and determining the level of security of a huge application can be complicated. However, given the seriousness of this issue, we have created a list of potential threats and methods to address them.

According to OWASP statistics, there are ten main security risks for mobile applications:

• Improper platform usage

• Insecure data storage

• Insecure communication

• Insecure authentication

• Insufficient cryptography

• Insecure authorization

• Client code quality

• Code tampering

• Reverse engineering

• Extraneous functionality

To comply with all elements of application security, our team used the MASVAS (Mobile App Security Verification Guide) system. This standard defines security requirements that can be applied to mobile apps on both iOS and Android. All requirements here are divided into two levels, L1 and L2. L1 is the basic level of requirements that absolutely all applications must meet, regardless of their purpose. The L2 includes applications that have highly sensitive data (this is our application). In addition to the security requirements standard, this guide also includes a checklist for testing all MSTG (Mobile Security Testing Guide) requirements, which tester teams can use.

Subscribe to our news

Subscribe

X

Thank you for Subscription!

Our iOS app security best practices

To cover all the security issues of the mobile application, we conducted a special workshop and wrote a list of all possible iOS security issues and solutions for iOS applications. Below I suggest you read about iOS app security best practices and go through each item in more detail.

Secure data storing

Issue: Both iOS and Android support copying/pasting data via the clipboard. Confidential data can be stored, restored, or modified on the clipboard, regardless of whether the data source was initially encrypted. If it is in plain text when the user copies it, it will also be in plain text when other applications access the clipboard.

Solution: When entering sensitive information, such as passwords, credit card information, etc., be sure to mask the input fields and prevent this data from being cached.

SSL pinning

Issue: By default, when establishing an HTTPS SSL connection, the client verifies the server certificate. However, the client does not check whether this certificate is precisely the certificate used by your server. The client's mapping of SSL certificates in the device's trusted certificate store to those used on the remote server opens a potential security hole. 

Most iOS applications use the TLS (Transport Layer Security) protocol to communicate with the server. Applications usually do not specify which certificates to trust and rely on the iOS certificate. 

However, the certificate stored on the device can be easily compromised: the user can install a dangerous certificate and thus allow man-in-the-middle attacks when an attacker replaces the certificate and gains access to traffic. Attackers can use MitM attacks to steal login credentials or personal information to sabotage network communications or corrupt data.

Solution: If HTTP traffic is not encrypted, anyone on your network can see it. So how can you check if it is allowed? This can be checked in the info.plist file:

SSL-pinning is a process that allows you to associate a server with its certificate or public key. In this case, the application rejects all certificates, except those "pinned," i.e., when communication with the server begins, the server certificate is checked with a "pinned" certificate/key. If they match, a client-server connection is established. There are two ways to implement pinning: through a certificate or a public key hash. Apple recommends that you use the CA (certificate authority) key hashes not to have to deploy the application again if you change the keys.

You can find the solution to this problem in the official guide from Apple.

Data leakage

Issue: there is no denying the fact that with the increase in the number of mobile apps, attackers have also improved their ways of hacking and stealing users' confidential information. Data leakage can occur during accidental data sharing, such as screening to multitasking or when the application goes into the background when the system snapshots the screen and saves it to disk.

Solution: possible solutions to the problem of data leakage may be:

• Overlay screen, i.e., adding a logo or blue screen image to the background.

• For better UX, you can also clear fields that contain security information.

• Redirect the user to the previous screen.

Face ID/touch ID

Issue: Data theft due to physical theft of the phone. For criminals, the use of stolen information becomes as attractive as the sale of the device itself. The hijacker can access your personal information, so you must securely protect it.

Solution: in this case, we implemented a biometric authentication with a PIN code for each application launch.

But if you misuse this API, attackers can easily pass a biometric check. An example of a similar case is shown in the Dropbox and Evernote applications.

Storage API Overview:

1. UserDefaults — non-encrypted storage, available even on a locked device. No sensitive data can be stored in user defaults.
2. Keychain — encrypted SQLite database. It is decrypted when unlocking the device.
3. Secure Enclave — isolated from the central processor, used for an additional level of security, key storage for encryption Keychain entries.

An important point when using Keychain is access policies, i.e., the conditions under which the data will be decrypted.

An example of biometric login implementation from Apple documentation:

This approach is vulnerable, as it is easy for attackers to simply check the Boolean check and replace the value, which returns to true.

A safer way to implement this is to store data in Keychain with specific access control that allows you to bind biometrics.

When you create an access control, you specify two conditions under which data from the Keychain can be retrieved.

1. This is the access level:

For example, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly means that data can only be accessed when the device is unlocked and only when the code is flooded on the device.

ThisDeviceOnly means that this data will not be shared via iCloud Keychain or backup.

2. Authentication level. This flag allows you to set up a biometric check to access data from Keychain.

Creating access control is as follows:

The second parameter just determines the level of access we need. The third parameter determines the authentication level, and you can specify a more flexible version of SecAccessControlCreateFlags.userPresence. This also provides for biometric verification, but in case of a failed attempt, a fullback is automatically performed before checking the poster.

Adding data:

Getting data:

Jailbreak Detection

Issue: The user can gain root access on a jailbroken device, which means installing software that is not verified by Apple and the malicious software may appear. Therefore, attackers can steal or sell sensitive data, passwords, and other authentication details.

Solution: possible solutions to the issue of data leakage may be:

1. Check the existence of paths, for example /bin/bash.

2. Check for dynamic libraries in memory

3. Call fork() or popen(). third-party that can be used to fix the jailbroken device.

Two-factor authentication data(2FA)

Issue: Traditional password-based authentication methods alone may not suffice for data protection of sensitive user accounts from compromise.

Solution: I emphasize the critical importance of robust authentication practices in secure iOS app development. One standout method is the implementation of Two-Factor Authentication (2FA), which adds an extra layer of defense against unauthorized access. 

By requiring users to provide two forms of identification, such as a password and a one-time code, 2FA significantly reduces the risk of security breaches, even if passwords are compromised. Through seamless integration of 2FA using trusted libraries like Google Authenticator and Authy, we enhance both data security and user convenience. Moreover, regular review and adaptation of 2FA implementation according to evolving security standards are essential to ensuring the app's resilience against emerging threats.

Encryption of personal data

Issue: Manual data encryption and decryption tasks in iOS app development can be cumbersome and prone to security vulnerabilities, potentially leaving sensitive user data at risk of compromise.

Solution: Handling encryption and decryption tasks manually can be daunting, which is why we opted for leveraging the powerful CryptoSwift library. This library offers a plethora of robust encryption key algorithms readily applicable in Swift, streamlining the encryption process. Let's delve into an illustrative example: storing and retrieving passwords securely from Keychain using CryptoSwift algorithms.

The above function securely stores the username and password by encrypting data and then storing them in Keychain as a hashed string. Let's dissect the process:

1. We initialize the salt variable with a random string to enhance security.
2. Utilizing the SHA-256 hash function, we compute the hash of the password along with the salt.
3. HKDF (HMAC-based Key Derivation Function) facilitates the derivation of cryptographic keys from the password and salt.

By incorporating the salt, we introduce an additional layer of complexity for potential attackers. Merely encrypting the password without a salt could leave it vulnerable to attacks leveraging precomputed hash tables.

With this approach, even if an attacker possesses a list of common passwords, decrypting them becomes significantly more challenging. Subsequently, logging in using the generated key ensures a secure user authentication process.

It's imperative for the server to be aware of the encryption techniques employed, enabling seamless verification of keys to authenticate users.

Embracing this approach significantly enhances the security posture of your application, safeguarding sensitive user data effectively.

Key agreement

Issue: In iOS app development, securely establishing communication channels and exchanging sensitive data between parties can be challenging due to the risk of interception and unauthorized access, posing a threat to the confidentiality and integrity of information exchanged.

Solution: Mastering secure key agreement methodologies is vital in secure iOS app development, and one standout approach we've integrated into our secure coding practices is the use of Key Agreement protocols. Specifically, we leverage the Diffie-Hellman key exchange protocol, a cornerstone in establishing secure communication channels. Let's explore how we implement this protocol in secure iOS applications:

In the provided code snippet, we initiate the key agreement process by generating a private key using Apple's CryptoKit framework. We then extract the corresponding public key from our private key and securely transmit it to the other party. Upon receiving the other party's public key, we perform a key agreement using our private key and the received public key. This computation results in a shared secret, enabling both parties to establish a secure communication channel.

By incorporating the Diffie-Hellman key exchange protocol into our secure iOS app development workflow, we ensure robust encryption and confidentiality in data exchanges. This approach strengthens the security posture of our applications, safeguarding sensitive information effectively.

Signature verification

Issue: Without robust mechanisms for verifying the integrity of application code signing, the iOS development process is susceptible to security risks such as the installation of unauthorized or tampered software. This could compromise the confidentiality, integrity, and overall security of user data and device functionality.

Solution: Ensuring the integrity of application code signing stands as an important practice in iOS mobile app security tools offered by Apple. With mandatory code signing, the operating system rigorously vets processes and applications to ensure they originate from reputable sources.

In this process, all executable code must bear the signature of an Apple-issued certificate, validating its authenticity and origin.These stringent security measures extend the concept of the trust chain from the operating system to applications, fortifying defenses against untrusted or tampered code fragments.

Developers, within the Apple Developer Program framework, sign their applications using certificates, further enhancing the ecosystem's security. By meticulously verifying certificates, Apple fosters a marketplace where all applications undergo scrutiny, instilling confidence in users regarding the apps they install.

Additionally, developers can embed various software environments in their applications, with the system conducting code signature verification for all dynamically linked libraries, reinforcing the robustness of the security infrastructure.

This comprehensive approach underscores Apple's commitment to providing an environment for security in iOS apps and iPadOS users and developers alike.

More on the topic

AI mobile app development: impact, challenges and the future

Ever wondered how AI is changing your favorite mobile apps? This article spills the beans on the good stuff AI brings and the problems it tackles.

Learn more

Regular updates

Issue: Without regular updates, iOS applications remain vulnerable to security threats, including known vulnerabilities and emerging risks. This exposes user data and iOS devices to potential exploitation by malicious actors, undermining the overall security and integrity of the app ecosystem.

Solution: By diligently releasing updates, we addressed vulnerabilities promptly, enhancing the overall resilience of their apps. These updates not only patched known security flaws but also incorporated the latest security features and best practices recommended by Apple.

Moreover, staying abreast of platform updates allowed us to adapt our app to evolving security standards and regulatory requirements. Through transparent communication with users regarding the importance of updates for security reasons, we encouraged timely adoption and minimized the risk of exploitation by malicious actors.

Ultimately, prioritizing regular updates demonstrates a commitment to maintaining the security and integrity of iOS applications, fostering user trust and confidence in the app ecosystem.

Conclusion

Creating safe and reliable applications for iOS is not an easy task. Mobile solutions with all their functions are an integral part of almost everyone's life, so it is crucial that we, the developers, treat security and, consequently, user data with the utmost attention.

In this project, we managed to develop a strategy for the data protection of mobile applications from the very beginning, including penetration testing, and consider as many vulnerabilities as possible, which could further become real threats and security problems. That is why we recommend thinking over the security system at the stage of creating the project architecture. And we took all the nuances into account before writing the code during cybersecurity services.

What practices do you use for data protection in mobile software?