Few years ago my friend had an account in a bank that gave him security token, that generated a random number every 60 seconds, that had to be appended to password during login. So even if someone sniffed your password, it would be valid only for less than a minute :).
I think it's a great solution and I don't understand why it's not widely used.
Because they are hellaciously expensive, in terms of:
* 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
Banks are moving to multifactor auth systems. Expense is slowing the process down. Buy me a beer next time I'm in San Francisco and I'll give you anecdotal details I can't give here.
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.
Switch to a credit union, then. If your profile info is accurate, you live in a region served by the SF Fire Credit Union (http://www.sffirecu.org/). I switched to them a few years ago and it's been a great experience. Save yourself that $144 a year.
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.)
Make it an optional smartphone app, like Google's two-factor auth. Maybe let people buy a token like Mt.Gox does (they are hardly huge, and they could afford it...name.com and World of Warcraft too.)
You know what was expensive? The bank bailout. I want my $8,333 that I'm paying to keep banks open back.
Short answer from my experience is cost. The individual tokens have a cost, then there's the management overheads of running the system. Initially it doesn't seem like too much but if you've got a customer base numbering in the millions, it can get quite pricey.
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.
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".
That's not an inherent flaw in the idea, though, just in RSA's implementation. There's no real need for the servers to hold on to private device-specific data.
This is a horrible solution. I don't care what security experts say about two-factor authentication. I'm not about to start stuffing my pockets with a pile of security tokens. I have more than enough keys on my keychain, thank you. Unless everyone can agree to use the same physical token, I simply refuse to use a service that makes me carry an extra piece of junk with me all the time.
Although slightly ahead of its time for the masses there are implementations which do not require you to carry another device. You can use your telephone and be provided with your second factor via voice, sms or application running on your smartphone.
It's a particularly horrible solution when your bank decides to replace their existing clever nigh-impossible-to-sniff multi-factor authentication system with a little dongle sent to your home address whist you overseas. Specifically, I need it to pay off my credit card bill with the same bank; I can still log in and shift money between savings accounts at will.
Ah, but I can still pay my bill by telephone and all I need is to dial in the card number when prompted...
The only problem with this, is that it requires everyone to trust a single third party with the authentication. Since the input space that you type in is small, any one-way encryption is easily reversible. This means for every site that the code is good for, you would need to reveal a means to generate the code, rendering it the password problem all over again.
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.
Lastpass is awesome and even with google authenticator if you do not have your phone with you they give you the option of printing out like 30 one-off codes in case of situations where your phone is dead or missing.
That's a problem with cell-phone providers who overcharge for SMS. An SMS is almost free nowadays, in some cases it actually is free since it goes over channels that would otherwise go unused. SMS seems like a good, cheap, ubiquitous solution for most of the developed world.
From horrible providers, yes. The big three legacy operators in Canada charge 15 or 20 cents per unless you're specifically on a plan that includes a larger allowance.
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.
It depends on your contract. In general, by default, you pay a bit for every text (10 cents maybe?). But you have the option of paying a flat rate for unlimited texting, which is generally something like $10/month. Most people I know choose that option.
Let me ask again the parents question for clarification. Do people really pay for the received sms-es? It sounds like total bullshit, because you don't have an option not to receive sms from a person, like you have with calls.
Absolutely (in the US here). Some carriers will allow you to block all text messages, which can get rid of the annoying ones you wouldn't want to accept, but also forces legitimate ones to get eaten - causing some people to think you're ignoring them when you actually had no idea they even tried texting you in the first place.
Less than a minute is also short enough that the bank can simply deny a second login attempt during that time without causing any inconvenience to you.
Absolutely. i got your TCP segment with data on your WIFi, and sent a TCP RST from a location with the lower overall latency - so both your SSL connection got reset.
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 bad solution. As well as password lists. Because it doesn't verify sum or target of the money transfer. Money can be transferred to anywhere when you give the confirmation code.
My bank requires both my pin (numeric) and password to log into my account, and SMS's me when I login. If I need to transfer money to anybody outside of my usual payment recipients it SMS's me a token that I have to enter.
That's not failsafe but it raises the bar quite a bit above 'enter password to own everything'. Also, no extra hardware required.
I have two accounts with security tokens. In one case they charged me $20 for the token, in the other case they gave it to me for free with the account.
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.
If the description of password+number is accurate, then it's a poor solution because it means your password is sent to the bank as opposed to being hashed and the hash being sent to the bank.
This comes up every time passwords are discussed, and it's a bad idea. A password sent over a secure channel is fine. A hashed password sent over a secure channel is generally fine, though more complicated. A password sent over an unsecured channel is not fine. Neither is a hashed password sent over an unsecured channel.
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.
This is common practice. Our password forms all over the internet send the password just as part of a normal request. We rely on SSL to protect that data as it goes over the wire and then there are all sorts of ways that it might be stored in plain text somewhere on the servers.
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.
It is widely used. At least in several parts of Europe I've been to and/or lived.
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.
I think it's a great solution and I don't understand why it's not widely used.