[Cthulhu_]

I've heard about the security of a mobile banking app about eight or so years ago, when mobile banking was still very much a new thing and trust was a big issue. They too opted to write a second encryption layer on top of TLS / SSL, fearing MITM attacks. That was also when iOS didn't support SSL pinning yet.

It seemed to work for them, security researchers went to town on it and while they quickly discovered there was a second encryption layer below SSL, they were unable to determine what it was and how to crack it.

IIRC their encryption was never broken, and thanks to that track record, they slowly increased daily spend limits over the mobile app.

Long term, because they were very forward-thinking and they had competent native app developers (as opposed to the competition who struggled for years with mobile web / crossplatform tech), they increased their market share by a lot, now being the largest bank in NL; can't find historical data, but they went from 37% in 2016 to 40% in 2018.

[zemnmez]

this approach tends to be a self-own. Bug bounty and responsible disclosure folks don’t usually have expertise in it, so you’re just making the real attack surface less visible until someone with the expertise comes a long and owns you deeper than you could have imagined. This, ironically was also the case for steam: https://steamdb.info/blog/breaking-steam-client-cryptography... (I helped make this bug)

There is a misconception that the responsible disclosure system reflects real security threats, but it unfortunately doesn’t. The areas of expertise in the real world are different, and sticking a bunch of crypto in like that tends to be a case of making your eventual problems more complex, bigger, and harder to find.

[TimTheTinker]

True, but for those reading: this is a knock on roll-your-own crypto, not on application-level crypto or the defense-in-depth benefits it can provide.

[saagarjha]

SSL pinning and other MITM obfuscations are frequently not very useful from a security perspective.

[zemnmez]

This is a knock on application-level crypto.

[TimTheTinker]

I humbly disagree - there are times when application-level crypto makes sense. E2EE in particular relies on application-level crypto, and any password manager or "secret server" that relies only on TLS is highly suspect, in my opinion.

I attended a talk at QCon SF 2019 where the speaker advocated use of application-level encryption (even in web apps) by default as a form of defense-in-depth. I was skeptical, especially since client code itself has to be delivered using TLS only (and thus a successful TLS attack renders further defenses worthless).

But it does seem that application-level crypto allows a lot of networked devices (besides the application servers themselves) to be rendered zero-knowledge concerning most application and user data. This allows us to trust those devices less.

[zemnmez]

I never made the argument that no application should ever encrypt anything at the application level. Password managers are very niche uses.

"secret servers" or key-management systems are just fine using TLS imo. I helped draw up the design for what is now the aws secrets manager. At the point you're reasoning about TLS being broken you might as well be focusing on detection, monitoring and key rotation because the whole internet is coming down with you.

> I attended a talk at QCon SF 2019 where the speaker advocated use of application-level encryption (even in web apps) by default as a form of defense-in-depth. I was skeptical, especially since client code itself has to be delivered using TLS only (and thus a successful TLS attack renders further defenses worthless).

defense-in-depth is a weasel word. security isnt a bunch of layers that can be reinforced as such; often things that are referred to as 'defense-in-depth' cover specific characteristics of one protocol over another.

For example, in password managers as you mention you end up with application level encryption. But this is because TLS doesn't provide the guarantees they want of server blindness, and some resistance to bad TLS certs installed at the OS level (a dubious security boundary, but regardless...).

> But it does seem that application-level crypto allows a lot of networked devices (besides the application servers themselves) to be rendered zero-knowledge concerning most application and user data. This allows us to trust those devices less.

This may well be true in niche cases. In reality, there's not a lot of businesses out there who will overengineer their systems to know less about their users. zero-knowledge applications are unbelievably subtle to make really work, and it's very easy to fool even experts in adjacent security fields that an application is zero-knowledge in some respect when it isn't.

I'm digressing. Application-level encryption in 2021 is very rarely what's wanted, and the existence of niche security cases in entirely security-focussed products doesn't discount that.

[TimTheTinker]

Great points and discussion, thanks.

One thing I still want to say — when I speak of secret servers that only use TLS, I was thinking primarily of products like Thycotic Secret Server, where deployment is left to on-prem IT staff, no E2EE exists at all, authorization uses code branching not security primitives, and where “vaults” are databases with DBMS-implemented encryption at rest. Security-wise, a hand rolled solution actually could be better if written by an experienced non-security engineer.

I’m not familiar with AWS secret server, but I assume it’s deployed such that it inherits a lot of guarantees by virtue of being part of the AWS ecosystem.

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

[leokennis]

The funny thing is, before the current ING app, there was a super crappy app that used an MSN chat bot on the background to query your account balance.

But indeed as you describe, since 2012 or so, the ING app is formidable and built by amazing people.

Source: I work at ING, in IT, but in a completely different area.

[seanalltogether]

Funny you should say that, I'm looking at my ios codebase from 2010 for an eastern-"ish" european bank that hired us to build their first banking app. They wanted a completely custom encryption layer in their app for all communication. I don't know if it was a case of not trusting the current tech standards, or a case of believing their engineers were better then everyone else. They were in charge of the SecurityCenter framework, we did everything else.

[sgtfrankieboy]

Which bank? It's a 70/30 between ING and Rabobank for me.

[tdons]

https://www.security.nl/posting/34165/%22Beveiliging+ING+mob...

> "Het authenticatie protocol ziet er goed doordacht uit. Er wordt niet vertrouwd op SSL of TLS. In plaats daarvan gebruikt ING een extra encryptielaag waarvoor het wachtwoord wordt afgesproken via het SRP protocol. Ook genereert elk mobiel device een eigen profileId en een public/private sleutelpaar", merkt Van den Berg op.

In English:

> "SSL/TLS isn't trusted, instead, ING uses an extra encryption layer the password of which is negotiated using SRP. In addition, every mobile device generates an own profileId and a public/private keypair"

Assuming SRP refers to this https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

[hkolk]

Rabobank was the one with the horrible non-native client so pretty sure he is talking about ING :)

[bulgr0z]

Don't know if op was indeed talking about ING, but their app was, for a time, very wrong on Android as they seemed to have rewritten it on a Cordova/Phonegap stack which subsequently tanked their rating on the play store. Looks like they have released a new native version since then - at least on the french store.

[spockz]

There are many ING apps in the marketplace. Almost one for each product type and country. The comments above refer to the Dutch version.

[faeyanpiraat]

Are you sure the percentages are correct?

[pc86]

For a bank, increasing national market share by nearly 10% in just a few years is a pretty incredible feat. People don't generally shop around banks for checking/savings accounts, and the switching cost is very high and a pretty manual process (at least in the US, may be less onerous in NL).

[slightwinder]

Switching-Cost in Europe is around low to zero. Especially with discount-banks like ING, who are offering free services.

Bank-hopping is also simple and having accounts with multiple banks was common for certain people some years ago.

[meetups323]

Switching-cost in US can actually be negative - many banks will pay you hundreds to set up an account and get direct deposits to it for a small (~3mo) period. Payroll software is generally happy to split deposits, so this isn't a real barrier to entry.

The real barrier is who wants to bother switching banks? It's new UI to learn, new passwords, new apps, new cards, new exposure to security flaws, etc etc etc. I don't think that's any different in US vs EU.

[slightwinder]

Yes, bait-money exists in europe too. Because of which some people are constantly moving around their accounts, or just have multiple accounts for different purposes.

Until 2018(?) this was really simple, because there where good APIs for online-banking available. All you did was adding a new account to your software and call it a day. But new security-rules for EU kinda killed them off, and banks are putting up more barriers against bank-hoppers. So at the moment it's a bit in transition.

[gpvos]

Note that in NL, ING is not a discount bank.