[lol768]

There was a UK retail bank that tried a strategy like this.

I maintained (and still do maintain) it was security through obscurity and a waste of engineering effort that should've been spent on actually hardening the banking API server and migrating it to a modern stack.

I thought it inevitable and indeed - it got cracked twice anyway (despite the use of Arxan, extensive anti-debugging functionality and rewriting the crypto on at least one occasion).

[sjtgraham]

Barclays? Was cracked both times by me :)

Disagree that hardening the API server is any better. This is the approach common in the US market, and my team has broken everything available there too. Also disagree with insinuations that these banks don't have good, modern stacks. Barclays in particular is great. Way better than any challenger bank.

Lloyds also took a similar approach to Barclays but they did a better job than Barclays did (although Barclays did a great job themselves too) and so we never got around to finishing it before we pivoted to the US market. As far as I know it's still unbroken, although I'm pretty sure my colleagues could easily break it today. We've since developed far more sophisticated reversing techniques.

[lol768]

> Disagree that hardening the API server is any better. This is the approach common in the US market, and my team has broken everything available there too. Also disagree with insinuations that these banks don't have good, modern stacks. Barclays in particular is great. Way better than any challenger bank.

By "hardening the API server" I mean fixing actual security vulnerabilities and improving the security posture of the API gateway, not going for further obfuscation layers or attempting to prevent third-party clients. Those are a waste of time. My position is that there's no point trying to prevent the user's access to his own data - but there is a point in enforcing e.g. access controls so customers can't access data for accounts they don't own or spend money they don't have.

When you talk about "breaking" banks in the US space, are you referring to gaining access to the API and reversing it (which has always been Teller's MO, no?) - or finding vulnerabilities with the API endpoints with actual financial implications for the institution?

> Also disagree with insinuations that these banks don't have good, modern stacks

I'm aware of your thoughts on this, though I respectfully disagree with the "modern" characterisation you have applied to legacy banks based on the sorts of tech I've seen and how it e.g. coped when faced with such exotic things as non-ASCII characters.

Monzo have at least never wasted time on obfuscating the fuck out of their API comms, nor forcibly preventing me from accessing my transactions on my rooted device or running their app under a debugger.

[sjtgraham]

With respect I think you're speaking outside the bounds of your knowledge of these systems.

> By "hardening the API server" I mean fixing actual security vulnerabilities…

That is just table stakes. Have you ever found any vulns in bank API gateways? We tested authorization boundaries with our own accounts, we didn't ever find a bug like that. I found a total of two bugs quite low impact. One was unsafe object deserialization that could potentially lead to RCE, we obviously didn't try this. The payload was signed so it most likely would have been difficult to exploit provided the signature was verified before deserializing the object. The other one was an authentication bypass, which potentially could have given you read only access to the user's accounts. You could then call up customer services and use recent transactions on the account as a knowledge based 2nd factor to be given a code to upgrade the read-only enrollment to write access. This would require some knowledge about the customer (account number, telephone number, etc) and sloppy CS, so would probably say that was also low risk. We reported both to the respective bank via internal contacts.

> When you talk about "breaking" banks in the US space…

Everything this thread refers to countermeasures banks employ to keep third parties from leveraging their private mobile API gateways. When I talk about breaking things I'm talking about breaking these countermeasures.

> I'm aware of your thoughts on this, though I respectfully disagree with the "modern" characterisation…

The content encoding of the underlying persistence layer is a tiny part. Their technology is broadly speaking very good. I am probably the world expert on the state of these systems because I have very deep knowledge of a large number of them, whereas even bank employees would only about their employer's systems.

> Monzo have at least never wasted time on obfuscating the fuck out of their API comms…

Monzo did other stuff to effect the same result, i.e. they only allow one device to be logged in at a time. So you couldn't use Monzo's app AND access your account via Teller at the same time.

I wouldn't use Monzo as an exemplar of technological capability. Barclays absolutely smokes them.

[lol768]

> With respect I think you're speaking outside the bounds of your knowledge of these systems.

I'm not going to argue with you on this; you're entitled to your opinion :)

> That is just table stakes. Have you ever found any vulns in bank API gateways?

Infosec consultancies find vulnerabilities in the API gateways of retail bank clients, yes. That's one of the things they are paid to do. And yes, I found issues myself in part of the open banking consent flow I was asked to test for a retail bank when I worked for such a consultancy. Such features don't get built without flaws.

The folks who are smart enough to reverse the mobile apps, any crypto used and write their own client get to play with these features in prod after they've been tested (either internally or via a contracted pen-test firm).

> Everything this thread refers to countermeasures banks employ to keep third parties from leveraging their private mobile API gateways. When I talk about breaking things I'm talking about breaking these countermeasures.

Then we seemingly agree these countermeasures are not effective - which is the point I attempted to express :)

> whereas even bank employees would only about their employer's systems

I have never been a bank employee so don't personally know, but presumably some of them move between orgs.

[Deathmax]

> Monzo did other stuff to effect the same result, i.e. they only allow one device to be logged in at a time. So you couldn't use Monzo's app AND access your account via Teller at the same time.

Only if you were trying to impersonate Monzo's iOS/Android OAuth clients instead of the expected AISP/PISP flows.

[jrochkind1]

So... what is any better?

I mean, I guess, hiring you to find vulnerabilities, is the pitch.

I'm curious whether your team would have found this kind of steam vulnerability.

[sjtgraham]

I haven't read the article I'm just joining in on the side-discussion in this thread.

[duckmysick]

Jrochkind1 first question isn't about the article. It's a follow-up to the side-discussion.

[throwsaways212a]

I remain convinced that rewrite was a purely anti-competitive move to stop/slow Teller and others. As someone that worked on a startup that required API access to transaction data, it was a huge pain in the ass having to write and rewrite screen-scrapers.

[xvector]

Security through obscurity isn’t an invalid technique if you also are doing security through cryptography too. One reduces your attack surface, the other reduces the number of attackers by increasing the required effort - both work. In part this is why many IoT devices also attempt to physically protect the underlying microchips, why HSMs destroy keys when enclosure tampering is evident, etc.

[lol768]

> Security through obscurity isn’t an invalid technique if you also are doing security through cryptography too

It becomes a distraction vs actually writing a secure set of endpoints in the first place.. Folks get a sense of security from it which is entirely false.