You can read in the announcement the need to update the app, meaning it was the app that logged the PIN and this led to internal logging.
I love Monzo, but one thing that does concern me greatly are banking apps (or any apps that touch highly sensitive pieces of information) that include third party components or make any communication to third parties.
Of those, aside from generally "Why?" I'm most concerned by crashlytics.com . Is this like Sentry? Does it send a stack on a crash? If I'm paying someone and entered my PIN and it crashes, did my PIN go to a third party?
I saw an app recently that gave me the option in the settings to opt out of crashlytics - more of that please!
I'd be much happier seeing nothing third party in apps that deal with sensitive information.
And I'd be happy to memorise a 2nd less important software PIN for app transaction authorisation that wasn't the same as the ATM and hardware PIN.
Among other things, that resulted in us cooperating around monitoring potential hate sites on our network and notifying law enforcement when there was content that contained an indication of potential violence.
That indicates deep inspection of traffic going through CloudFlare.
AWS ELBs typically terminate the SSL connection for you. If you’re using AWS’ certificates management, you won’t have access to the private keys so you have to terminate at the ELBs.
That is correct (assuming https isn't compromised). The issue is that once the requests hits your systems, nothing by default treats url paths as sensitive. The end up in you your elb/Apache/nginx/stack trace logs. Making them really accessible to most employees.
imo this is exactly the sort of situation where if you can't implement perfectly "clean" REST, you shouldn't try at all and just use a simplified RPC mechanism only instead.
For my company, it's all POST-only, no URL params allowed, all inputs as JSON in the body only, no resource IDs in the path - just the method & version only.
You can, but it's unusual. Probably best to implement the most obvious fix, particularly because a lot of libraries (and engineers) will associate data with the query string in the context of a GET request.
One of my concerns about Monzo, that I have mentioned to them on Twitter some time ago, is the fact that they entirely rely on CloudFlare for customer facing services. Although I trust CloudFlare and understand how useful their services are, I am a bit uneasy that my banking information is transiting in clear through any third party.
dig internal-api.monzo.com
;; QUESTION SECTION:
;internal-api.monzo.com. IN A
;; ANSWER SECTION:
internal-api.monzo.com. 288 IN CNAME k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com.
k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com. 8 IN A 34.254.57.66
k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com. 8 IN A 52.212.7.167
k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com. 8 IN A 34.255.246.8
Monzo the bank, runs from Amazon and not via Cloudflare.
dig www.monzo.com
;; QUESTION SECTION:
;www.monzo.com. IN A
;; ANSWER SECTION:
www.monzo.com. 59 IN A 104.25.212.99
www.monzo.com. 59 IN A 104.25.211.99
Monzo the marketing website for the bank, uses Cloudflare.
If you go through the DNS logs for the Monzo app, you'll see everything else goes direct... Google, Facebook, Status Page, AWS.
With the only exception being some image assets:
dig monzo-prod-user-images.imgix.net
;; QUESTION SECTION:
;monzo-prod-user-images.imgix.net. IN A
;; ANSWER SECTION:
monzo-prod-user-images.imgix.net. 2280 IN CNAME dualstack.com.imgix.map.fastly.net.
dualstack.com.imgix.map.fastly.net. 4 IN A 151.101.18.208
I would argue that using a third party that specialises in security is better than remaking the wheel yourself.
Cloudflare invest a significant amount in the security of their platform and have a lot of talented engineers that focus solely on that. They have a lot more data to play around with and I would expect they can do a better job at security than Monzo alone, with their own infrastructure, with their own engineers. Note that Cloudflare is PCI compliant (https://support.cloudflare.com/hc/en-us/articles/202249734-C...)
Not sure I understand the hype of remaking the wheel, when specialist services exist that probably do the work better, more safely and cheaper.
Cloudflare basically acts as a reverse proxy adding all kinds of features (mostly caching, origin protection against ddos, waf, etc). I'm pretty sure they're pci compliant
Many banks use a CDN, primarily for DDOS protection. This includes the actual online banking endpoints. E.g. Lloyds and Barclays (major UK banks) both use Akamai, as does American Express.
The Google and Facebook stalking concerns me way more than any PIN leakage to be honest (and I'm wondering why they need both Google and Facebook Analytics?).
The leaked PINs were "leaked" to employees (and even then there's no evidence they were misused) and I expect them to be able to do damage even without those PINs if they wanted to, so to me it's not that big of a deal. The risk here could be if you reused the PIN on other cards.
On you crashlytics concern. We use sentry which allows you to sanitize data being sent for reporting. We consider the sentry app to be "unprotected" from a data security standpoint and therefore assume anything sent to it is breached.
I wouldn't be surprised if crashlytics had similar systems
I like what the challenger banks are doing. A customer of several, including Monzo, there are some features that I think Monzo and similar could add or more broadly adopt.
Different PIN for app and ATM.
'Always on' app not being always on. By this I mean opening the app and instantly being logged - no password - in with balance, transaction history, access to funds, etc. Material concern if phone lost. N26 by comparison always request password.
Again, comparing to N26, no self-imposed limit on ATM or online transactions. In N26 this is set in the app/web interface. Monzo doesn't have this self-set limit feature.
No web interface. Using a phone for everything is annoying.
Monzo do have very responsive and knowledgable customer service. And a very distinctively coloured card.
Comments
You can read in the announcement the need to update the app, meaning it was the app that logged the PIN and this led to internal logging.
I love Monzo, but one thing that does concern me greatly are banking apps (or any apps that touch highly sensitive pieces of information) that include third party components or make any communication to third parties.
In the case of Monzo: https://reports.exodus-privacy.eu.org/en/reports/88809/
+ Facebook Analytics
+ Facebook Login
+ Google Ads
+ Google CrashLytics
+ Google DoubleClick
+ Google Firebase Analytics
And according to NetGuard locally:
Of those, aside from generally "Why?" I'm most concerned by crashlytics.com . Is this like Sentry? Does it send a stack on a crash? If I'm paying someone and entered my PIN and it crashes, did my PIN go to a third party?I saw an app recently that gave me the option in the settings to opt out of crashlytics - more of that please!
I'd be much happier seeing nothing third party in apps that deal with sensitive information.
And I'd be happy to memorise a 2nd less important software PIN for app transaction authorisation that wasn't the same as the ATM and hardware PIN.
It wasn't the app logging the PIN, was their AWS ELB setup.
Two APIs were accepting the PIN as URL parameters on GET requests, since in terms of REST principles, the operations were to retrieve information.
They were changed to non-GETs with the PIN sent in the body instead. The apps needed to be updated to switch to the new APIs.
Oh wow.
That's worse than accidental logging.
Engineers should know the GET params get logged fairly routinely and shouldn't be used for anything sensitive.
I thought with https, the ISP (or anyone in between) only sees the base url and not params?
A person in the middle can see the hostname via SNI.
But if you're terminating TLS on behalf of a customer, you can see everything. e.g. https://new.blog.cloudflare.com/terminating-service-for-8cha...
That indicates deep inspection of traffic going through CloudFlare.
AWS ELBs typically terminate the SSL connection for you. If you’re using AWS’ certificates management, you won’t have access to the private keys so you have to terminate at the ELBs.
That is correct (assuming https isn't compromised). The issue is that once the requests hits your systems, nothing by default treats url paths as sensitive. The end up in you your elb/Apache/nginx/stack trace logs. Making them really accessible to most employees.
This is correct, I've seen the diff of the two Android versions.
Do you have a source for this you could share?
Monzo will post a technical write-up soon. But, in the meantime:
Before:
After (v2.59.1 has the fix):Can't you send a body with a GET request? Why change the request to POST/something else if GET was a better semantic match?
It should have been a POST.
Idempotency and implications for which operations can be cached is why.
GETs are cacheable, but if a PIN can change so can the answer. This is an authentication action, and it should have been POST.
imo this is exactly the sort of situation where if you can't implement perfectly "clean" REST, you shouldn't try at all and just use a simplified RPC mechanism only instead.
For my company, it's all POST-only, no URL params allowed, all inputs as JSON in the body only, no resource IDs in the path - just the method & version only.
You can, but it's unusual. Probably best to implement the most obvious fix, particularly because a lot of libraries (and engineers) will associate data with the query string in the context of a GET request.
Principle of least surprise and all that.
Out of interest, where did you hear this from?
Uh. I checked my bank (Boursorama, France) and I got 17 trackers. WTF? How can you just add trackers left and right in a _banking_ app?
Report them to the French information commissioner, for GDPR violation.
Embedding a particular SDK doesn't necessarily mean that there's a GDPR violation?
That's true, but as n_trackers increases, so does the chance of of some kind of GDPR violation (assuming independence of violations amongst trackers)
It's just like Sentry and does send back stack traces on a crash or any error the developer chooses to send back.
Crashlytics part of fabric.io, which was bought by Google and is actively being integrated into Google's Firebase.
One of my concerns about Monzo, that I have mentioned to them on Twitter some time ago, is the fact that they entirely rely on CloudFlare for customer facing services. Although I trust CloudFlare and understand how useful their services are, I am a bit uneasy that my banking information is transiting in clear through any third party.
If you go through the DNS logs for the Monzo app, you'll see everything else goes direct... Google, Facebook, Status Page, AWS.
With the only exception being some image assets:
There are still plenty of customer-data-carrying things which do go over cloudflare - e.g. the internet banking, the public API, in-app webviews, etc
The Monzo web interface uses the public API too.
"through any third party"
I would argue that using a third party that specialises in security is better than remaking the wheel yourself.
Cloudflare invest a significant amount in the security of their platform and have a lot of talented engineers that focus solely on that. They have a lot more data to play around with and I would expect they can do a better job at security than Monzo alone, with their own infrastructure, with their own engineers. Note that Cloudflare is PCI compliant (https://support.cloudflare.com/hc/en-us/articles/202249734-C...)
Not sure I understand the hype of remaking the wheel, when specialist services exist that probably do the work better, more safely and cheaper.
In clear? Could you show me any example supporting this claim?
Cloudflare basically acts as a reverse proxy adding all kinds of features (mostly caching, origin protection against ddos, waf, etc). I'm pretty sure they're pci compliant
They are. Relevant support page for those who are curious: https://support.cloudflare.com/hc/en-us/articles/202249734-C...
Many banks use a CDN, primarily for DDOS protection. This includes the actual online banking endpoints. E.g. Lloyds and Barclays (major UK banks) both use Akamai, as does American Express.
The Google and Facebook stalking concerns me way more than any PIN leakage to be honest (and I'm wondering why they need both Google and Facebook Analytics?).
The leaked PINs were "leaked" to employees (and even then there's no evidence they were misused) and I expect them to be able to do damage even without those PINs if they wanted to, so to me it's not that big of a deal. The risk here could be if you reused the PIN on other cards.
Because they are optimising for both Google and Facebook ads. You may not like that answer, but it's true.
On you crashlytics concern. We use sentry which allows you to sanitize data being sent for reporting. We consider the sentry app to be "unprotected" from a data security standpoint and therefore assume anything sent to it is breached. I wouldn't be surprised if crashlytics had similar systems
I like what the challenger banks are doing. A customer of several, including Monzo, there are some features that I think Monzo and similar could add or more broadly adopt.
Different PIN for app and ATM.
'Always on' app not being always on. By this I mean opening the app and instantly being logged - no password - in with balance, transaction history, access to funds, etc. Material concern if phone lost. N26 by comparison always request password.
Again, comparing to N26, no self-imposed limit on ATM or online transactions. In N26 this is set in the app/web interface. Monzo doesn't have this self-set limit feature.
No web interface. Using a phone for everything is annoying.
Monzo do have very responsive and knowledgable customer service. And a very distinctively coloured card.