5 ms·

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

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

jaclaz 8y ago
>"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 ...
- Zanni 8y ago
  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.
  - jaclaz 8y ago
    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..."
    - csmattryder 8y ago
      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.
      - softawre 8y ago
        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.
        ams6110 8y ago
        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.
bsaul 8y ago
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.
- toast0 8y ago
  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)
Cthulhu_ 8y ago
If they want it out by $DATE I'd argue it'd be simpler to add support for Apple Pay / Google Wallet.
- candiodari 8y ago
  I'd bet they didn't want to provide SIMs and data contracts for every vending machine.
rebuilder 8y ago
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.
- 086421357909764 8y ago
  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.
namdnay 8y ago
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
nojvek 8y ago
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”.
- paulie_a 8y ago
  If they are actively blocking it the building is doing something illegal.
  - androidgirl 8y ago
    It could be passive though. For example, underground parking lots both have vending machines and block my cellular reception.

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

jaclaz 8y ago

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

Zanni 8y ago
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.
- jaclaz 8y ago
  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..."
  - csmattryder 8y ago
    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.
    - softawre 8y ago
      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.
      - ams6110 8y ago
        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.

bsaul 8y ago

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.

toast0 8y ago
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)

Cthulhu_ 8y ago

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

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

rebuilder 8y ago

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.

086421357909764 8y ago
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.

namdnay 8y ago

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

nojvek 8y ago

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

paulie_a 8y ago
If they are actively blocking it the building is doing something illegal.
- androidgirl 8y ago
  It could be passive though. For example, underground parking lots both have vending machines and block my cellular reception.