> There are obvious security reasons for apps like banking apps to do this
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.
Jailbreak detection is done by testing for the presence of common things that allow the device owner to control the device. The device owner controlling the device is not a problem for banking. Meanwhile a malicious third party wouldn't inherently need to make use of any of those and would have strong incentives to avoid using any that trigger jailbreak detection, so it's no help there either.
And for the same reason it's basically useless for detecting cheating. Because if you jailbreak your phone so you can install some apps from outside the store and then it breaks your games, you might grumble and decide you want to play the game more. But if you jailbreak your phone because you want to cheat at games, your next step is to thwart the jailbreak detection, which is not that hard when you have the game software to inspect to see how it's doing jailbreak detection. And you can also tell when the app is updated and then run the new version on a test machine to see how the new version is doing jailbreak detection.
It's hostile and a waste of time to do this when you're going to lose anyway. You only inconvenience the people who jailbreak their phones for completely unrelated reasons.
If banks could secure their web portals to the same degree as their mobile apps, they absolutely would. “Portal A (web) cant be as secure as Portal B (mobile), so don’t bother securing Portal B” isn’t an acceptable security model. The banks are naturally going to reduce their vectors of attack to the greatest degree possible, and that naturally means that some access points will be more secure than others.
> “Portal A (web) cant be as secure as Portal B (mobile), so don’t bother securing Portal B” isn’t an acceptable security model.
Which isn't the case here. A device controlled by the owner isn't less secure than one that isn't. It's only a device controlled by an attacker that is. But "jailbreak detection" only detects the former (when it even detects that) and not the latter.
The fact that you can do banking on the web only proves that banks admit that you don't need a device the owner doesn't control in order to do banking.
“A device controlled by the owner” is one way of putting it. “A device capable of installing unverified software with an increased potential to introduce security vulnerabilities into the OS” is another.
> “A device capable of installing unverified software with an increased potential to introduce security vulnerabilities into the OS” is another.
The jailbreak community is usually quick in introducing patches for security vulnerabilities.
The most recent Mail bug [1] had a patch released 29 days ago [2]. Apple only introduced a fix in a 13.4.5 beta, and it's unsure if the same fix was put into 13.5 [3].
Admittedly, it'll be even better if the community strongly encouraged the installation of such tweaks in Cydia et al.
Clearly the fact that you can jailbreak a device really means that the non-jailbroken one wasn’t really preventing the installation of software that abuses vulnerabilities in the OS…
Banks are usually following the currently "supported" versions. At least the big ones that are all compliance based nowadays.
Windows XP and IE6 have been out of support for quite a while. They've long been dropped in favor of windows 7 (LTS support until 2023) and 10 more recently, which comes with internet explorer 10 or 11.
SSL would be quite easier to keep up-to-date if Microsoft actually upgraded their operating system and applications to support TLS 1.2 by default, which they don't for retro compatibility reasons.
For reference, working at JP Morgan, I can tell you that the company has dropped support for Internet Explorer entirely. Half of the existing internal apps don't even load on IE. Would be nice of vendors to stop wasting their time praising IE support as a feature.
> I mean, a photoTAN device with a 120x120 camera resolution? Seriously, what is this? 1999? Why not use RFC 4226 or RFC 6238 [2] [3]?
TOTP (RFC 6238) or HOTP (RFC 4226) are less secure than photoTAN/chipTAN because they are phishable, as in you can think you authorize a 30€ transfer for an internet purchase while in reality it's a 30000€ transfer to some bad people. photoTAN/chipTAN on the other hand are challenge-response based and send data about the transaction to the second factor device so that you can verify it before confirming.
> photoTAN/chipTAN on the other hand are challenge-response based and send data about the transaction to the second factor device so that you can verify it before confirming.
Actually, this statement is not true, as those transactions and their payloads are not cryptographically signed and neither are they verified anyhow [1] [2]. Attackers or malicious activities on Android can easily modify the payload and still have a valid transaction for the end-user; showing up the wrong IBAN, wrong amount and wrong recipient. This applies to both the official banking apps and the photoTAN generator devices that Cronto is (re-)selling.
Note that the research was made public and reposted/printed in a _lot_ of newspapers in 2016. And of course, nothing got improved.
If you search the web for Uni Erlangen (FAU) and the "crypto" analysis, you'll find out that Cronto / CrontoSign is the software supplier for pretty much every major bank.
And yes, it's patented, and yes, other frameworks got taken down on GitHub for copyright infringements when they tried to reverse engineer it.
The only open implementation of the HBCI 2.2 / FinTS 3 [3] standard that I personally know of that hasn't been taken down already is libfintx [4].
> those transactions and their payloads are not cryptographically signed and neither are they verified anyhow [1] [2]
Your linked sources [1] and [2] don't really cover that topic. They mainly cover the use of Android apps and highlight the danger that the Android devices might be hacked, recommending use of dedicated devices. From [2]:
> Last but not least, please note that the photoTAN procedure is not only available as a smartphone app but also as dedicated hardware (Cronto, 2011). Naturally, our statements about the security features of app-based authentication cannot be transferred to thephotoTAN hardware device. Quite the contrary, a dedicated photoTAN device — available for all three analyzed banks — offers excellent security properties largely similar to those of chipTAN.
But this wasn't your point. It might very well be that the transaction data is not verified by the generator devices and only displayed, but your sources don't state it.
> It's possible to do the same banking things using the bank's website both from general purpose PCs and browsers...
In my experience, this is not always the case. Some banks treat their mobile devices as more secure than website. For example, some actions would prompt an SMS MFA (I know, I know) if initiated from the website, but go right through if initiated from the app. It makes some sense, as on the app, they have access to things like location which they can use to make a better assessment on whether a request is fraudulent.
On a related note, the finance-related apps on my phone all offer me the option to sign in with a fingerprint sensor. Arguably you have two forms of authentication there: the presence of the physical device itself (using the secure element or whatever it is), as well as the biometric identifier (fingerprint scanner).
Neither of those are present when logging into your bank from its website, and I would also suspect that jailbreaking a phone significantly reduces the trust you can have in either.
Also, from a bank's perspective, all they care about is reducing their liability, without inconveniencing too many customers. In that context, it makes a lot of sense for banks to disallow their products from being used on jailbroken phones.
That's not actually letting you do something different. You can still do the thing on the website, it just requires SMS.
It implies they should at most only require SMS to use the app on a jailbroken phone. Or, you know, stop doing that entirely, since SMS-based authentication is horrifyingly insecure. It's literally less secure than email, and that's a pretty low bar. People should really stop using it.
Also, phones have no real way of authenticating their current location, so assuming that what the phone tells you is secure against intentional fraud is a pretty bad idea to begin with.
> It's hostile and a waste of time to do this when you're going to lose anyway. You only inconvenience the people who jailbreak their phones for completely unrelated reasons.
I'm pretty sure jailbreaking is bad for developers who want to sell nice, simple, pay up front no surveillance software, because that is primarily threatened by the very piracy jailbreaking enables.
You might imagine jailbreaking is all about giving people control or whatever. Ultimately it just means, due to piracy, that the only people that are allowed to make money off software is Google and Facebook, through ads, or other companies, which just routinely abuse the spirit of open source to monetize other people's work.
Unless you're of the frankly radical opinion that anything that costs money is bad, and everything that is free is automatically better, and that the whole app ecosystem, that pays out like billions a year to actual, bonafide human beings writing software, could be instead totally supplanted by free websites. Then of course what I'm saying makes no sense.
Yeah, whatever. Who wants to have control over their device anyway? Much better if Apple gets to decide what I do with my iDevice. Not sure why Microsoft hasn't started the same approach, at least Linux distributions discourage people from installing software outside of the repositories, but there is much work left to be done in actually making that impossible. At least the latest innovations in home computing, smart speakers, don't allow you to run anything at all other than what the makers intended. It's great for privacy if you can't do insecure things.
...
Privacy and control really are much more synonymous than at odds with each other. Sure, allowing someone to shoot themselves in the foot is something you'll want to minimize happening, but if they can't shoot themselves in the foot when they really try very hard, then how much control do they have over their private life really?
> jailbreaking is bad for developers who want to sell nice, simple, pay up front no surveillance software
I fail to see how this is explained by the "because" that comes after it. It just makes zero sense: why would a user taking control be bad for the developers if they don't want to surveil your device anyway? They already have the money up front, as you say. Wouldn't it make more sense to expect something to be mine after I paid for it up front?
> Unless you're of the frankly radical opinion that [something exaggerated to the point where it's clearly illogical]. Then of course what I'm saying makes no sense.
I'm not sure what you're trying to say here. Anyone who disagrees must be of this weird opinion and there can be no other viewpoints: either you're with you or you're illogical and "radical"?
If you’re someone who needs total control over your device then why are you buying an iPhone? Jailbreaks get patched in OS releases so it’s only a matter of time before you lose control again. If you really care about control why wouldn’t you buy an Android phone and flash a custom ROM on it?
Heh, I suppose you've got me there: I indeed don't buy devices that don't allow taking control by design. But I know there are a lot of people that like other parts of the iOS ecosystem (apps are often more polished; they might be more used to the OS; etc.) and would prefer to keep those while still having having their four freedoms on the device.
Game piracy requires exactly one jailbroken device, and that’s just because nobody has publicly cracked FairPlay yet so the easiest way to pirate a game is to just dump it from RAM once it’s been loaded and is available completely decrypted (thus necessitating the jailbreak). After that point, anyone can pirate that app, jailbroken or not.
> 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.
> 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?
I 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.
> 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.
Interesting. 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.
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.
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.
> 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.
I'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).
General purpose PCs have a security model that takes into account that the end user has root access to the machine. OSes typically have methods to detect/mitigate exploits.
A jail broken/rooted device may not have the same protections since jail breaking is typically circumventing that sort of threat protection.
> A jail broken/rooted device may not have the same protections since jail breaking is typically circumventing that sort of threat protection.
So your argument is that walled garden devices are less secure assuming there exist methods to convert it into a general purpose computer, which they empirically do.
Shouldn't this be an argument for such devices to be less trusted? After all, you can't always tell when this has happened (so you better assume it has), whereas as you say the devices designed to be operated under that threat model would then be more secure.
That’s not my argument. All I’m saying is that a bank has good reason to be concerned about a phone being jail broken/rooted.
I absolute agree that a user, as the owner of the phone, should be able to do this, especially in a safe and official manner. Right now it’s an all or nothing and that is a problem.
Jail breaking is a deliberate and involved process, in some cases something that the manufacturer even allows for.
It’s not really the same as a random piece of JavaScript on a webpage jail breaking your phone. I think having a rootable device doesn’t inherently mean your device is insecure.
> It’s not really the same as a random piece of JavaScript on a webpage jail breaking your phone. I think having a rootable device doesn’t inherently mean your device is insecure.
You are the one who jail-breaks the phone, but now third party apps you install can have much more unprotected access and you cannot be certain what they are doing behind your back.
> With all of the malware and ransomware that is constantly bringing down governments and organizations, the “security model” isn’t working.
The three largest ransomware vectors are people leaving RDP exposed to the internet, phishing emails to get login credentials that are then used to gain access to internal systems, and vulnerabilities in existing software. None of those requires the user to install third party malicious software.
> Would you do banking on a random computer?
Would you do banking on a random iPhone? I wouldn't. There have been more than enough vulnerabilities that you have no way to know if it has already been compromised.
Initially, the thesis was that ransomware doesn’t come from installing software that has unfettered access to the file system and that it comes from RDP. As far as I know RDP is not enabled by default on consumer PCs.
I just searched for “ransomware” on Google.
MalwareBytes
“One of the most common methods today is through malicious spam, or malspam, which is unsolicited email that is used to deliver malware. The email might include booby-trapped attachments, such as PDFs or Word documents. It might also contain links to malicious websites.”
PCs and Macs are “insecure by design”. Anything that the user runs has full access to the users files and applications - without administrator access. How could this possibly be more secure than your typical iOS device? We have over 30 years of evidence of what happens when the typical user is able to install software that has free reign on their computer.
“ Malvertising often uses an infected iframe, or invisible webpage element, to do its work. The iframe redirects to an exploit landing page, and malicious code attacks the system from the landing page via exploit kit. All this happens without the user’s knowledge, which is why it’s often referred to as a drive-by-download.”
The browser is also another application that is not sandboxed on personal computers. Any security vulnerability in the browser leaves the computer vulnerable.
Notice that most if not all mobile ransomware affects Android devices?
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.
Jailbreak detection is done by testing for the presence of common things that allow the device owner to control the device. The device owner controlling the device is not a problem for banking. Meanwhile a malicious third party wouldn't inherently need to make use of any of those and would have strong incentives to avoid using any that trigger jailbreak detection, so it's no help there either.
And for the same reason it's basically useless for detecting cheating. Because if you jailbreak your phone so you can install some apps from outside the store and then it breaks your games, you might grumble and decide you want to play the game more. But if you jailbreak your phone because you want to cheat at games, your next step is to thwart the jailbreak detection, which is not that hard when you have the game software to inspect to see how it's doing jailbreak detection. And you can also tell when the app is updated and then run the new version on a test machine to see how the new version is doing jailbreak detection.
It's hostile and a waste of time to do this when you're going to lose anyway. You only inconvenience the people who jailbreak their phones for completely unrelated reasons.