Live data from Hacker News

Trusting clients is probably a security flaw

liberda.nl

81–90 of 150 posts

Re: Trusting clients is probably a security flaw

#81
post #27
post #25

Earlier quoted context omitted.

You could try getting them to give you a physical security key, they used to supply them and I think still will if you can't use the app (just say it doesn't work on your phone). I have one and the website still works with it.

Thanks, I was thinking of phoning and asking, but good to know there is some point in waiting in the queue to talk to someone!

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.

Re: Trusting clients is probably a security flaw

#82
post #72

I'm about 90% sure that for some inane reason, McDonalds outsources and creates separate apps for each country/region with these disastrous security flaws, except that at HQ they universally demand horrifically counter-productive "anti-root" measures for every locale, to a larger extent than even finance apps. Why am I so sure about this? I live on the other side of the world, the app is almost certainly an entirely…

In news press about similar nonsensical and costly business decisions some of them end up being an exec getting kickbacks or other self dealing

Re: Trusting clients is probably a security flaw

#83
McDonald’s is seriously the strangest company when it comes to the way they push your app at you. They literally ask you if they’ve installed their app as the first question when you show up at a drive-thru. I don’t trust them at all and there is no way I’m installing their stupid app.

Re: Trusting clients is probably a security flaw

#84

Earlier quoted context omitted.

> professional body membership is becoming more important for programmers. People need to be able to say "I studied what you asked me to make, and refuse to work on this illegal, insecure, depressing cruft, and if you fire me for having professional ethics my lawyers will empty your company bank account." I think this might be an interesting one to consider, other than the "depressing" bit of course. The problem is,…

And who's the "you" in that case? If you're on a team of ten developers working for a shoddy company - because your family can't eat lofty principles - and a bad piece of software is released, who loses their accreditation? Is it the whole team? Do we go through the commits one by one? Is it just the tech lead, or the PM, or the engineering manager?

The same way it works in engineering. What happens when a building collapses due to not following engineering code?

Re: Trusting clients is probably a security flaw

#85
If I turn off location, ad tracking, or other permissions on the iOS version the McD's app only shows the breakfast menu and no deals are available. This is on a loyal, active account with 40k reward points. On iOS you do not have the option to root your phone so I just eat there less which is probably a good thing anyway.

Re: Trusting clients is probably a security flaw

#87
post #34

Earlier quoted context omitted.

Well, they're also an app that relies (at least on Android) on Google's Play Integrity DRM to "keep it safe" from those pesky root users. And like clockwork, this false sense of security leads developers into stupidly trusting the client.

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?

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/....

Re: Trusting clients is probably a security flaw

#88
post #65

Earlier quoted context omitted.

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 permiss…

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.

[deleted]

Re: Trusting clients is probably a security flaw

#89
post #73

If an app tries to detect that I have root or a non-stock OS, I will give it a 1-star review on Google Play 100% of the time. Everyone who has a rooted device should do this.

One good reason why "honest" app vendors do this is because providing tech support for custom OS's (in addition to the wide variety of popular handsets) is more costly. They also might not want the responsibility - in case something like your banking app gets pwned by random malware, they want to blame the OS vendor. CYA is always a good strategy.

But if someone is seriously thinking client-side security works, yeah the app deserves your review - and probably some reversing, just for fun.

Re: Trusting clients is probably a security flaw

#90
post #72

I'm about 90% sure that for some inane reason, McDonalds outsources and creates separate apps for each country/region with these disastrous security flaws, except that at HQ they universally demand horrifically counter-productive "anti-root" measures for every locale, to a larger extent than even finance apps. Why am I so sure about this? I live on the other side of the world, the app is almost certainly an entirely…

I’ve worked on apps like this for companies like this. What happens is that their IT department mandates an expensive pen test for suppliers, anti-root requirements are on the pen-tester’s generic checklist, and most companies won’t push back on the pen test results. If you do, they normally fold and admit it’s not required.
Post reply on HN