Hacker News Reader

Comment by SmellyGeekBoy | Hacker News Reader

I guess plenty of people are going to come in here to wave their e-peen and comment on how trivial and obvious this "hack" is, but that's kind of the point. Us developers could learn a lot from this - mainly how not to design any kind of payment app.

View on HN

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

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

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)

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.

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.

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.

It's much easier to learn how not to do this than to answer how to do it!

You cannot rely on the data network, have to cope with all kinds of failure modes and mobile features support. Most companies decide that they will make some attempt to make things secure and live with the risk.

>I guess plenty of people are going to come in here to wave their e-peen and comment on how trivial and obvious this "hack" is, but that's kind of the point. Us developers could learn a lot from this - mainly how not to design any kind of payment app.

Yep, I would add that the unknown programmer that wrote the app very likely thought that it was a very clever approach (and probably he/she has been paid good money to write the app).

I actually came to complain about the silly filler content I had to scroll past that felt like ads were inserted? I just closed the page after I lost the article in the memes.

I didn’t get that on my iPhone with adblock

I found the memes not that bothering, since they are mostly in the 'narrative' part of the article and absent from the technical part.

Reply on news.ycombinator.com