141–150 of 150 posts
> [the extensive anti-reverse engineering measures are] more annoying than any financial app I've had, and I have 5 of them on my phone Ah, this reminds me of the Tuya app. I've done some ssl unpinning and mitm to see requests going in and out of my phone, it's pretty fun and there's often really nice and easy to use restful APIs underneath. Among them I've also done a couple of banking apps and they weren't particul…
Earlier quoted context omitted.
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
The app works perfectly well on my device, parent comment is just mistaken.
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…
Ah, it's the same with supporting browsers other than Internet Explorer!
I thought not trusting clients was already security 101?
Earlier quoted context omitted.
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.
It's literally only McDonalds though who goes to this degree and does so across different codebases in locales across the world. The departments you're talking about exist in many places, but no other big company has their apps be like this so consistently.
Earlier quoted context omitted.
It's literally only McDonalds though who goes to this degree and does so across different codebases in locales across the world. The departments you're talking about exist in many places, but no other big company has their apps be like this so consistently.
Other companies do similarly ridiculous things. I’ve personally had to push back on this in non-McDonalds companies, and I see others out there with the same kinds of problems. For instance, Starbucks has a different app for different countries, and they region-lock them. So if you have an Apple ID registered in one country and you visit another, you can’t use install that country’s Starbucks app to order. Which is s…
Earlier quoted context omitted.
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.
Linux has containers for this - firejail, flatpack and others have support for this. Older software tended to be less obnoxious about it. I have never had a desktop app refuse to run for this sort of reason. Desktop software installers do not claim to offer this security. Mobile OSes claim to be sandboxed so your expectations are different. The sorts of applications you install are different too. Many mobile apps are…
Earlier quoted context omitted.
Other companies do similarly ridiculous things. I’ve personally had to push back on this in non-McDonalds companies, and I see others out there with the same kinds of problems. For instance, Starbucks has a different app for different countries, and they region-lock them. So if you have an Apple ID registered in one country and you visit another, you can’t use install that country’s Starbucks app to order. Which is s…
I've had the websites of two American store chains (Napa and Publix) block me while standing inside their stores because my prepaid eSIM from airhub.com geolocates to Israel. I'd really like to know what's in the heads of people who come up with this sort of crap.
They probably think that geolocation always perfectly works based on the physical location and don't consider edge cases like people with roaming SIMs (which is what I think a lot of those cheap data-only eSIMs effectively are) geolocating to their home country even when abroad.
Though by now you'd think that people are aware the e.g. the Google/Apple app store region locking basically locks out all tourists, but it seems that even that isn't necessarily common knowledge…
Earlier quoted context omitted.
The problem with Tuya is that they don't manufacture the devices themselves. Instead, they provide a standardized interface for all those low-cost manufacturers and get paid by them. If it were easy to fake Tuya requests or set up your own account (trust me, I tried this to integrate a Fingerbot into Home Assistant, but you have to jump through countless hoops, and the developer account keeps expiring every few weeks…
This sounds somewhat backwards to me but maybe missing something... We got a bunch of Tuya devices and was barely aware they even have an app. They paired out of the box to a zigbee2mqtt gateway on the local airgapped network without fuss. No apps, online servers, api keys, vendor signature checks, or such shenanigans at all. I don't think the motion sensors we have from them have the capability to send dhcp over ip…
Tuya is just the cloud connector for those devices that communicates with the bridge (so the hardware manufacturers don't need to operate their own servers).