Pressing the Side Button to Confirm Payments on iPhone X
These remarks caught my attention because a technically-savvy family member was confused by the same thing the first time they tried to buy an app on their new iPhone X. They showed me the phone with the “Double Click to Pay” animation and asked me, “What am I supposed to double click here? It doesn’t work.” What they had tried was double tapping on the “Double Click to Pay” label on screen. When I explained that the animation was pointing to the physical side button, the proverbial light bulb went off.
This is an interesting design dilemma. The reason why Apple requires you to press the physical side button to confirm a purchase with Apple Pay or in the App Store is because pressing the side button can’t be faked by an app. If it was an on-screen button, a nefarious app could present a fake Apple Pay button. With any normal app, clicking the side button once will always lock the screen, and double-clicking will put you in Apple Pay mode. Only Apple’s own software can override the side button like this. Double clicking the side button to confirm a purchase effectively guarantees that it was a legitimate payment experience.
I’m sure there must be a good reason, but I don’t understand what problem this is solving. A fake payment button is not actually going to charge me. And prior to Touch ID, payment confirmations used regular software buttons.
Update (2018-01-01): Tanner Bennett:
I had this question too. Consider this scenario:
Say the payment UI uses an on-screen button. A malicious app presents a fake IAP dialog that looks just like the real one. When you try to use Face ID, what it really does is use ARKit to detect your face then fakes the Face ID popup and tells you it couldn’t recognize your face. Now, when you hit the blue Install button, it will ask for your iTunes password.
So, it doesn’t apply to Apple Pay so much as it applies to phishing for your iTunes password.
All of this could be faked, except the Double-Click to Confirm, which would either lock the phone or trigger Wallet.
7 Comments RSS · Twitter
I think Gruber has this backwards. If Apple presented a software button, then a nefarious app *could* simulate a click on it. (Out of process views help to mitigate against this, of course.) Then you could get charged without your approval.
Even if you can't simulate a click and perform exact clickjacking, you can work out the position and say "for an extra bonus, tap *this spot* as many times as you can within the next 20 seconds!" - put the spot where the "agree" button would show up and watch people be too slow to react. Both Touch ID and the side button Face ID interface avoid this by making you both take the finger off the screen and put them on a button that would take you away from the app if clicked otherwise.
The mistake Touch ID made was to screw the home button as a "no, wait, I don't want to pay... take me out of here!" response if you were not fast enough to click so that it was interpreted as a fingerprint scan instead of a home button press (easier on the solid state home buttons). And the mistake (non-side-button) Face ID does is to not require any further consent. Looking at the screen to read the text is enough to snag your face, so that app better have had some previous step to that actually make you trigger Face ID, or just looking at the screen is enough to signal "consent".
This is exactly the same as pressing control-alt-del before logging into a windows NT machine. It’s a clever hack - only the OS can catch that key combination, so you know that it’s the OS asking for your password at that point.
Except that no one understands the ctrl-alt-del thing (and Bill Gates considers not adding a dedicated hardware button for the thing to be a mistake - http://www.zdnet.com/article/bill-gates-any-regrets-ctrl-alt-delete-should-be-a-single-button/), and it protects nothing. Both operating systems ask for passwords constantly and in situations where the user didn’t press the magical button combination. And no normal user will be confronted by a flow that looks exactly like the normal payment flow and presents sensible-looking errors, and think to themselves “weird, normally I have to do this odd thing that was never explained to me but it didn’t happen this time, I shouldn’t trust this flow”.
And is this attack not still valid on devices with Touch ID? Show payment flow, wait 10 seconds, say “bad fingerprint” and ask for a password. Do people without Face ID just have to put up with it? Apple could add the double-tap sleep function on older devices as well, surely. Is the attack real (in which case the majority of the install base is vulnerable) or not (in which case why bother)?
>This is exactly the same as pressing control-alt-del before logging into a windows NT machine
Bingo. It makes the legitimate use case more difficult, but doesn't train people not to fall for the illegitimate use case. It's security theater.
Isn’t this because a similar-looking family member could make a purchase? Face ID is more secure than Touch ID — except in one specific circumstance: “The statistical probability is different for twins and siblings that look like you and among children under the age of 13” (https://support.apple.com/en-us/HT208108).
So when your kids want to buy something, Face ID might work if they look like you? Hence why you need a password.
@Nate As far as I am aware, there’s no relation between this and the Face ID family issue, and it does not protect against that because if the face is recognized it doesn’t ask for a password.
