Best practices of implementing Touch ID within financial apps

Touch ID is one of the most secure ways to authenticate users within iOS apps, making the login experience more convenient and user-friendly. Touch ID uses the device fingerprint sensor on the home button on iPhone 5s and later, with the device passcode serving as a backup, to access secure data in the iOS keychain. This allows users to have one of the most unique “passwords” to secure their financial accounts—their own fingerprint—without having to worry about insecure practices such as writing down passwords or using complex passwords that are difficult to remember.

There are two ways of implementing Touch ID—either through Apple’s Local Authentication APIs, or through access control on the underlying system keychain. Local Authentication lets you decide when to show the Touch ID prompt through calling the LAContext function:

evaluatePolicy:localizedReason:reply:^(BOOL success, NSError *error).

If the success boolean returned is true, then the user has authenticated successfully with Touch ID and developers can perform authentication manually.

Authenticating with Local Authentication is easier and has its benefit, but be wary of the risks. There are tools available on jailbroken iOS devices that bypass Local Authentication by sending a success signal to Apple’s APIs, and there have even been reports of non-jailbroken device manipulation via similar techniques. Obviously, a trained attacker would have to have direct physical access to the phone, in which case there are bigger issues at play than overriding Touch ID, but it all depends on the level of risk acceptable while designing a Touch ID strategy.

For higher risk apps, it is generally acknowledged to be best practice to use Keychain Services—this takes a little more time for iOS developers to set up because they need to write a keychain wrapper themselves, but the wrapper is easily portable and there are well-written examples online. Developers need to set up access control on the keychain so when users attempt to retrieve the secure item stored, they must authenticate with the device passcode (and therefore, Touch ID). By providing a prompt message to keychain query parameters, the Touch ID prompt displays itself any time users try to retrieve their secure item. In some ways, once the wrapper is implemented it could be argued that this is even easier and cleaner than Local Authentication—for example:

let savedPassword = AccessControlWrapper.get(username, prompt: "Login to view \(username).")

With this implementation, thieves of iOS devices will have a more difficult time gaining access to the stored data, since access to the keychain would require device authentication. Now that the basis of Touch ID is covered, there are still many different scenarios that might occur while developing a Touch ID strategy. Let’s dive in.

How can users enroll in Touch ID?

Generally, developers shouldn’t assume that a user wants Touch ID enabled. It is best practice to have a user prompt on first successful login asking each user if they want to opt into Touch ID. This prompt should be made in a way that explains the strengths and weaknesses of Touch ID to the user, and directs them to a section of the app where they can edit this setting at a later time.

If the user opts in, it’s necessary to save their credentials, or token, in order to have Touch ID successfully authenticate the next time they log in. Depending on the app’s level of risk, this is where developers could store the password, encrypted, in the access control keychain, and the username is normally stored in NSUserDefaults.

Important to note is that NSUserDefaults is just a file with key value storage—values in User Defaults can easily be discovered by an attacker. In most cases it’s safe to take that risk, as the username is not considered as sensitive as the user’s password. (This is the rationale behind the “save username” feature apps commonly offer.) There should also be another area in the app, like the settings screen, where a user can toggle Touch ID on or off. This ensures that, should a user change her mind about using Touch ID, it’s easy for her to change the preferred authentication method.

How do developers allow users to enroll in Touch ID once they are already logged in?

There are challenges that persist if a user did not initially enroll in Touch ID and decides to opt in later. As we want to turn on Touch ID for their next login, how do we save their user details if we don’t store them previously, during their initial login? Some developers suggest storing the username and password for every user who logs in on the device, with a flag that determines if the user has enabled Touch ID or not. This maybe permissible for lower risk apps, but good security practices suggest we should only store what is absolutely necessary when it comes to user info, and only with the user aware of what is being stored and why.

So how do we get the user’s credentials if they choose to turn on Touch ID? The best practice around this scenario is to have the user reauthenticate with their account, which also provides an additional security measure. With a successful authentication, the app can store user information going forward, similar to how it would handle a first-time login. (With the above mindset, developers should make sure to delete user data stored if the user decides to turn off Touch ID.)

How do we manage multiple users using a device?

A scenario many developers may encounter when implementing Touch ID is that a user may have multiple accounts or users on the same device using your app. This is especially true now that four out of five devices in the iPad lineup have a Touch ID sensor for fingerprint authentication, and iPads are commonly shared among many users. Despite this reality, there can only be one Touch ID user per device, so it’s critical to demonstrate this clearly to the user. (Admittedly, users can save multiple fingerprints in Settings, each of which will work to authenticate them. For shared devices, multiple users might each save one of their fingerprints to the shared device, but the system typically assumes one primary user—and it’s easiest for apps to do the same.) The most logical approach to this problem is:

1. Once prompting for Touch ID, apps should include in the prompt message the name of the account they are logging into, in order to clearly demonstrate which account the Touch ID authentication is associated with.
2. When logging into an account that is not the Touch ID–associated account, ensure that users have the ability to switch Touch ID to their current account. Apps can accomplish this by checking username entered versus username stored and, if necessary, display appropriate messaging asking if they want to change their Touch ID–associated account.
3. Make sure the toggle displaying the Touch ID enabled state is synced to the current account, not the status of Touch ID on the phone. Make sure the Touch ID username is the current username logged in, if not, then the Touch ID toggle should be set to off. Furthermore, if the user then enables Touch ID, apps should give the user similar messaging about changing their Touch ID–associated account.

When should I have the user authenticate?

Depending on your acceptable risk, it might be necessary to still have areas of the app behind a password wall. It might be safe for read-only data to be only secured by Touch ID—like recent transactions and balances—but more sensitive areas of the user experience should be protected. This is especially applicable when financial apps allow for transfers of funds or running payroll, for example. Touch ID can be risky for secure areas because the user can use their device password as a backup. A lot of iPhone users still depend on simple four-digit PINs to unlock their devices, which are usually less secure than the account password and significantly less secure than biometric fingerprint authentication with Touch ID. Touch ID still provides users with easy access to core, regularly used features in the app—features that are important to users across the board.

Overall, Touch ID is a feature that improves the iOS user experience within many third-party iPhone or iPad apps. It can be difficult to implement, due to the significant number of edge cases and unusual situations that may occur, but with a comprehensive Touch ID strategy, the actual logic is fairly simple. Without much effort, developers can convert existing app authentication methods to make use of the technology. With a good Touch ID strategy, even highly sensitive financial apps can minimize risk while providing added convenience to their mobile users.