Schneier on Security
A blog covering security and security technology.
« Friday Squid Blogging: Squid in Parking Spot |
| Interesting Bioterrorism Drill »
November 27, 2006
Fighting Fraudulent Transactions
Last March I wrote that two-factor authentication isn't going to reduce financial fraud or identity theft, that all it will do is force the criminals to change their tactics:
Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses.
Here are two new active attacks we're starting to see:
- Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.
- Trojan attack. Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.
See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.
The solution is not to better authenticate the person, but to authenticate the transaction. (Think credit cards. No one checks your signature. They really don't care if you're you. They maintain security by authenticating the transactions.)
Of course, no one listens to me. U.S. regulators required banks to implement two-factor authentication by the end of this year. But customers are rebelling, and banks are scrambling to figure out something -- anything -- else. And, amazingly enough and purely by accident it seems, they've stumbled on security solutions that actually work:
Instead, to comply with new banking regulations and stem phishing losses, banks and the vendors who serve them are hurriedly putting together multipronged strategies that they say amount to "strong" authentication. The emerging approach generally consists of somehow recognizing a customer's computer, asking additional challenge questions for risky behavior and putting in place back-end fraud detection.
Despite the FFIEC guidance about authentication, the emerging technologies that actually seem to hold the most promise for protecting the funds in consumer banking accounts aren't authentication systems at all. They're back-end systems that monitor for suspicious behavior.
Some of these tools are rule-based: If a customer from Nebraska signs on from, say, Romania, the bank can determine that the log-on always be considered suspect. Others are based on a risk score: That log-on from Romania would add points to a risk score, and when the score reaches a certain threshold, the bank takes action.
Flagged transactions can get bumped to second-factor authentication -- usually, a call on the telephone, something the user has. This has long been done manually in the credit card world. Just think about the last phone call you got from your credit card company's fraud department when you (or someone else) tried to make a large purchase with your credit card in Europe. Some banks, including Washington Mutual, are in the process of automating out-of-band phone calls for risky online transactions.
Exactly. That's how you do it.
EDITED TO ADD (12/6): Another example.
Posted on November 27, 2006 at 6:07 AM
• 55 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
External tokens for authentication are commonplace in Europe and widely accepted, yet there is much concern in legal circles about the integrity of the hardware software combination used. The introduction of the digital signature has been thwarted or delayed because of this issue. From a legal point of view, it suffices to have a man-in-the-middle Trojan on your PC for your Bank to successfully deny liability in a fraudulent financial transaction.
More on this in the German language publication:
"Internet-Recht und Digitale Signaturen." by Oliver Arter or see:
I called my bank about six years back.
On the "There's a problem with your card-number/password, please call us" webpage, the telephone number to call for info wasn't the usual phone-in-your-bank-transaction telephone number.
I had to go through three of the so-called 'managers', explaining what a Man-in-the-Middle attack was, and how this situation was ripe for one, before one of them told me that they'd take it up at the nest staff meeting.
No matter what the situation is, always tell your customers to call the same telephone number. And keep repeating this to your customers over and over, until it becomes a mantra.
This is good news.
Remember that two factor authentication is useless if both are sent over the same same channel.
With the phone call, the banks are finally implementing two factor, two channel authentication. And since they already have your phone number and most of them have the automated dialing systems ...
So unless the phishers can somehow alter your bank record to change the phone number ...
And I'd look for that to be the next attack. If you can change your phone number via the 'web, it is possible for the phishers (with more effort) to compromise this by altering the phone number prior to the transaction.
The simple solution is for the banks to refuse phone number changes over the 'web. We'll see how this progresses.
This is what real security is about, amazing that it developed spontaneously. My bank deployed this early this year and it is seemless from your home computer, but a bit more difficult from others.
You want a layered defense, with some sort of intelligent, adaptive filtering. I wonder if we could generate something that would create a score based on behavior and other factors for TSA.
And yes, any one method can be defeated by some sort of trojan or MITM, but automated attacks like that will leave a signature that the behavioral filter can detect. The article also talks about those wanting even MORE security can opt for tokens or other methods
See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part.
I would contend that such schemes are *not* 2-factor, they're multiple single factor. There's a difference.
A *real* 2-factor scheme would require banks to maintain a customer PKI and issue smartcards, but they want to do it on the cheap.
This doesn't obviate transaction security, of course.
It's not so much about banks wanting to do it on the cheap, but customers who don't want a smart card for every bank they may do business with. Screw that. That has never been a real solution, and only works in small, closed groups.
One advantage the credit card industry has over the banks is the ability to pass on costs to merchants. Credit card transactions are typically authenticated after the fact, which has allowed credit card fraud to continue to flourish. The CC issuers may suspend an account after a number of suspicious transactions, but in cases where the CC issuer did not catch the fraud, they are able to issue chargebacks to merchants and then impose a chargeback fee on top to mitigate any unrecoverable losses. It's hard to say how effective the transaction authentication is when there is scant data on how much merchants all over the world are collectively paying to make possible the $50 limit on fraud liability. The banks do not have this luxury and will have to do considerably better than the CC issuers.
"Exactly. That's how you do it." Is it? Perhaps, but it also holds a risk. If the Romanian bad guy uses a compromised computer to access the bank that is near to where the true client lives (e.g. simply in the US), the bank may flag the transaction wrongly and thus lower its guard and eventually putting even more burden on the shoulders of the client to prove the fraudulent nature of the transaction.
Both at log in and when executing a transaction banks should ask a customer a question that only they can answer, and which is different each time. This is how my Dutch and Italian banks do it, but for Anglo-Saxon banks this principle which involves issuing a small piece of hardware is apparently too expensive.
The problem with that kind of system is what steps banks are going to take when the risk score of a transaction is too high. Banks will want to implement an automatic system instead of a manual check. This will probably lead to people on hollyday in Romania not getting any money because the risk-assessment system automatically locked them out of their bank account.
"'Exactly. That's how you do it.' Is it? Perhaps, but it also holds a risk."
Of course. Everything holds a risk. Welcome to life.
The trick is to minimize the risk to the point where accepting it is a reasonable business model
Actually, what is called two-factor authentication nowadays really isn't two-factor at all. If I have a token which generates a one-time password for me or the one-time password is delivered via a second channel, then this is still a knowledge-based authentication. So username, password, PIN/TAN, one-time password, smart tokens, etc. are all knowledge based authentication and thus not two-factor. Any attacker can authenticate as the victim if he gets to know the one-time password.
Two factor should mean one knowledge-based factor and a factor based on physical possession. A smart card based authentication (no matter whether it's the session or the transaction) is much harder to break or replay. Of course, there is still the weak point between the smart card and the human interface (e.g. between the smard card reader and the online banking portal in the browser window). Any trojan can still hack in there and modify the transaction before it is signed.
As usual, security can not be reached by technological means only!
The Royal Bank of Canada started to do the authentication question earlier this year. Now when I bank from any place other than my computer at home I get one of three potential questions back.
Now, I don't know how accurate you have to be (exact wording, etc..) but it seems to work.
I feel a bit more comfortable banking on-line now.
"Of course. Everything holds a risk. Welcome to life."
Sure, but as I and some others have pointed out your way of doing it at least warrants some discussion about the true efficacy of the measure. That's what I was pointing at. I guess you'll agree.
My credit union recently changed the online authentication system to include, among other measures, the computer generated text-as-image of a phrase the account holder previously created. In this way, the website is authenticating to the user in addition to the new steps to authenticate the user to the website.
If the attackers are adapting, with even more sophisticated trojans, then its a very simple matter for any of these trojans on the infected machine to include a proxy server so access to the bank can be done by attacker using exact IP and machine as victim. Its red queen.
Many years ago, I worked in an internal audit department of a large organisation. At that time I was invited by a large financial institution to evaluate their online services. I did. The result was that I carefully explained to them the vulnerabilities inherent in their approach, and strongly recommended they authenticated transactions rather than the end-user. They completely ignored my professional recommendations, and noticing that most other financial service providers used similar mechanisms, I have refused to use their online services. The side effect of using most online services is the offloading of the responsibility for the security of the access mechanism to the end user - and I am not en expert in O/S and browser security to the level needed to ensure any PC of mine is secure enough. You have to start from the assumption that the end-user device is comletely compromised - keyloggers/intelligent screen capture software/man-in-the-middle networking and so on and try an develop a protocl that is immune to the compromised channel. This is likely to require a security certified device and public key cryptography and/or one-time pads. Anything less will be subverted.
One problem is that, somehow, the end user needs to be able to tell the system what shouldn't be considered risky behavior.
My parents spend every summer in England; they're constantly having problems with their credit card activity raising flags because it isn't from the US. Ideally, there should be some mechanism for them to let the system know that its ok in advance. (It's probably hard to do this in a secure way, I suppose.)
Be careful before you count two-factor authentication as useless against phishing attacks. Just because someone attempts a phishing attack doesn't mean they made any money at it.
Back in July there was much fussing about how two-factor authentication hadn't prevented the CitiBusiness web site from being phished:
However, there is a difference between an attempted phishing attack and a successful one. To my knowledge, there has not been a repeat attempt. If the first attack had been successful, the phishers would have tried it again.
It's hard to know why the attack failed. It might be because there just aren't enough citibusiness customers to target. Maybe the site got shut down too quickly to snag many victims. Or it's possible that the MITM code was buggy and didn't work properly. Two-factor authentication may have played a part in the successful defensive mechanisms, because it limited the time period the attackers had access to the accounts.
Part of the problem, I think, is that it's difficult to solve human factors problems with technology. You can devise all the systems you want to flag potentially fraudulent transactions, but at the end of the day, the best way to maximize true positives and minimize false ones is still a pair of human eyeballs checking the "flagged" transactions.
Anonymous's problem (the real customer on vacation in Romania) could be mitigated by giving customers a way to notify the bank, "hey, I'm going to Romania next week and might use my ATM card there", but it's hard for an automated system to make intelligent decisions when there's that kind of complexity involved.
Banks will, I'm sure, want to prefer automated solutions to this problem. However, the cost savings of automation will need to be weighed against the costs of fraudulent transactions and against the costs of lost customers due to overly broad automated screening. I suspect that the equilibrium point for that equation will vary widely from bank to bank.
Banks may be cheap, but given the option of purchasing a smartcard/PKI solution as a bank customer, I would procure one, as would others I imagine.
Acknowledging up front the "eggs in one basket" argument some might make, perhaps the FDIC [or someone else with the same market penetration] should look into a program whereby a customer could enroll (possibly for a fee) and obtain a smartcard/keyfob that could be used across multiple financial institutions (rather than having one card or keyfob per bank).
The next step, of course, is to wait until quantum entanglement gets industrialized. Not that such a solution will 'cure' anything, as we all know... merely take the game to the next level.
My problem with all the 'extra questions' is that I am now forced to give up more of my secrets to more places. I can manage giving a unique strong password to each bank I do business with (thanks to password safe- Thanks Bruce). But now every bank wants to know my high school, and my first pet's name, and my home town, and my favorite colour. I can either lie, and try to record which lie I told each bank, or hope that my secrets are safe. What happens when an employee at bank A uses all my secrets to siphon my money out of bank B?
The answers to these questions really just extend our password, (the 'know' factor) but are harder to manage.
the best solution i've seen so far is called mTAN in germany. before the transaction the customer get's a SMS on his mobile phone including the TAN, destination account and amount of money. the TAN is only valid for transactions to that account.
the added security does not come from sending the TAN via SMS, that's not more secure than having indexed TANs. the sent account-number is the security-feature.
"Of course, no one listens to me."
This is just a case of the "traffic light" syndrome.
There is an intersection.
The intersection is obviously dangerous.
It is obvious that some day, someone will be killed.
Nobody installs a traffic light, because nobody thinks that someone will die.
One day, someone dies on the intersection.
Everyone scrambles to get a traffic light installs.
So, listen to Schneier NOW, rather than LATER!
"Be careful before you count two-factor authentication as useless against phishing attacks. Just because someone attempts a phishing attack doesn't mean they made any money at it."
Exactly. There are no reliable figures. Anybody can claim what they want, and this is unfortunately what Bruce does in this case.
"The emerging approach generally consists of somehow recognizing a customer's computer, asking additional challenge questions for risky behavior and putting in place back-end fraud detection." A strategy that partly relies on recognizing the customer's computer is poor security. "Challenge questions" are a weak attempt at mimicking TFA. They put the bar a little higher, but do nothing against Trojan or MITM. Even the weakest form of TFA as practiced in most of Europe is at least an order of magnitude better, because they use one-time transaction codes. As to back-end fraud detection, of course they should do this but it is no more a panacea than TFA. I also agree with the caveat about credit card fraud detection: CC companies pass a large share of the cost on to merchants. The system might not work at all if this wasn't possible.
There seems to be clear evidence that the TAN approach is the most secure to date. Saying phishers will always catch-up is simply a cop-out. As VoIP begins to take root, intercepting phone calls from the bank will become more feasible.
All we can do is implement a solid mixture of prevention/detection commensurate with risk. Each bank must make that decision for itself(its customers). Legislation's only place in the whole mix is to properly govern asset liability. In other words, make the banks responsible and they will either pay out customers because it's cheaper or implement better security. Either way, the consumer can only lose in the form of high banking fees.
Not sure what you're disagreeing with anymore, Bruce. A two-factor authentication system is what you seem to say works at the end of your post, even though you start by saying it will never be worth it...
At least one bank - NAB - is doing this here in Oz. Transactions that arent pre-authenticated are challenged each time, or in the case of periodical transfers they are challenged when they are first created or whenever they are changed. This involves the bank sending an 'n' digit code to the customers mobile phone which is good for one event only. This is manually keyed in to the site to complete the transaction.
One good aspect of this is that security doesnt rely on the usually bad passwords people choose. Obviously if the customers phone is stolen then they need to notify the bank as well as the telco, but the upside is that if the bad guys gain access to their account then the customer gets an unexpected SMS before the bad guys realise they needed it to complete the transaction.
I'm still not convinced this removes the possibility of a man in the middle attack. If bad guys were to successfully and "as transparently as they wanted" put a site between the customer and the banks site, then it seems quite plausible they could present the evidence to the customer that the transaction was progressing according to their wishes while presenting a completely different transaction to the bank. Of course the customers SMS authentication token could be passed transparently and the customer might be none the wiser. In that sense whether the authentication is delivered to the customer in-band or out-of-band seems irrelevant, it is still presented back to the bank in-band. It would make more sense to compute a response and send that back to the bank out-of-band, but I cant see a customer friendly way of doing that easily.
Flagging transactions as "unusual" can cause a lot of headache for customers if not done carefully.
Like some friends of mine, they drove from the UK through France and into Switzerland and then tried to get money out their English account through an ATM. It was a Friday night, the bank was closed and they were stuck with no access to either card and only a small amount of cash to last the weekend. (the bank disabled the partner's linked credit card as well after three "suspicious" attempted transactions).
By Monday morning when the bank finally answered the phone they had decided to close their accounts and use a new bank, especially when they were told they would need to visit a branch to "reactivate" their cards!
@Davi Ottenheimer "A two-factor authentication system is what you seem to say works at the end of your post, even though you start by saying it will never be worth it..."
Two factor authentication by itself does not protect against trojan/man-in-the-middle attacks, if both forms of authentication can be intercepted at the same time.
The phone call / sms from the bank about the attacker's transaction is harder to intercept (but what about voip?)
"My parents spend every summer in England; they're constantly having problems with their credit card activity raising flags because it isn't from the US. Ideally, there should be some mechanism for them to let the system know that its ok in advance. (It's probably hard to do this in a secure way, I suppose.)"
The way it's done with my bank card is I call them from my home phone before I go on vacation. I tell them when I'm going and to what country. They use their caller ID to confirm I'm calling from my home phone as their way of authenticating me. I learned to do this after having my credit card turned off when I made a weekend trip that was 5 hours drive away. Somehow they thought that buying gas and eating at restaurants along the way was suspicious. Now I call them if I'm going to be out of the country.
Unless the SMS challenge contains details of the transaction (which might in itself be a security risk) then this system is still open to MITM.
Also... while the out-of-band verification is nice, it does imply some scope-creep in the user phone number held by the bank.
Initially it was intended as a convenience, and safeguards surrounding changing it would be designed accordingly.
Now the phone number is used as part of the authorisation mechanism. I suspect the system has not been updated to take into account the fact that the phone number is now much more valuable.
I used to do that, too, then I stopped. No reason, but I haven't had my credit card disabled, nor received a call from them, even though I still travel. Mostly to the same places, visiting family, and often the same times of year. Maybe my pattern is known to them by now.
Overseas travel might be different.
@rob mayfield "...and send that back to the bank out-of-band, but I cant see a customer friendly way of doing that easily"
How about a simple reply to the SMS message?
Ok, but if I take a step back, it looks like this starts with the assumption that behavior profiling is a good thing (the user logged in from this computer for this many days, or from this geolocation, etc.) because it makes it easier to validate a session.
But behavior profiling requires the provider to know something somewhat reliable about the user in order to judge a session (the user does not move around much, choosing different IPs and different locations, or maybe they do) The more sessions perhaps, the stronger the relationship.
Of course, the implicit problem is still that something only somewhat reliable about the user is often ripe for abuse by clever attackers. (let's just say IP)
Therefore, something more than somewhat reliable about the user is a good thing, even though it raises the chance of abuse again, requiring something even more "reliable" (another factor). It's true the phone is good because typically the phone system has a "something you have" component to it already built-in. It's not hard to spoof phone numbers or IDs, even before you get to VoIP, but nevermind that...it raises the bar for attackers.
So the only real objection I see to two-factor authentication systems is that many of them are a royal pain to use and end up causing more confusion and control gaps than good. That's a bad implementation argument. A pre-existing telephone solution is desireable because, well, it's pre-existing and we all know what to do with the thing. An odd-shaped fob with randomly disappearing hard-to-read digits that users lose or can't remember to bring with them...maybe that's just not the right tool for the job.
Seems to me that forcing criminals to change tactics is actually the very reason why crime goes down, if not the definition of it.
@Zaphod: Just sending a response is easy enough, but computing a response to a challenge would either require a seperate calc or a java app on the phone - doable but could be messy if not done right. Then theres potential timing issues with the web interface and the authentication arriving elsewhere - again doable but potentially messy ...
I guess my main concern here though is that while some methods seem more secure, they really only have the appearance of being more secure - and the more secure they appear, potentially the more relaxed people will be when they use them, which compounds the problem when workable exploits appear.
@w, @dave: It was about 8 years ago I spent 6 weeks in another city on business. After eating in the same restaurant 5 nights out of 7 for 2 weeks running (they had a big menu) my wife back home received a call from Diners Club to see if I really was in that city and that keen on Italian food ... so some companies have been profiling for a while (I'm sure they do it primarily for the value of the data to other potential customers, but it has the potential side effect of being a valuable fraud detection mechanism ...)
I don't know how phishing looks like in the US today, but over here in Germany, we see trojan horses changing transactions on the fly on the user's PC, transferring money to other banks in Germany (which is then sent to Russia via Western Union). From a backend's perspective, there is no difference from a legit transaction. I do not see how transaction authentication can be helpful in the long run against this kind of attacks.
That's why mobile out-of-band authentication systems (short message with transaction data and one-time-password) or context-sensitive tokens (user has to type in some portion of the transacton into the token) become increasingly popular over here.
"See how two-factor authentication doesn't solve anything?" - yes it does, if applied properly.
Let's not castigate the regulators before we check the facts. The facts are that U.S. regulators *NEVER* "required banks to implement two-factor authentication by the end of this year."
What they did say in their guidance is "Where risk assessments indicate the use of single-factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate risk."
That doesn't sound like a requirement for multi-factor authentication to me, and I can't see how it sounds like it to you. But, just in case reasonable people can differ on the point, let's look at the regulator's Q&A http://www.fdic.gov/news/news/financial/2006/...
"Q5. Does the Guidance require the use of multi-factor authentication?
A. No...the use of multifactor authentication is one of several methods that can be used to mitigate risk as discussed in the guidance"
"Q 10. Are the Agencies recommending multi-factor authentication over layered security or other compensating controls?
A. No, any of these controls may be an effective method to mitigate risk in accordance with the guidance, if properly implemented."
I realize that the press coverage trumpeted the FUD about banks having to implement two factor authentication. Perhaps you were misled by that press coverage?
"Both at log in and when executing a transaction banks should ask a customer a question that only they can answer, and which is different each time. This is how my Dutch and Italian banks do it, but for Anglo-Saxon banks this principle which involves issuing a small piece of hardware is apparently too expensive."
The customer inputs transaction details into the hardware device? Without that, I fail to see how this could be secure against a man-in-the-middle attack; in fact, you'd be talking exactly about the two-factor authentication Bruce explains is (relatively) useless.
A few people have made comments about the possibility of intercepting text messages or phone calls that are used as the second factor in authentication systems. Doing that kind of interception is certainly possible, but it requires a major elevation in technology and resources. I doubt banks will worry about it until phishers prove they can do it.
I agree completely with the comments about spoofing a request to change a phone number as a risk area. Banks have been using the home address as an authentication mechanism for a long time. Now that they are using phone numbers for authentication, they'll need to watch out for changes to that data as well.
@w (09:16 pm): That's so ridiculous, having to inform the bank each time you go on a trip! I am constantly amazed at what hassle and abuse US bank clients are putting up with. The banks are doing what they want, ripping off customers, denying service at will, trampling on customers' privacy rights etc. One gets the impression there is no regulation in this country. Meanwhile, they have the lousiest transaction security around. My guess is the banks will always find a way of passing the cost of security on to someone else - most probably the customer in this case, either directly or by denying service. Denying service may prevent some fraud cases but it also is costly and annoying for the customer who is relying on it.
@Florian, do you have details on how much money was successfully stolen by the attacks on German bank accounts you are describing? The cases that I am aware of actually failed. Is this FUD, or do you have references?
"That's so ridiculous, having to inform the bank each time you go on a trip!"
I don't know that I _have_ to do it, but I have gotten into the habit of calling before any overseas trips because it's too much of a hassle to try to contact them if my card stops working in a different country. I don't call them for trips inside the US and haven't had a problem since that one time.
Have the banks not accept transactions from odd locations, unless you notified them before you left on your trip? Be careful what you wish for. You're assuming the bank actually handles this info competently. I did a three week trip through Europe this past summer. I took three credit cards with me, and I notified the banks for all of them. I gave them a list of the countries I planned to visit, and they all had routines for taking these lists from me. I assumed they were saving the information. However when I got to Europe, none of my credit cards worked. I had to borrow money from my traveling companions. Two weeks into my trip, I finally got one of my credit cards to work in Macedonia, which wasn't even on the list I sent to my bank. Sending the bank a list of travel destinations seemed to do more harm than good.
"do you have details on how much money was successfully stolen by the attacks on German bank accounts you are describing? The cases that I am aware of actually failed. Is this FUD, or do you have references?"
I have no details on money stolen. But I know that this kind of Trojan was in the wild in 2006, attacking a major German bank, and featuring an impressive set of functions in terms of flexibility and user deception.
Quite common are Trojans that do the following:
1. steal TANs (one time transaction numbers) when entered by the user
2. change those TANs before they are sent to the bank, so that they are not invalidated (otherwise the attacker cannot use the stolen TANs)
This is a kind of rudimentary browser-based man-in-the-middle attack. There have been actual damages with this kind of attacks (I have no public references, but I am involved with these issues personally).
Currently, though, there seems to be a trend back to the good old email-and-fake-website phishing scam (I suppose it's just simpler for the phishers), but the more advanced technology is out there. It simply does not make sense for a bank to implement a system today that can easily be broken tomorrow.
I read again and again, among other places here that one-time-passwords doesn't work. But I cannot really figure out how to break the system we use here. Can someone enlight me?
How it works both in Sweden (where i'm from) and in the Netherlands (where i live now) is that we get a small device from our bank. Basically a smart card which uses some encryption algorithm. The device itself is protected with a PIN and looks like a pocket calculator. In the netherlands all bank users (atleast for ABN amro) uses the same device, but insert their bank card in it to personlize it. In sweden the device itself are linked to the bank account. I like the ABN system better since you can actually borrow other peoples devices, at work for example if you need to do something like check your saldo.
You use this device to both identify yourself when you login and to authenticate transactions. If a man-in-the-middle or a trojan on my computer would change anything in the transaction i make, like the amount or add a new fake transaction to their own account, I would immediatly notice this since I have to authenticate each transaction. The number i enter into the device is either based on the account number of the person i want to send money to, or the amount of money I send. If this suddently changes I would of course not authenticate. If the trojan/mitm changes the info "In transit" and display correct data on my screen, then my authentication code wouldn't match the control number of the bank (since it's based on the amount of money sent).
I really cannot see any way to exploit this system. The only downside is that it's a little more hassle to use the device all the time... but seriously, it's not that hard work. I use the online bank maybe 2-3 times each month not more then 15-30 min each time. I think I can manage a little more trouble to stay secure :)
no, there's no man-in-the-middle-attack possible with mTAN because the SMS also includes the amount and the account number and then TAN is only valid for that.
or at least it would require two man-in-the-middle-attacks: internet and mobile phone, which is very unlikely.
@Chris : "I like the ABN system better since you can actually borrow other peoples devices, at work for example if you need to do something like check your saldo."
Do you know if there is some sort of device-authentication going on, or could people be using/loaning a fake device which records the PIN, does the MITM attack, or whatever?
Unbeatable, security access for online accounts is available and in use now at www.pecunix.com
Never been hacked or phished. Its three levels so even if you get into the first level, you don't have any access to funds, a 16 digit PIK (key) and access only asks for a radom 4 digits of this each time coupled with a standard long pw.
I moved to Australia a couple of years ago but kept my UK credit card for emergencies. When I went to use it for a large transaction recently it was rejected. I figured that it was because I wasn't "at home" although they know that I live here. When I asked the bank they told me that they had sent back a 'ring provider' message but that the local card company had just decided that it was too hard and rejected it. We need to make sure that the security measures aren't just rejected as too much effort.
X: "Do you know if there is some sort of device-authentication going on, or could people be using/loaning a fake device which records the PIN, does the MITM attack, or whatever?"
I guess it would be possible to re-engineer the device to record the PIN of the card inserted, but I don't think it would help much unless you get the card as well. It's just like other scams* then when you in some way get both card and PIN and then are able to get money. Mostly useful for getting money from a ATM though because using the info to login and transfer online would create traceable records. The most important defence against fake devices of course is normal human trust. I can't imagine my coworkers, friends or family to cheat me with a fake bank device :)
* another scam to get PIN and card was revealed quite recently in sweden where scammers put up a small camera in the "roof" of the ATM to film the entering of the PIN plus adding a small scanner to the slot where you insert the card, to duplicate the cards. The people being screwed had no idea they just had both their card copied and their pin recorded... pretty smart.
Humans in the loop might solve the problem.
1) If I make a wire/ACH transfer request, have someone from the bank call me to confirm.
2) I'll list all of my pre-approved payees. If I write an online check to someone not on the list, have someone from the bank call me to confirm.
The incremental cost to increase staff in call centers required to pull this off might be offset by the reduced cost from less fraud.
Also, it would add a nice touch - as a customer I would feel important that the bank cares enough to call.
As I am currently studying this topic as part of a university thesis what about the use of public key cryptography to provide the second authentication. at the moment this is just an idea i am playing with and i'm not sure if it has been implemented but the system i am invisioning would work in following way.
user registers with the system and provides the site with their public key. whenever the user wishes to access the system the system generates a random string, m , and encrypts it with the users public key (lets call it u(m)) and then encrypts this with the systems private key (giving s(u(m)) ) and sends this to the user (either though a separate client or through the browser itself) the user then decrypts this with the systems public key (which has been verified by a certificate authority to prove its actually the system they want) giving the user u(m) and then the user decrypts u(m) with their private key to give m1. the user then encrypts m with the systems public key giving s(m1) and sends this back to the system, the system then decrypts s(m1) with its private key to give m1 and compares m if they are both equal then the user is authenticated.
Apologies if the above seems long winded.
It is likely that i would design a piece of client software which would enable most/all of the users actions to be carried out automatically.
does the above sound like a plausible solution?
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.