Live data from Hacker News

Monzo urges 480k customers to change their pin numbers

theguardian.com

51–60 of 66 posts

Re: Monzo urges 480k customers to change their pin numbers

#51
post #20

As someone who is fully drunk on Monzo kool-aid, well done to them on (a) identifying the problem and (b) immediately telling customers what to do. Imagine how long this would have been an issue if it had happened at Barclays or TSB.

Barclays have surprised me with how good their tech seems to be

Really? They can't join a Barclaycard with a checking account because the former was opened through the internet and not from the store (Their words.) Plus they don't allow installing the Barclay's mobile app if you are running Lineage OS and openGapps despite passing safetyNet. Last but not least the web log in process for Barclaycard is security theatre. Split into 2+ steps but all knowledge based, ie still only 1 factor but annoying to use.

Re: Monzo urges 480k customers to change their pin numbers

#52
post #40
post #17

Earlier quoted context omitted.

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?

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.

Re: Monzo urges 480k customers to change their pin numbers

#53
post #9

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/r…

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

Re: Monzo urges 480k customers to change their pin numbers

#54
post #32

Earlier quoted context omitted.

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.

This is correct, I've seen the diff of the two Android versions.

Do you have a source for this you could share?

Re: Monzo urges 480k customers to change their pin numbers

#55
post #40
post #17

Earlier quoted context omitted.

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

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

Re: Monzo urges 480k customers to change their pin numbers

#56
post #9

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/r…

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.

Re: Monzo urges 480k customers to change their pin numbers

#57
post #23
post #9

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/r…

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.

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

Re: Monzo urges 480k customers to change their pin numbers

#58
I remember we worked for a well established (no startup) EU bank on a completely new mobile banking (which later won several awards) and I always kind of wondered why they didn't want any 3rd party services like Google Analytics or Fabric. Well now I completely understand. Also, the PIN (which was a "password" to enter into the app) never left the app and the bank didn't know the PIN. A SRP (Secure Remote Password) protocol was used so that the passwords never left the device and actually even the communication could be done over HTTP (instead of SSL) and the attack would not gain the passwords/keys. I became a customer after working onsite for them and seeing the code and working with the devs at the bank :-).

Re: Monzo urges 480k customers to change their pin numbers

#59
post #48
post #43

Earlier quoted context omitted.

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? AdColony Adincube AppLovin ATInternet Facebook Ads Google Ads Google CrashLytics Google DoubleClick Google Firebase Analytics Inmobi MAdvertise Millennial Media Ogury Presage Smart Tapjoy Twitter MoPub Unity3d Ads

Report them to the French information commissioner, for GDPR violation.

Embedding a particular SDK doesn't necessarily mean that there's a GDPR violation?

Re: Monzo urges 480k customers to change their pin numbers

#60

Seems like credentials being stored in logs is something that happens at pretty much every tech company - see e.g. Facebook[1] and Google[2]. Perhaps client and serverside hashing should be standard - at least then the actual credentials wouldn't be leaked, and the salt could be rolled the next time the user inputted it [1] https://krebsonsecurity.com/2019/03/facebook-stored-hundreds... [2] https://www.theverge.com/2…

PIN's are 4 digits in the UK. Hashing them (even with a per user salt) would only produce 10k possible hashes. To have anything that was difficult to brute force would also just not practical on CPU constrained mobile devices.

That's why you don't hash it, you encrypt it. What they want to do here can be solved using something called channel binding.

The problem is not that we can't do this securely, it's two separate but related problems:

1. The web stack was never designed for RPC and attempts to use it that way are often unsafe.

2. Poor or missing libraries to make common patterns safe. Why was the logging framework happy to log the PIN, well, because the type system didn't know the PIN is sensitive. Why was the PIN even sent in the clear at all, well, because libraries to do this securely aren't well known and the web doesn't help.

Post reply on HN