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 of the banks use SRP-like setups for app-based credentials - I've seen some clever symmetric hash-based implementations of a challenge response protocol that can be backed by a HSM - low entropy credential info (3 characters from a password) is hashed together with a session salt (presumably) generated by the HSM, and the hash is sent to the HSM, which can say "yes" or "no".
For debit card PINs, the bank needs the ability to verify the PIN, for ATM or magnetic stripe online authentication transactions I believe, but this could again be handled by HSM. Not sure why they were using card PINs as a generic password, and storing them at all retrievably by staff. I wonder if this is complaint with best practice in banking?
