Online banking’s dirty little two-factor secret

Posted  April 8, 2008 By Steve

Lots of people use online financial websites of one sort of another, from online bill-pay to brokerage accounts and more. Some sites, like E*Trade, offer you the option to pay for two-factor authentication tokens. E*Trade’s is about $50 a year, and comes in the form of an RSA SecurID token. I have it and use it, and aside from the many annoyances associated with tokens, it does its job.

I noticed after I started using it that there are a couple of really major holes in the implementation. First off, the token isn’t required for telephone access. The phone menu prompts you for the very same password you use on the website, but doesn’t require the second factor at all. I guess the theory is that crooks are less likely to think of abusing the phone system?

But wait, it gets worse. I’m also an avid user of Quicken, and I have it configured to download new transactions from all of my bank accounts. Sure enough, it logs into E*Trade and requests my balances, portfolio, transactions, and so on, without using two-factor. I don’t know what other functionality is exposed through that API, but in any case, that looks like a pretty considerable implementation bug to me.

The problem isn’t really E*Trade’s fault; they have no (good) way of requiring every client out there to update its user interface. The only interface they control is the website— as soon as you publish an API that can be accessed remotely, you lose control of the UI. E*Trade has no way of going back to Quicken 2007 and making it prompt for a token, and even if they could, that kind of thing would render useless the PIN Vault that is supposed to store all of your passwords.

This is the kind of environment where PhoneFactor can make a difference. Whereas most other two-factor systems require some change to the user interface (or some nontrivial training on how to use the existing UI differently), PhoneFactor generally doesn’t. PhoneFactor authentication is out-of-band, and is triggered by the server side, not by the client. Because of that, application software like Quicken generally doesn’t need any modification to work well with PhoneFactor.

Remember, crooks are lazy – if you make one attack too difficult, like going in through the front door, they’ll find another easier way, like going in through the API the way Quicken does. For security to be effective, you have to guard all the doors.

-Steve