3 ms·
> This is obviously wrong. It's possible to do the same banking things using the bank's website both from general purpose PCs and browsers on phones for which j
by petersellers 6y ago
> This is obviously wrong. It's possible to do the same banking things using the bank's website both from general purpose PCs and browsers on phones for which jailbreak detection is not possible in the browser.
That's quite a bold statement, and also not correct in my experience. Take for example NFC payments. Both Apple and Google will disable the mobile wallet if they detect that the phone has been rooted / jailbroken.
- AnthonyMouse 6y ago> Take for example NFC payments. Both Apple and Google will disable the mobile wallet if they detect that the phone has been rooted / jailbroken. Both Apple and Google have a conflict of interest there, so that proves nothing about the security and everything about their perverse incentives. How does it even make sense? It's safe for me to use the website from a jailbroken phone to transfer thousands of dollars to the account of a foreign national but not safe to use a jailbroken phone to pay $3 for a cup of coffee in a restaurant I'm physically standing in?
- kalmi10 6y agoI remember reading that card transactions have different costs aspects for the parties involved depending on if the card is actually physically present at the time of purchase. And iirc Apple managed to convince the banking sector that Apple Pay is equivalent to chip card security, so that they get better rates. According to reddit, Apple Pay works on jailbroken devices, but still, something like this might be at play in all the other similar scenarios.
- ValentineC 6y ago> According to reddit, Apple Pay works on jailbroken devices, but still, something like this might be at play in all the other similar scenarios. I can confirm that Apple Pay works on my jailbroken devices, and as far as I can tell, no jailbreak has managed to affect the Secure Enclave.
- SXX 6y ago> And iirc Apple managed to convince the banking sector that Apple Pay is equivalent to chip card security, so that they get better rates. As far as I aware that's because Apple actually have hardware-backed implementation so tokens (or signatures or whatever, I honestly have no idea how they called for NFC payments) are generated on iPhone itself. Google on other side just keep few tokens on Android device, but they are actually pre-generated on Google servers.
- dzhiurgis 6y agoInteresting. In NZ about 5-10% of places seem to disable contactless payments in an effort to cut costs (most corner shops), while chip+pin works for as little as $1 payment.
- petersellers 6y agoThink about it more from the perspective of a jailbroken device being used as a wallet for "cloned" virtual credit cards, transit cards etc. and then using those on NFC readers. It's not possible right now AFAIK but that doesn't mean it might not be possible later. The main point I'm trying to make though is that mobile devices support NFC payments with virtual cards in wallets that are protected by Apple/Google. That's not a use case that is supported on regular PCs, so it's not unreasonable that the security requirements are different.
- AnthonyMouse 6y ago> Think about it more from the perspective of a jailbroken device being used as a wallet for "cloned" virtual credit cards, transit cards etc. and then using those on NFC readers. Any reasonable system (i.e. one using public key cryptography) does not allow the attacker to "clone" your virtual cards at all, because they don't have your private key, which never leaves your device. And if they've compromised your device (not their own) sufficiently to extract your private key then the game is over and you've already lost. Once they have the private key they don't need a jailbroken phone running the official app, they can just speak the NFC protocol directly to the reader and sign with the victim's private key. > The main point I'm trying to make though is that mobile devices support NFC payments with virtual cards in wallets that are protected by Apple/Google. That's not a use case that is supported on regular PCs, so it's not unreasonable that the security requirements are different. The difference is that the security requirements should be lower, since it's only used for in-person purchases. Even if the attacker somehow has your private key, to use NFC they would have to show up in person, smile for all the surveillance cameras and risk getting arrested on the spot if the card has already been reported stolen.
- petersellers 6y agoI'm more referring to an attacker cloning their own cards, not someone else's. Some smartcard systems assume that the state of the card is the source of truth, and not anything on the server. In that case you don't want people cloning their own cards and then using those to hop on the subway. I don't see the argument for why security requirements should be lower in that case. Security cameras are not always present and getting arrested "on the spot" for a virtual card theft seems unlikely given the nature of the crime (it seems doubtful police forces would have officers standing by for this purpose that are able to both detect and react quickly enough).