Banking applications, please listen to your security experts!

Honestly, I have had it with Banking applications and their God awful "security" measures. Its almost as if they want malicious actors to get access to their customer's accounts. And its not just any one bank in particular, I have seen the same thing over and over again with multiple ones, at least those in India. I can't comment on other international banks but I have a hunch they would be pretty much the same.

Now, where should I start. How about something that not only banks but even big name tech companies are guilty of.

Expiring passwords

Microsoft released a lengthy explainer on why password expiration is a bad practice (scroll down a bit in the link). In short:

1. When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords.
2. Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.
3. What should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration?

The above points are directly copies from the linked article. I suggest everyone to have a read through that. Password expiry is an archaic practice that I have no idea why anyone came up with. It gives a false sense of security to the organizations and causes unnecessary friction to the end users. Just STOP.

Disabling right click/context menu

Me: Okayyyyy, so I have an extremely complex password that has been generated by Hardware Random Number Generator which is stored in an encrypted vault that I need biometric access to and I will copy the password since there is no way to remember it and paste it onto the password fie...

Banking Portal: NOOO! You can't go around pasting text into the password field. What if, what if a hacker ummm does something. Yeah, like uh, copy your password from this field, yeahh, that's it!

Me: But I have already copied it onto my clipboard. If someone is sniffing my clipboard, then its already gone and its my fault for not protecting my system. Moreover, why disable pastes? What will a "hacker" do by pasting on behalf of me?

Banking Portal: Rrreeeeee...

Thankfully, the above is not a conversation I had to have in my real life. Why on earth would anyone disable context menus in the login forms is beyond me. What kind of attack surface are they trying to protect? Is it worth it to prevent a user from using a complex password and use "Name@123". Is the attack surface caused by bad passwords better smaller than the one being protected by the above. I am lost on this. I dare not even google it up. If anyone has any insights, please tweet me...

Sending OTP over SMS

When this one is looked in conjunction with the others, it makes the whole thing a criminal negligence. Sending OTPs over SMS is an extremely insecure practice. Full Stop. You might have all the security in the world, but if the OTP is jacked (and there are ways it can be), you will instantly lose access to your account. I am yet to see a single bank implementing any reliable 2FA of any sorts. Organisations need to realise how insecure this method is and stop implementing on new projects. Especially for such security critical tasks.

Frequent session expiration

Ok, so this one is not the fault of the banks. And it might be a bit controlversial one too. This is because the above is because of a certain requirement of PCI DSS (Payment Card Industry Data Security Standard). Reqquirement 8.1.8 states that:

If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Now, I get, I get. The intention of this requirement is to ensure that someone else isn't able to access the account from the same system when the user walks away. It even mentioned in the above doc:

When users walk away from an open machine with access to critical system components or cardholder data, that machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse.

Isn't there a discrepancy between the intention and the implementation. The intention is surely when the user "walks away" or isn't in front of the system. So, why does the session still time out when I am looking at my bank balance and dwelling in my pain. Should switching to a different tab be considered "walking away"? Should banks start monitoring users via a webcam to see if the user is "walking away"? In my opinion, this is a poorly worded and an even poorly implemented requirement. Cause the only way to keep the session running would be click something (which I guess sends a request to the backend which refreshes the stay alive lifetime) or click on the annoying popup which asks me if I am there 1 minute before the session expires. Here is a better (allegedly in my head) idea that I cooked up in a couple of seconds. How about sending a stay alive pulse on mouse movement. That won't solve my staring into my transactions while I reconsider my life choices but should provide a much better experience to most other users. All in all, this needs better implementation and I wish OS developers and web developers came together to find a better way to implement this.

All in all, these are some of the great UX problems in banking applications that they just pander around as "security features". They are not! I am pretty sure that this is just the tip of the iceberg as there is a vast ocean of banking applications that I certainly haven't used. Let me know via a tweet if you have faced something similar or anything new.