Hackers' delight: Mobile bank app security flaw could have smacked millions Security researchers from the University of Birmingham, UK, last week went public about security shortcomings in mobile banking apps that leave millions of users at a heightened risk of hacking. The researchers developed a tool called Spinner to perform semi-automated security testing of mobile phone apps. After running the …
This post has been deleted by its author
But presumably not only "supported devices" in terms of what version of the OS is coded for, but whether and when (& if) that OS receives security updates and/or patches? I'm not sure that would leave many eligible customers for mobile banking!
I suppose that in practice the banks are making risk/benefit judgements - if the costs to them of app-based fraud are small enough, they decide to live with the risks in order to not alienate customers.
This post has been deleted by its author
Perhaps it would be better if in cases of fraud, the bank refunds the customer automatically instead of pushing the blame onto the customer
That way, the bank would stand to lose a shedload of money very quickly if their app security is bollocks.
But as far as the banks are really concerned, just like smart meters, they push the latest "Ohh shiny" onto the population , and we're dumb enough to use it, and when we lose money they fobb us off with "You must have shared your pin"
Yeah, I forgot to make that clicky - https://www.bentasker.co.uk/blog/security/315-the-state-of-mobile-banking. The summary is, all pretty crap but in a variety of different ways
Sure, just turn on a VPN first. That's true even if using cellular in the U.S., unless you want your cellular provider logging/selling whatever data passes through it. My family uses NordVPN - not perfect, but well reviewed and cheap for the number of devices we're using it for.
As a (happy) Jolla/Sailfish user, and a strong believer in the benefits of a varied OS ecosystem, I am quite concerned about banks, transport systems and governments pushing "apps" as the preferred way of interacting with their services. This has led to a "duoculture", only one step removed from a monoculture, in smartphone OSs, with many people rejecting alternatives such as Sailfish because their bank / railway / taxi / government doesn't offer a native "app" for it. Apple and Google really have an ultra-privileged position here, with all these organisations effectively forcing their customers/citizens to buy one of their devices. This not only stifles competition and innovation - it also magnifies the severity of any OS level vulnerability, as it will affect a much larger segment of the population in a "duoculture" than it would in a "multiculture" (think pandemics vs. genetic diversity). It also puts increasing pressure on people to give up their privacy and their data to corporations which often have a rather flaky track record on keeping it safe. This story seems to confirm some of those fears, and makes me feel a little less frustrated about having to wrestle with my bank's desktop website UI on my Jolla.
Multi-factor authentication using a secondary source of identity validation is more important than ever. We should have gone down the route Estonia took and issued certificates to every citizen for use with banking and governmental online services. Our current model of relying solely on one set of credentials per service then trusting service providers to guarantee E2E security no longer seems fit.
Worse still, people STILL don't assume insecure-by-default. Everything is just too complicated for a layman to understand even a portion of your average app's operation in the context of system and network security. We're basically all doomed :(
Your certificate is not good enough. The bank will have your public certificate to establish that you are the person you claim to be. You can prove this with your private certificate. Now the fake bank will also have access to your public certificate. So you are preventing the fake bank from getting cheated.
The fake bank will know that ‘you’ are ‘you’
You need to have a certificate issued by the bank to get a verification that the bank is the site it claims to be. Such a certificate can be baked into a banking app. Expiration of such a certificate is no problem as the application can be updated.
OK, my problems are fewer since I don't travel abroad but when out & about, if I want to use my phone banking app, I switch off WiFi so I will only ever connect via 4G. I'll only ever use public wifi for something where network security isn't necessary.
RaspberryPi (or similar) +OpenVPN +PiHole. Or you can install OpenVPN&PiHole on an existing system.
Connect your phone/tablet/laptop/whatever to that while you're out and about, and you're done. Personal VPN to your home network, and PiHole seems to be quite a good ad+bad domain blocker.
The discussion is not about web browsers being tricked into accepting fake web sites but applications failing to check the chain of trust and not using a known certificate to establish the communication.
An App can be easily updated. It does not have to rely on a certificate it gets presented.
That said what is different with a VPN connection? In addition to names of banks an attacker will know the names of commercial VPN sites. Now there is the same problem for a MITM attack. Does the VPN software really know the supposed target? I doubt that a VPN provider only using a well know preshared secret and the email address can give protection.
In addition to names of banks an attacker will know the names of commercial VPN sites.
It's a good question. It does scale the problem the attackers have, but I'm not sure by how much.
I have OpenVPN installed for this reason. It shares certificates between the device and the server, not username+password (you can set it to do that but I prefer cert-based auth). From my understanding, if the certs don't match from both ends the connection fails. They'd have to be able to fake the server's cert to get the thing to work in that case.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
