
Monzo urges 480k customers to change their pin numbers - chaghalibaghali
https://www.theguardian.com/business/2019/aug/05/monzo-urges-480000-customers-to-change-their-pin-numbers
======
buro9
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/](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.

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

~~~
ancarda
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?

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

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

------
shawabawa3
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...](https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-
millions-of-user-passwords-in-plain-text-for-years/)

[2] [https://www.theverge.com/2019/5/21/18634842/google-
passwords...](https://www.theverge.com/2019/5/21/18634842/google-passwords-
plain-text-g-suite-fourteen-years)

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

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

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

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

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

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

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

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

[https://en.wikipedia.org/wiki/RAS_syndrome](https://en.wikipedia.org/wiki/RAS_syndrome)

~~~
benj111
Off topic, but is there a name for names that are diagnostic or demonstrative
of the thing. Eg you can't say 'lisp' with a lisp, have trouble spelling
dyslexia with dyslexia. 'hippopotomonstrosesquippedaliophobia' is the fear of
long words, TLA (three letter acronym) and the above obviously.

~~~
this_is_not_you
I think you are looking for:
[https://en.wikipedia.org/wiki/Autological_word](https://en.wikipedia.org/wiki/Autological_word)

~~~
benj111
Perhaps? The examples given seem much more limited to the qualities of the
word itself, I'm not sure the lisp example would fit under that banner.

That page does link to 'Ostensive definition' though:

"An ostensive definition conveys the meaning of a term by pointing out
examples"

So perhaps 'Auto-ostensive'?

[https://en.m.wikipedia.org/wiki/Ostensive_definition](https://en.m.wikipedia.org/wiki/Ostensive_definition)

