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.
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. …
-
Friday 18th March 2016 13:50 GMT 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.
-
Friday 18th March 2016 14:04 GMT 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.
-
Friday 18th March 2016 21:00 GMT 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)
-
-
-
Friday 18th March 2016 15:32 GMT 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).
-
-
-
Friday 18th March 2016 19:44 GMT 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.
Biting the hand that feeds IT
