Seems like they dealt with this as quickly as possible with a sensible explanation of the issue and why it happened. So many companies struggle with logfiles and sensitive information unfortunately.
It's disheartening to see the replies in their forum [1] from some users unwilling to accept the explanation.
From the sounds of it, Monzo was/is using customer (card) PINs as a security passcode within their app itself. Hence on 2 operations in the app (cancelling a standing order, and getting a reminder of your card number), it was being logged due to a misconfiguration.
I was of the understanding that it was accepted best practice for a bank to never use the user's card PIN anywhere except card authentication, for this very reason (and even then, to handle it particularly carefully).
It seems that treating the PIN as a general authentication factor within the app might well be convenient for users (only 1 PIN to remember), but then this exposes their card PIN as seen here (which is used to prove you authorized a transaction yourself). The notion the PIN itself was stored in a secure part of the system to "control which staff members could access them" is at odds with how banks used to handle PINs - which is that no staff can see them, and they're held in hardware security modules, which validate encrypted incoming PINs and say "yes" or "no".
Some "old banks" have some pretty elegant (albeit clunky) web login systems, all so they can do low entropy challenge-response authentication backed by a HSM, so user secrets are not stored in the plain, or transmitted in a way they could be recovered without access to the HSM (think HSM issuing a session-based challenge and mixing in the response to that challenge via hashing, then sending the hashed response back for yes/no checking by the HSM).
A push for good user experience (less secrets to remember) gone too far? Or a lack of focus on the layered security approach taken by banks?
2 comments
[ 0.22 ms ] story [ 15.4 ms ] threadIt's disheartening to see the replies in their forum [1] from some users unwilling to accept the explanation.
[1] https://community.monzo.com/t/we-ve-fixed-an-issue-that-mean...
I was of the understanding that it was accepted best practice for a bank to never use the user's card PIN anywhere except card authentication, for this very reason (and even then, to handle it particularly carefully).
It seems that treating the PIN as a general authentication factor within the app might well be convenient for users (only 1 PIN to remember), but then this exposes their card PIN as seen here (which is used to prove you authorized a transaction yourself). The notion the PIN itself was stored in a secure part of the system to "control which staff members could access them" is at odds with how banks used to handle PINs - which is that no staff can see them, and they're held in hardware security modules, which validate encrypted incoming PINs and say "yes" or "no".
Some "old banks" have some pretty elegant (albeit clunky) web login systems, all so they can do low entropy challenge-response authentication backed by a HSM, so user secrets are not stored in the plain, or transmitted in a way they could be recovered without access to the HSM (think HSM issuing a session-based challenge and mixing in the response to that challenge via hashing, then sending the hashed response back for yes/no checking by the HSM).
A push for good user experience (less secrets to remember) gone too far? Or a lack of focus on the layered security approach taken by banks?