7 ms·

Monzo urges 480k customers to change their pin numbers

shawabawa3 7y 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-of-millions-of-user-passwords-in-plain-text-for-years/ https://krebsonsecurity.com/2019/03/facebook-stored-hundreds... [2] https://www.theverge.com/2019/5/21/18634842/google-passwords-plain-text-g-suite-fourteen-years https://www.theverge.com/2019/5/21/18634842/google-passwords...
- throwawaylolx 7y 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 7y 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 7y 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 7y ago
    PINS for the ATM are but my online banking has a number more
  - repolfx 7y 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 7y 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.
ggambetta 7y ago
Would that be my personal pin number, or some other pin number?
- rys 7y 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.
  - wrboyce 7y 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 https://en.wikipedia.org/wiki/RAS_syndrome
    - ggambetta 7y ago
      Yep :) Didn't know it was called that.
    - benj111 7y ago
      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 7y ago
        I think you are looking for: https://en.wikipedia.org/wiki/Autological_word https://en.wikipedia.org/wiki/Autological_word
        benj111 7y ago
        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
buro9 7y 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/ 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 7y 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.
  - buro9 7y 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.
    - mcny 7y ago
      I thought with https, the ISP (or anyone in between) only sees the base url and not params?
pidg 7y 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.
- throwawaylolx 7y ago
  To use this news to belittle their competition about a hypothetical event seems like a dangerous form of kool-aid fanboyism.
  - wrboyce 7y ago
    I think we can safely applaud Monzo for their transparency in stark contrast to the opaque nature of "traditional" banks.
  - McDev 7y ago
    >about a hypothetical event Not entirely: https://www.bbc.co.uk/news/business-44121901 https://www.bbc.co.uk/news/business-44121901 https://www.theguardian.com/business/2018/apr/28/warning-signs-for-tsbs-it-meltdown-were-clear-a-year-ago-insider https://www.theguardian.com/business/2018/apr/28/warning-sig...
- peteretep 7y ago
  Barclays have surprised me with how good their tech seems to be
  - Iolaum 7y 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.
Daniel_sk 7y 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 :-).

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-of-millions-of-user-passwords-in-plain-text-for-years/ https://krebsonsecurity.com/2019/03/facebook-stored-hundreds... [2] https://www.theverge.com/2019/5/21/18634842/google-passwords-plain-text-g-suite-fourteen-years https://www.theverge.com/2019/5/21/18634842/google-passwords...

throwawaylolx 7y 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 7y 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 7y 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 7y ago
  PINS for the ATM are but my online banking has a number more
- repolfx 7y 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 7y 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.

ggambetta 7y ago

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

rys 7y 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.
- wrboyce 7y 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 https://en.wikipedia.org/wiki/RAS_syndrome
  - ggambetta 7y ago
    Yep :) Didn't know it was called that.
  - benj111 7y ago
    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 7y ago
      I think you are looking for: https://en.wikipedia.org/wiki/Autological_word https://en.wikipedia.org/wiki/Autological_word
      - benj111 7y ago
        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

buro9 7y 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/ 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 7y 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.
- buro9 7y 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.
  - mcny 7y ago
    I thought with https, the ISP (or anyone in between) only sees the base url and not params?

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

throwawaylolx 7y ago
To use this news to belittle their competition about a hypothetical event seems like a dangerous form of kool-aid fanboyism.
- wrboyce 7y ago
  I think we can safely applaud Monzo for their transparency in stark contrast to the opaque nature of "traditional" banks.
- McDev 7y ago
  >about a hypothetical event Not entirely: https://www.bbc.co.uk/news/business-44121901 https://www.bbc.co.uk/news/business-44121901 https://www.theguardian.com/business/2018/apr/28/warning-signs-for-tsbs-it-meltdown-were-clear-a-year-ago-insider https://www.theguardian.com/business/2018/apr/28/warning-sig...
peteretep 7y ago
Barclays have surprised me with how good their tech seems to be
- Iolaum 7y 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.

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