Comment by pta2002
Comment by pta2002 a day ago
This is like the fifth article I've read about the McDonald's app not having any sort of server-side validation. How do they keep getting this wrong???
Comment by pta2002 a day ago
This is like the fifth article I've read about the McDonald's app not having any sort of server-side validation. How do they keep getting this wrong???
> I find it disturbing that any app can examine your device in this much detail.
When I did a tiny bit of Android development a few years ago, I was astonished how free the app I made was to just examine the file system. I assumed it would be like the web, where each website can have its own little SQLite database and cookie store equivalent, but that's it. I don't know if it's changed, or if it was just because I was in a "dev mode" somehow, but that was very surprising.
It has certainly been locked down a bit. This makes easily backing up all your data using some techniques harder/impossible.
I can't include podcasts in the backup I do via rsync via termux anymore, unless I switch to an app that uses a shared storage area instead, as termux can not longer read app directories only its own and shared storage. You have to rely on each app that used app-local storage to have its own backup method. Not that I really care from the podcast PoV, hence I've done nothing about it, but it is a sign of apps being better sandboxed at the filesystem level than they used to be.
Is it not the same for computers most of the apps data is accessible by all the apps. Mobile OS came from the paradigm of the past and as the way we use our phones change so do the way how mobile os work. For a long time Android devs have wanted to obfuscate the disk from the user like iOS does but have faced push back from users and developers so in the end they created a permission where an app needs to ask permission to access the disk. Keeping the file system a black box or allowing user/apps to mess with it is a development question of the times dumb it down or not. Then people here complain children don't know anything about computers these days well yeah because we have dumbed it down so much in the name of security and usablity.
Definitely the same for computers. LOTS of software rely on saving data on "secret" locations for shareware-style trials.
macOS for one has been asking to allow access to specific folders. Other OSs are possibly starting to do the same, but it used to be a free-for-all.
By default you can `ls` almost anything on an entire drive.
Afaik all apps on android have the ability to list directories across most of the "sdcard" file system even without storage permissions.
If you're near a branch you can also just pop in and ask for one; might be faster. I did that when the battery ran out on my last one. There's no process upfront, you then have to pair it with your account. Well,you will probably have to convince them to switch your account to use a physical key - maybe that means you have to call anyway, I don't know.
It used to let you use it with a full-on rooted phone, it just popped up a message saying 'it's not our problem if you get robbed'
i wonder what caused the change
as others have said, you can ring them up and get a physical security key, it works for the website
> i wonder what caused the change
In many countries, if the consumer gets defrauded, the bank foots the bill.
I don't think the problem here is consumers getting defrauded by having an insecure rooted device. It's fraudsters using the mobile app APIs for nefarious purposes, and the best way to prevent that is to use SafetyNet and other similar mechanisms.
> and the best way to prevent that is to use SafetyNet and other similar mechanisms.
It's not the best way to prevent it. It's the easiest way for the bank to avoid liability.
The ugly truth of cybersecurity is that, in the real world, most of it is an exercise in shifting liability around and diffusing it. Making systems actually secure is not necessary.
The HSBC app runs fine on my rooted phone with a few magisk plugins and 5 marketplaces installed and a ton of sideloaded apps.
The HSBC UK app runs perfectly well on my Android phone, including full biometrics, 2FA for the website and for major functionality like transferring money.
I have at least a dozen apps installed on my phone that are not from the Play Store - a mixture of other stores (Samsung/Epic) and apps that are not from any store but I've compiled myself, or downloaded APKs directly from the developer website.
This isn't true.
I don't know much about this. Is this a (possible fundamental) flaw in Google's Play Integrity DRM, or did the developers implement it wrongly?
It makes sense, to some degree, that for example some banking apps refuse to run if they detect that the phone has been rooted, or even to go as far as to refuse to run if there are non-Play apps on the phone.
Maybe some apps with DRM media playback do this kind of check too, yes. Haven’t used Android for many years now.
Hopefully iOS stays the way it is where apps don’t get so much info about other apps on device. I prefer it that way.
GPIDRM doesn't protect against much, even if it's perfect [0]. What it gives you is an API your Android app can call into to inspect the device status.
That's not enough because the owner of the phone can just twiddle that memory between you calling the API and using the value. You fully own the code that runs on your devices, and if you don't like it then you can just choose to run different code. The GPIDRM hinders some users who want to fully own their device and also use your app, but it doesn't actually protect your app from being executed in other environments (similarly with any other modification to how the GPIDRM might function, short of it physically decrypting the code/data you intend to run and only ever running in environments that would somehow prevent people from backing up those decrypted bytes -- or, similarly, physically decrypting data unique to a particular instance of using the app and not useful for any reason when somebody else runs the app).
When, then, does GPIDRM make sense to use?
_Arguably_ the thing that banks do isn't terrible [1]. Their servers are authenticated, so it's not a security thing. They're just managing risk (people with rooted phones might be more likely to have root-level malware for example). If somebody has a rootkit leaking banking details and the attacker is also willing to pay $10 to borrow their phone number for the day, the bank account will be fully compromised. When that happens, the bank is on the hook some fraction of the time. The bank server trusts requests to either come from a real user or a user with stolen credentials, and they're trying to reduce the chance of the latter (but not eliminate, even from rooted Android phones).
How does McDonald's differ? There are no server-side checks, no passwords, no logins, no crypto handshakes, no anything. If you send a request pinky promising you're a trusted client then you'll get your free food. The implementation was so bad that the TFA demonstrated compromising it on a phone which _correctly_ passed the GPIDRM check.
[0] No such technique can be perfect. At its core, it relies on a secure hardware enclave. Physical keys are always reversible with enough time and effort, in time _linear_ in the key length. The goal is just to create a constant factor big enough that almost nobody with expensive enough tools to dismantle the chip and go probing is willing to go through the effort (or, ideally, not able to with the current generation of technology, so that rotating keys every few years can keep up with reversing efforts).
[1] I'd be shocked if people with rooted Android phones were actually more likely to be victims of phishing/malware/....
As a contractor who works building apps (and their server backends) for big clients: I don’t give a fuck. I just do the minimum so the app works. The worst that can happen is that the client asks me to fix the flaw later on, for which I will bill more hours.
I can 100% guarantee that’s what happened here.
I assumed there is always some technical documentation/app architecture and some mandatory (server side) security you have to follow, but reading this I'm being too optimistic.
I think it's the combination of trying very hard to usurp the user's control over their device, the lack of obvious reasons to do so, and the size of the brand. It doesn't surprise anybody when a bank does this, and nobody cares when some crappy pay to win game does, but McDonalds?!
I haven't eaten food from McDonalds in years and have never even considered installing their app, but if inspecting and reverse-engineering Android apps was my thing, theirs would have almost certainly caught my interest.
Which indicate that the management wants to feel good, not that the app developers care about actual security.
They have money and want to make more money? This seems like a straightforward question to answer.
McDonalds has historically not put an emphasis on security, imo it's just that simple.
This sort of things happens a lot. A few years ago a British bus company put certificates in the app to sign tickets.
The HSBC UK app will not run if you have any apps installed from outside play store. I cannot log into the website without the app. Luckily all I have with them is a lightly used credit card with a low limit so I have just stopped using it and rely on paper statement.
I find it disturbing that any app can examine your device in this much detail.