Monzo urges 480k customers to change their pin numbers

https://www.theguardian.com/business/2019/aug/05/monzo-urges-480000-customers-to-change-their-pin-numbers

102 65 7 years ago

shawabawa3• 7 years ago

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/2019/5/21/18634842/google-passwords...

throwawaylolx2• 7 years ago

I assume they're all double-checking after it was reported by Facebook, and they're realising they've been doing the same thing for a long time too.

benjojo12• 7 years ago

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.

g_p• 7 years ago

When traditional banks do "1st, 2nd and 4th character" checks (i.e. via their apps), some go to pretty good lengths to protect these, even given the limited entropy.

These systems are typically backed by HSMs, and the HSM generates a high-entropy "challenge". The challenge is sent to the client, which combines the challenge with the characters the user entered. The resulting hash is sent back to the HSM, which can verify internally that the correct characters were selected, by computing the expected hash for the correct response (hopefully in constant-time).

It seems there is a bigger issue here -- Monzo used card PINs as a generic security credential in their app, and was storing them in a recoverable form (albeit only accessible to a very small number of staff). That's not standard practice elsewhere that I'm aware of - given use of the PIN is the "proof" you approved the transaction, it's usually used only in environments with dedicated PIN entry devices (ATM, card readers), rather than commodity devices (phones), unless those go through PCI-style verification and approval.

newaccoutnas• 7 years ago

PINS for the ATM are but my online banking has a number more

repolfx• 7 years ago

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.

tialaramex• 7 years ago

Rather than this workaround, don't use secrets this way at all. Do public key crypto. You don't need a PKI because you have an existing registration + authentication flow you can re-use to figure out which keys belong to which users.

This design is safe because your systems don't have any secrets to mistakenly log or otherwise lose. Make things we don't want to happen _impossible_ and they'll stop happening. Merely saying "Don't do that" doesn't make it stop happening.

Your site can literally post all the WebAuthn registration data for users on the front page, and it won't make it any easier for bad guys to sign in as those users, there aren't any secrets in there. That's a correct design.

ggambetta4• 7 years ago

Would that be my personal pin number, or some other pin number?

rys• 7 years ago

The PIN you use to prove it's your card, when you use it in an ATM or in a chip and PIN reader.

wrboyce2• 7 years ago

I'm going to hazard a guess that @ggambetta is making a veiled reference to "RAS Syndrome".

https://en.wikipedia.org/wiki/RAS_syndrome

ggambetta4• 7 years ago

It's refreshing to see the correct capitalisation and no redundant words in your sentence :)

evilmoo• 7 years ago

It's the one you use in the ATM Machine :)

ggambetta4• 7 years ago

I only use automatic ATM machines.

comma-ampersand• 7 years ago

It's your personal identification pin number

maaaats• 7 years ago

personal pin number

It's your personal personal identification number number

buro94• 7 years ago

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:

    ws-eu.pusher.com
    graph.facebook.com
    e.crashlytics.com
    app.adjust.com
    graph.accountkit.com

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.

BillinghamJ3• 7 years ago

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.

buro94• 7 years ago

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.

ancarda• 7 years ago

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?

lol7683• 7 years ago

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

dijital• 7 years ago

Out of interest, where did you hear this from?

Nextgrid• 7 years ago

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.

disgruntledphd22• 7 years ago

Because they are optimising for both Google and Facebook ads. You may not like that answer, but it's true.

keraf2• 7 years ago

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.

loriverkutya• 7 years ago

In clear? Could you show me any example supporting this claim?

buro94• 7 years ago

    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

idiocache• 7 years ago

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.

m11a• 7 years ago

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

jakub_g• 7 years ago

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

pjc50• 7 years ago

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

McDev2• 7 years ago

Is this like Sentry? Does it send a stack on a crash?

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.

mrguyorama• 7 years ago

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

zhte415• 7 years ago

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.

pidg2• 7 years ago

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.

throwawaylolx2• 7 years ago

To use this news to belittle their competition about a hypothetical event seems like a dangerous form of kool-aid fanboyism.

wrboyce2• 7 years ago

I think we can safely applaud Monzo for their transparency in stark contrast to the opaque nature of "traditional" banks.

McDev2• 7 years ago

about a hypothetical event

Not entirely: https://www.bbc.co.uk/news/business-44121901

https://www.theguardian.com/business/2018/apr/28/warning-sig...

peteretep2• 7 years ago

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

Iolaum• 7 years ago

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.

_0o6v• 7 years ago

I find it bizarre how people aren't giving Monzo more of a hard time over this. This is a security blunder of the highest order. Saying sorry in a cutesy email after the fact doesn't in any way make up for it.

scrollaway• 7 years ago

Probably because it's not a "security blunder of the highest order".

Equifax was a "security blunder of the highest order". This is an it-happened-to-Facebook-and-Google "shit, some sensitive info ended up in internal logs" blunder where there's no reason to suspect the PINs actually leaked out of the company. And even if they did, a PIN on its own is not sensitive information - unlike a password, it's just a 4 digit number, there's only 10000 of them. And unlike SSNs, they can be changed. I can tell you my PIN is 1077 and what on earth are you going to do with that information?

dbbk• 7 years ago

This is a security blunder of the highest order.

No information was leaked... it's really kind of a non-issue. Monzo's approach is radical transparency. Any other bank probably would have never said anything.

Daniel_sk• 7 years ago

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

Monzo urges 480k customers to change their pin numbers

Related Stories