Stevie Graham: Why I hack mobile banking apps

One of the highlights of the QCon software development conference in London last week was Stevie Graham's presentation on reverse-engineering mobile banking apps. "Who's ever wanted a banking API?" Graham asked his audience, mainly developers and including numerous attendees with the names of well-known banks on their badges. …

[Anonymous Coward]

SSL pinning

I've used iOS kill switch (or android trustkiller) to monitor SSL traffic that's pinned..... It's a bit fiddly but seems to work ok.

[happy but not clappy]

Stevie's time has passed

So Stevie's problem is that if all the banks expose a standard API, there is no reason for his app to exist. Sorry Stevie.

Oh, and I am in this business, and it is looking like the banks will not be dis-intermediated by this as described. It's worse. They'll lose the piles of cash they've made by controlling the channel. And if that happens, then someone else will need to pay. Probably us.

Then people will see that push payments are intrinsically safer, and therefore less risky, and therefore cheaper, than pull payments. Cue Visa and Mastercard's business exiting stage left, followed swiftly by all those payment providers and probably a bunch of banks. Part of me is pleased.

[Adrian 4]

Re: Stevie's time has passed

Fsvo 'standard'.

When did it ever happen that all implementers worked the same, and there was no need to handle any exceptions from the 'standard' ?

[happy but not clappy]

Re: Stevie's time has passed

Well the EU are trying to put their foot down here, but you are right. Unless one of the utilities (like Vocalink/Faster Payments) gets broadly accepted, the banks will screw it up.

[NoneSuch]

Traditionally, weak security has been met with jail time for the person who brought it into the light. The Americans are excellent at that. Let's not fix the flaw, let's just jail the person who revealed it.

[Gordon 10]

security through fragmentation vs an API monoculture

OSS wisdom would suggest the monoculture approach is safer - the many eyes hypothesis. Then heartbleed happened.

Trouble is that comes up against the vulnerability and risks of a monoculture - crack 1 api you've cracked every customer who uses it. The rewards go from compelling for 1 banks customers to irresistible for every banks customers.

Which one is safer? Flip a coin.

[Adam 1]

Re: security through fragmentation vs an API monoculture

API monoculture isn't what is described though, at least not in the openSSL sense.

Heartbleed was two flaws; a stupidly designed API call and a buggy implementation of it. The stupid design was to allow the caller to independently mention the size of the buffer and the amount of data to read when it should have derived one of those pieces from the other. But the stupid design only matters because of the implementation bug whereby the server failed to validate that an untrustworthy client could manipulate those numbers to read additional information from memory.

Unless I misread the article, all that is proposed is a common API that each bank would independently evaluate the best way of implementing. So if the design was flawed, some banks would be caught pants down and others would return an error.

It's more similar to ART vs Dalvik vs Oracle implementations of the same method calls (but no points for guessing which of those would have the crap security implementation)

[techulture]

Re: security through fragmentation vs an API monoculture

Indeed, "I" is for "interface", not "implementation".

[Doctor Syntax]

"if third parties can manage the accounts of their end users programmatically, it diminishes the customer relationship."

There is, of course, a means of cutting third parties out of the customer relationship: branches. It seems that banks don't really care very much about this.

[Andy E]

Banks have just been given the green light to remove the human element from some aspects of the customer experience. If you need general advice you will be directed to a web site or deal with a multiple choice phone system. Its part of a cost cutting exercise apparently and shows that the banks don't value you they value your money (or debt).

[DryBones]

"Credit Union"

[oiseau]

Don't give a f*ck

> shows that the banks don't value you they value your money (or debt).

Quite so ...

But ...

Has it *ever* been any different?

[Neil Barnes]

Same question I asked last time

WTF is *any* third party doing with access to my bank account?

Here's how a transaction works. You, the party of the first part, asks me, the party of the second part, to pay you a sum of money in return for specified goods and services. I, the party of the second part, authorise my bank, the party of the third part, to transfer money to you, the party of the first part.

That's it. You, the party of the first part, may not, under any circumstance, involve yourself with my bank, the party of the third part, without first and on every occasion requiring my (the party of the second part) permission *given to the bank (the party of the third part)*

Sanity clause? Don't be silly, everybody knows there's no sanity clause.

[happy but not clappy]

Bang on

This is exactly how it should work, and why your bank won't go away. Full disclosure: I design a product to do this (coming soon folks!) so I might be a teensy weensy bit biased.

[John Smith 19]

Hooking the despactch table. Damm that takes me back.....

TSR utilities and at least one mainframe scheduler.

Nice to know some of those classics are still around.

Now who on this site wrote "Banks are large IT businesses with a banking license" ?

[nijam]

> ... it diminishes the customer relationship...

I thought the banks had more-or-less completed that process over the last 50 years?