The one time password (OTP) has been a pillar of modern Indian banking. To prevent fraud, the RBI requires Indian banks to implement two-factor authentication (2FA) technology, as a condition to offer internet banking services to the masses.
The basic idea is that customers can protect their accounts with something they know (passwords) and something they have (their mobile phone, which receives the OTP generated at the time of a transaction). Many banks require an additional transaction password before money leaves the customer’s account.
At its core, leveraging the OTP as it is currently implemented, is an excellent security protocol. A hacker could potentially get into a customer’s internet session or release a key-logging virus into the customer’s computer to record keystrokes of a password as they are typed in. But because the OTP is one-time and is sent as a separate SMS, the thief would also have to hack into the service-provider's network at the exact same time — a near impossibility.
But there are several operational issues with the OTP not related to security.
As internet and mobile banking rapidly advance in the country, the telecommunications infrastructure is coming under heavy loads during peak times of the day. OTP servers in banking data centres, which generate these codes, are sometimes overwhelmed by demand and fail to respond promptly.
This is why some banks, like SBI, provide an option to request a second OTP, whereas others, like Canara Bank and Indian Overseas Bank, do not. If the OTP is not received within the session window permitted — more than three minutes of inactivity generally shuts down a banking session — the entire transaction has to be redone; a frustrating prospect for the consumer and an inefficient outcome for the banks.
Recognising that the OTP is such a critical link in the transaction cycle, leading banks are looking at other ways to communicate the code to the customer within the limits imposed by the session window.
Cutting out the SMS
Borrowing from Google’s authenticator technology, SBI recently launched the SBI Secure OTP, which cuts out the SMS method altogether. A user launches the Secure OTP app on his smartphone by keying in a mobile PIN. When he/she requests an OTP on the banking page, the user has the option of choosing one of two methods — an online request or an offline request.
With the former, the app generates an OTP through tunnelled communication with the SBI server via the internet. With the latter, the banking page displays a random number, which the user keys into the app. The app instantly returns an OTP, which the user then enters into the web page.
SBI deserves kudos for rolling out this technology, although there are questions about backup options. What happens if the app fails or if the smartphone doesn’t work? What about customers who do not have smartphones?
Karnataka Bank, one of the best run private banks in the country, has had an excellent backup option for years. At the same time the OTP is sent out, a duplicate message is sent to the customer’s email account in a password protected PDF file. The hacker would have to know the customer’s email login credentials and the .pdf password (generally, the customer’s date of birth) to open this file. This can only happen if the customer’s computer is completely compromised — an unlikely occurrence.
IOB, among the least technologically sophisticated banks, has a crude backup when the SMS-based OTP fails to generate in time. During 12 attempts last week, the bank sent me OTPs each time after the 180-second session window, rendering the entire transaction useless.
The bank instructs customers that if an OTP is not received within 30 seconds, they need to call a Mumbai number from their registered mobile device and receive OTPs through an interactive voice response system. The backup option did not work well either.
Banks can come up with innovative solutions by borrowing from technology giants like Google, which allows users to print a set of 10 two-step passwords, which can be used if the authenticator app fails. And each two-step password can be used only once. When a new set is generated, any unused passwords in the old set are automatically retired.
Using this protocol, banks could generate a set of, say 25, OTPs and print them on the customer’s monthly bank statement. A new set would become active for a new month. Since bank statements are sent to email addresses and the files always require another password to open, these become a safe way to communicate OTPs.
Or, banks could have customers print a set of 25 OTPs at an ATM. If the customer loses a set, he can always return to the ATM to generate a new set, which automatically nullifies the old one. Because OTP generation is through the customer’s ATM card, the card replaces the phone in the “something the customer has” category.
It does not matter which solution is selected. The objective of the banks should be to retire the OTP/SMS platform soon — the sooner, the better.