I think it's a great solution and I don't understand why it's not widely used.
* cost to retrofit the backend of these systems onto the bank's retail software
* cost to roll out tokens to customers
* ongoing support costs for e.g. lost or broken tokens
To all that, you have to layer on the fact that tokens are priced for a different market (enterprise security), so the existing products aren't packaged in a way that makes them palatable to (say) Bank of America's many tens of millions of customers. You can't wave a magic wand on that problem either; tokens are packaged the way they are now because that's how you can keep a token company in the black.
You know, I have a checking account that I don't keep a lot of money in (because I rarely write checks nowadays) but have had so long that I don't really want to close it. I was surprised to notice last week that the bank is charging me $12/month in account fees unless I keep a minimum of $1000 in it at all times (effectively, an interest-free loan to the bank). For $144 a year, I think they can afford an RSA token or something better than the existing nonsense.
I know, the bank makes money from fees and that's the price I pay for access to a large ATM network..yet I distinctly remember a time when they made money from lending, while still managing to have a risk management policy grumble grumble
I think one obvious (but HN-unfriendly) point to be made here is that the overwhelming vast majority of bank customers could give a shit about online authentication systems.
They have the largest ATM network on the planet; every ATM is free-of-charge. (That is, they'll refund the fees, if the ATM charges any.)
You know what was expensive? The bank bailout. I want my $8,333 that I'm paying to keep banks open back.
The question was asked, why don't more banks use tokens? I provided an answer. That's all.
Obviously if the cost (to the bank) of online fraud gets high enough it starts to make more sense. What's interesting is that some online apps (eg, World of Warcraft) have seen the benefits of providing 2-factor authentication faster than a lot of Financial Services companies.
2-factor auth of one kind or another seems to me to be a good idea for online banking, given the prevalence of banking trojans which have keylogging functionality.
Those without smartphones could fall back to fobs or more "traditional" forms of auth.
Question: what is a good/trusted one-time key generator for Android and/or iPhone?
It implements an open standard for OTP and they provide source for a PAM module to require the OTP on the computer side.
RSA, one provider of such tokens, was hacked making many of those devices worthless.
RSA was hacked because someone in Personnel opened an attachment supposedly from a recruitment agency.
(http://www.pcmag.com/article2/0,2817,2391951,00.asp)
Very frustrating that the expert people supplying the extra security for the people wanting extra security are the people falling for stupid stunts like "include an infected Excel file, and hope someone opens it".
Being forced to pay a small fee (by your phone-service provider) to log in isn't much better, I think.
It's easy to negotiate to get them for free when you have any amount of leverage on the provider, but out of the box you pay.
Ah, but I can still pay my bill by telephone and all I need is to dial in the card number when prompted...
For example: http://googleblog.blogspot.com/2011/02/advanced-sign-in-secu...
Alternatively, the key-fob could have an arrow to select which site to show the key for, but that would be cumbersome. Personally, I think that a solution similar to the ssh one would be best in that you have some sort of pass phrase that you type into your browser, and it unlocks a private key that can prove your credentials on web sites.
While you hit "reload", I establish the connection and login.
Your attempt is the second login attempt. As you propose, it's denied.
Your next steps, while I am changing your contact email and other info ?
That's not failsafe but it raises the bar quite a bit above 'enter password to own everything'. Also, no extra hardware required.
It's mildly annoying in that you need to take the token with you if you want to have banking at your fingertips, but then it does mean you're extremely unlikely to be hacked.
They could just, in RAM, take off the last 6 characters of the password they got and treat those as the token with the rest being the password itself. At this point it's not much different from passing them separately.
The main point of the original rant was that we have a solution that doesn't require this, but it's not used for any websites.
Hashing the password before transmission gains you basically nothing. Hashing on the client side simply means that your hashed password becomes the effective password. Anyone who could theoretically sniff the password could also sniff the hashed password and perform the same kind of impersonation or man-in-the-middle attacks. You're introducing a bunch of complexity (and breaking compatibility with clients that don't, e.g., support Javascript), and you're getting nothing useful in return. And yes, you could implement some kind of challenge-response and basically try to reimplement a secure handshake and auth, but you'll probably get it wrong because security implementations by laypeople are generally quite broken, and at the end of the day, you should just turn on SSL and do it the way that works.
With some variations such security measures are ubiquitous here. SMS tokens, an electronic device that generates numbers. A card full of numbers of which a couple of them are asked before each transaction, etc.