Hacker News Reader

Comment by csmattryder | Hacker News Reader

"Never trust the client" is a lesson every developer learns at some point. Incredible how an entire company missed that, but I'd put this down to "bosses want this out by DATE? Alrighty..."

View on HN

To be fair, I'm sure the amount of money lost to people hacking vending machines by reverse engineering APKs is far smaller than the cost of getting every machine a network connection to a central server

Vending machines could be in buildings that blocking cell reception. I bet one of the requirements were that app should work offline.

And there you have it. Most people don’t understand security. The business can say they are MVP and “secure enough”.

If they are actively blocking it the building is doing something illegal.

It could be passive though. For example, underground parking lots both have vending machines and block my cellular reception.

But the benchmark this system was compared to was already a trust-the-client system : coin payments! I'm sure you can defraud coin-op machines, it's just not easy or common enough to worry too much about.

It's my impression that consumer payment systems operate on a good-enough principle. Being fraud-proof is not the goal, the goal is not to spend more on security than you are preventing in fraud.

By adding the element of a mobile device to verify the transaction it changes the dynamic here. There are protections and precautions to verify against fraudulent currency performed within the machine. The implied here is that there is no verification or protection (by means of storing values local rather then remote). In a system where there is transactional data / values stored, the default should be to have the data stored and housed within a protected system. IE central server that a simple app queries with API calls vs a database walled on a phone.

The same principles often come into play with online games and cheating, yet constantly developers make the same mistakes.

If they want it out by $DATE I'd argue it'd be simpler to add support for Apple Pay / Google Wallet.

I'd bet they didn't want to provide SIMs and data contracts for every vending machine.

Although modern credit card now have a kind of local storage that's used to pay for small amounts of money without querying the server (at least in europe). That may have deceived the developer of that app into thinking it was doing approximately the same.

You've always been able to accept a credit card without online authorization. If you've used credit cards for long enough, you've seen the carbon copy charge slips. Magstripes (or keying in the card number) works offline too, and chip cards have an offline mode. The merchant fees are higher when you run cards offline, and the risk of having a charge declined is higher too.

I'm guessing the reason they're doing a stored value system is because the per transaction part of the merchant fees is too high for vending machine coffee, getting a larger deposit as one transaction helps a lot with that (although, apparently not enough to hire people who know not to trust clients)

>"Never trust the client" is a lesson every developer learns at some point. Incredible how an entire company missed that, but I'd put this down to "bosses want this out by DATE? Alrighty..."

Can you clarify?

It sounds like the responsability for having designed an insecure app is of the people that asked the programmer/sofware house to write it[1]?

[1] and as said very likely paid good money for it ...

Never trust the client of a client-server system (not the client that hired the programmer). The server needs to own the truth. He was able to hack the app because the wallet was stored locally.

Yep, I know, it was the reference to the little time allowed that struck me:

>but I'd put this down to "bosses want this out by DATE? Alrighty..."

I've seen far too many projects where security/usability/accessibility is compromised because a project manager with limited technical qualifications decides that a time-frame is much more important than these features, and the programmers just have to get XYZ built to release for the date.

I've even been a part of some of those projects.

Isn't it up to you to make absolutely sure that PM knows what they are risking by pushing that deadline? Maybe they understand the tradeoff already. If they don't, make sure they do.

Sadly, when you tell that type of PM things that he doesn't want to hear, you get pegged as "not a team player" and either marginalized or sometimes fired.

Reply on news.ycombinator.com