One-time passwords for e-banking

| Comments (6) | COMSEC
As I've mentioned previously, simple password systems suffer from a variety of capture and replay attacks. All the best solutions involve cryptographic authentication but this involves changing both client and server, which is a pain (the client is the real problem). One of the early approaches to this problem was to give the users physical cryptographic tokens which they could use to generate a supplemental password. This had the big advantage that it could be deployed without changing the user's client software.

The most succesful of these tokens was the SecurID card (now part of RSA). A SecurID is a card with an LCD display that generates a new "random" value every 30 seconds. The server side is synchronized to the token and so can verify the token value. I mention this because VeriSign is introducing a credit card with a similar technology, aimed at login for e-banking.

Rosch explained that, at this point anyway, the cards would not be geared toward online retailers, like Instead, they're aiming the concept at businesses and consumers who set up online accounts, like banks, brokerages and PayPal.

The cards would hold an algorithm that could generate the six-digit passwords, which are only good for 30 seconds.

When a consumer wanted to log onto her online banking account, for instance, she would log on with her user name and password, as usual. Then the site would ask for her secondary password. She would press a button on her credit card and the numerical password would flash up on the LCD screen. The next time, she needed to log into her account, her card would give her a different number, which the site would match up with the card's unique serial number, which corresponds to the algorithm it uses.


Rosch added that even if a key logger planted surreptitiously on the user's computer picked up that second password, a hacker wouldn't be able to use it because subsequent transactions would require a different password.

This certainly seems reasonable as a phishing countermeasure. Web login and telnet are similar in a number of respects—in particular in the desire to avoid touching the client. It shouldn't be too hard to train users to type in the password from the LCD, given that it's going to appear more or less next to the credit card number. My main concerns would be the cost and durability of the cards. Durability is especially an issue. I have no particular information about durability of the ICT cards, but a card with electronics and an LCD, plus a magstripe seems likely to fail more often than just a magstripe. Even if the cards can be made as cheap as mag stripe cards, if they break a lot that means a lot of calls to customer service to get new cards, and customer service calls are expensive.

I note that they don't seem to be targeting this towards online retailers. That's not surprising since getting that right seems a lot harder. Online retail is a substantially less close fit for the password login model. In particular, merchants want to be able to both batch transactions and retain the credit card numbers for future transactions (think Amazon one-click). Obviously either of these is inconsistent with at least naive implementations of very short-term authenticators. This isn't to say it's not possible to make something along these lines work for credit cards, just that it's more complicated.


Doesn't seem like that great of an anti-phishing measure to me. It might eliminate some forms of phishing, but the phish could just implement a mitm attack and pass through the number you enter when you click on the fake email. Presumably, once you login to a session, you get some session token so you don't have to keep re-authing every 30 seconds -- that auth token might time out at some point, but likely on the order of minutes, and probably the timeout is extended any time you "fetch" a new page. A minimally cleverly written phish could get everything it needed from that one open session.

PS btw you seem to be collecting spam links in your old articles' comments.

OTP authentication systems have already been broken for online banking by just such a MITM attack - ABN Ambro fell victim earlier this year and there have been other successful phishing attacks against such systems in the past. However it does makes such attacks substantially harder and is pretty effective if combined with SSL authentication of the server and increased user awareness.

One thing that surprises me is that retail banking has not yet managed to acquire a TLD with strong oversight. (e.g. like but for banks ) It only helps a subset of problems but its another layer. And layers are good.

Online retail is a different issue. What we need to be doing there is to move away from architectures that require the consumer to hand over any significant data relating to their financial instruments at all. Giving a retailer CC details that can then be directly used with no further oversight for any amount is madness if you think about it. Single use credit card numbers are a very viable option for most online retail situations - and become even more attractive as the trustworthiness of the retailer decreases.
It seems (to me at any rate) far more logical to focus on improving the authentication process for my banking system and then to use that to acquire a single use token (ie a one time CC number limited by date and value) that I coult then give to the retailer. Solutions like Orbiscom's O-Card were a reasonable first stab at this but the time is ripe for a totally online reworking of that idea. The three main areas where one time CC's introduce problems are models like Amazon's One-click, cases where cards are pre-authorized for one value and "fine tuned" later with an exact amount and cases where the card eventually has to be physically presented.

Citibank has a very nice, easy, convenient one-time CCN system for online transactions.

When the host the user is connecting from has been compromised it gets quite complicated to stop an attack, even if a one time password of some kind is used.

I have heard of (but not seen myself yet) malware that uses browser helper objects to simply rewrite the request to change the sums and target accounts, letting the user authenticate the transaction. Stopping this kind of attacks would be hard, with the current technology.

I wonder how long time it will take before banks routinely uses SMS or other out of band communication to authenticate transactions. Or at least uses a security token that requires that you enter account and sum before generating an authentication code dependent on those as well as the time.

The fine tuning model does allow some variation with "one use" cards. Having run an authentication scheme at an online retailer, validation checks (an authorization on the card for $1) are not counted as a "use" of the temporary card number, as it is assumed to be a validation check. (This may change with new card rules for unattended gas pumps which no longer require a significant pre-authorization amount for the purchase, but do impose a limit on the total purchase amount). The associations have also expanded merchant categories that are allowed to "edit" the final amount for tips et al.

But basically, this is a high end use scenario. The card issuers have basically ceded low volume fraud to the marketplace with no signature required ceilings and full refund on claim (above the Reg Z requirement) and are not going to roll out expensive technology for most consumers' use when they are trying to minimize cost and delay to themselves and retailers on the bottom end of the purchase spectrum.

I'm still waiting (ever so patiently) for the card reader on every computer to stop online fraud, and that would have been a lower cost solution.

Leave a comment