In the old days where DevOps was not a thing we usually had split responsibilities. Developers developed some code utilizing some synthetic data to test their hot stuff and if they saw it was good they gave that code as a (compiled) release to the operations team who deployed it in production. That means the developer could not just attach a debugger to the running process and see the password of the user. But a malicious developer could still add some code to send the received password to an external server of the developers choosing.
The only thing that would prevent this is to have more eyes on the code when it is pushed into production. For example, the operations team makes sure that at least two developers have signed off on the release they have to deploy which implies that there was a code review by a second developer. Note that we're operating under the assumption that collusion between multiple malicious developers is too risky for the developer.
Nowadays DevOps along with continuous integration is the hot new thing. Let's say we have an integration pipeline and only a subset of all developers have the system permissions to set it up. We would also require that the code repository have a non-rewritable history (allowing git rebase is a bad idea) in order to prevent a single developer of pushing malicious code and hiding the fact that they did. If you host your code repository yourself then a different subset of developers should operate the server it is hosting on. If auditability of the code is not enough you can even set up your continuous integration pipeline in such a way that two developers have to sign off on a release.
The controls I mentioned is only the tip of the ice berg. There are other things to consider:
- Inherently, you need to trust your administrators but you can verify by doing background checks when hiring new personnel and regularly afterwards (people change).
- Since this is about banking you likely have some compliance requirements for your jurisdiction. Those requirements might prescribe some useful security controls.
- You can have an independent team that is only there to check the audit logs that everybody (or a random sample) is a good citizen and is behaving according to agreed upon processes.
- Don't make it possible for your developers or other operators (bank staff) to impersonate end users in the backend without proper audit logging about who initiated the impersonation.
- Protect your audit logs in the same way by making them unchangeable by developers or other highly privileged personnel.
- Require two-factor authentication for your end users so that a developer who somehow looked into the production database and saw the user's password has to make changes to the system in order to exploit this password.
- Store only hashed passwords (scrypt or similar) and constant-time compare the hashes during login.
- If the password is simple and you're not requiring 2FA a developer might be able to crack it offline using hashcat or similar. So require some sensible complexity rules for the password of the end user.
