Failure of Two-Factor Authentication

Here’s a report of phishers defeating two-factor authentication using a man-in-the-middle attack.

The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit—a tactic used by some security-savvy people—you might be fooled. That’s because this site acts as the “man in the middle”—it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.

I predicted this last year.

Tags: , , , , , , ,

Posted on July 12, 2006 at 7:31 AM • 63 Comments

Comments

Mads Krog-Jensen • July 12, 2006 8:10 AM

You have a point however, it’s not just that easy. Yes this works in a lab, but there are many factors to consider here.

This is more of a phishing issue. There is only “so much” you can do for user mistakes, and frankly, visiting a bogus site like the one in the article is a user mistake. (Just like going to a bogus ebay site or similar,). I really dont think that this is a Two-Factor Authentication mistake.

I think that two factor Authentication does the job very well a long way, but you need to combine this with education meaning proper training of the users involved.

Also, if people do visit the “right” site, the “man in the middle” also has some SSL do deal with and a certificate.

I in general like the idea of TFA – we use it here in our company, and if you have some systems that require that level of privacy or security, maybe you should consider removing it from the public internet.

I am much more worried of people “forgetting” to close their sessions, or Citrix apps on a public computer than I am of a Man in the middle attack but if I did not have two factor Authentication, I would not be sleeping at night.

Mads Krog-Jensen • July 12, 2006 8:19 AM

By the way, I dont think that it was ever the intention of Two-Factor Authentication to defeat Phishing.

I Dont know how you would ever be able to “secure” your way out of people heading over to a bogus site and entering their private information. The user here headed over to Tufel-Club.ru instead of http://www.citibank.com – I mean the user here is just a dumb as the one giving out copies of his mastercard and pin at time square. Again, training, training, training.

evin • July 12, 2006 8:40 AM

The token needs to be a USB stick with a program which checks that the site connected to has the valid Citibank SSL certificate before giving up the password.

This still won’t secure you against nasties that you have installed on your computer, but it would be effective against phishing attacks.

TOMBOT • July 12, 2006 8:50 AM

From the FFIEC’s paper mandating 2-factor by 2006:

“Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks.”

Which sounds like citibank (and anybody else using tokens to address this reg) flubbed it. So much for federal intervention.

Phishing isn’t beat at the client end. You beat phishing by investing in appropriate fraud monitoring technologies that are completely transparent to the user. I haven’t seen them, but RSA’s Cyota acquisition and 41st Parameter’s PhishingNet at least sound promising, unlike another dumb token in my pocket:

http://www.rsasecurity.com/node.asp?id=3018

http://www.the41.com/site/solutions/phishingnet.html

Brian • July 12, 2006 8:52 AM

Looked at one way, this is an example of the failure of two-factor authentication. Looked at another way, this is a great example of a security system that fails gracefully.

Had TFA not been in use, the phishers would, in all likelihood, still have access to many of the phished accounts. Instead, they gained access for a very limited time, and that access vanished as soon as their site was taken down.

So was the additional cost of TFA a valuable investment in this case? It’s hard for me to say, given the lack of hard data about phishing losses before and after citibank was using TFA. But I’ll bet Citibank knows the answer.

Anonymous • July 12, 2006 9:07 AM

I don’t see this as a failure. Since the token is one-time use, the damage that can be done is highly minimized. Even if the phishing site captures the token, it would be usable for a very short period. Most token based systems automatically generate a new token when one is successfully used but at most, it would be valid for only a minute.

The intent of shrinking the window of opportunity for malicious behavior compared to one-factor authentication (from indefinite to one minute or less) has certainly been achieved.

billb • July 12, 2006 9:12 AM

@Everyone that thinks that the limited time window matters:

Once the phisher is athenticated, they can transfer all the money out of the account and then log out. The token is only valid for a minute, but once in, the phisher can maintain that session indefinitely.

Brian • July 12, 2006 9:20 AM

@billb

In a normal phishing attack, the attackers harvest usernames and passwords and are able to use them at leisure. The TFA forces them to take action immediately, increasing the chances that the targeted site will notice something unusual going on (e.g. hundreds of users all logging in from the same IP address making large transfers to an account in Serbia.)

The goal is not to make fraud impossible. That’s too expensive. The goal is to reduce fraud to manageable levels at a reasonable expense.

Does TFA help with that task? I’m not sure.

HuhSSL • July 12, 2006 9:36 AM

It comes back to a basic security technology that has been around for over 10 years, and that was designed specifically to stop MITM attacks just like this — SSL.

SSL provides two features. It provides authentication of the server (to stop MITM attacks), and based on that server authentication also provides connection encryption (to secure the data once you have authenticated the server).

The problem is getting the implementors of SSL to “get it right” (which really isn’t that difficult). This would be those making the web browsers (providing clear and usable SSL server certificate verification) and those issuing SSL server certificates (to properly validate the entities they issue SSL server certificates to).

Carlo Graziani • July 12, 2006 9:44 AM

Evidently the issue is that customers are required to authenticate themselves to the bank, but the bank is not required to authenticate itself to the customers.

The channel is not secure if the authentication isn’t mutual. Customers should be issuing their own 2FA requirements to their banks.

commonsense • July 12, 2006 9:59 AM

I look at the cute Citibank TV spots where they show victims of ID theft and then tell you their solution is talking to a real person to get your life back together.
Hmmmmmmm!!!!

When is getting your life back a solution, am I missing something.

When will the IT experts start to think outside the box (OS operating system) for the answer.

To overcome this problem we need five things to happen:

  1. Card-Present Transactions at all existing e-commerce sites.
  2. Enable Card-Present Transactions at the client PC for increased security for both consumer and merchant.
  3. Enable all e-commerce sites that currently accept credit cards to also accept ATM/debit cards through an existing network.
  4. Shield the consumer’s financial and personal information from reaching the Merchant website during online payment transactions.

  5. Protect the consumer’s account data and PIN codes from software executing in the consumer’s PC so that a virus cannot gain access to that information.

Must read articles

http://www.sans.org/reading_room/whitepapers/authentication/1070.php

John Ridley • July 12, 2006 10:01 AM

This sounds very much like the man-in-the-middle attack that some sites were using a while back to use people looking for free porn to decode the scrambled-text images; when a user hit their page, they’d hit another page, grab a scrambled image, have the user hitting their page decode the image, reward them with some free porn, and use the decode to get their target, which ISTR was a hotmail account to spam from or something.

It’s not much of a step from that to doing man-in-the-middle attacks on banking or other infrastructure. The only hard part is getting the people to visit their corrupted site in the first place, but the phishers have that figured out.

Swiss Connection • July 12, 2006 10:08 AM

@ Carlo Graziani

“Evidently the issue is that customers are required to authenticate themselves to the bank, but the bank is not required to authenticate itself to the customers.”

Exactly… bravo. Of course the banks will never do this because if something went wrong, they could be held liable! That in my view is the crux of the matter.

TOMBOT • July 12, 2006 10:33 AM

Client side certificates aren’t widespread because it’s a ridiculous expense in terms of time and money for both the end user and the bank. It’s a lovely solution on paper, nearly impossible to put in to practice.

TOMBOT • July 12, 2006 10:35 AM

Not to mention the false sense of security in trusting ANYTHING that’s supposedly checked and verified by a home users’ windows host.

Brandioch Conner • July 12, 2006 10:35 AM

The solution is simple. Call the phone number on record to authorize any and all on-line transactions.

As Bruce said, this would be “two channel” authentication.

But don’t just worry about authenticating the initial connection. Authenticate each transaction.

ring ring “This is an automated call to confirm that you are transfering $10,534.63 to the Nigerian National Bank. Please press 1 to confirm this transaction. Press 2 to cancel this transaction. Press 0 to speak to an operator or to report a fraudulent transaction.”

The banks have the automatic phone systems, your phone number and all your other info. If they were interested in cutting down on fraud, they could do it.

Brian • July 12, 2006 10:39 AM

Anybody know how much of the liability for this kind of attack falls on the customer and how much on the bank?

Clive Robinson • July 12, 2006 10:50 AM

@Brian,

“Anybody know how much of the liability for this kind of attack falls on the customer and how much on the bank?”

I guess whenever a Judge tells them to take the blaim 😉

Seriously I doubt if there are any real figures published, after all you don’t walk around with a T-Shirt saying “I’m nogood at life”, likewise Banks don’t like to advertise they lose peoples money.

In the UK we have had something called Chip-n-Pin foisted on us by the banks, they claim it’s secure, yet card skimming at ATM’s is still real big business in Central London. Why, because when the chip does not work the fallback is to mag stripe, so the same old game still works for the skimmers…

Oh the Cambridge labs recently demonstrated this failinng with a TV journolist so yes it’s real, Chip-N-Pin is a failier for the customer. However for the banks they claim you let somebody have your card and PIN so it’s your fault…

Brian • July 12, 2006 10:51 AM

@Brandioch

There are some people doing this kind of thing, but I don’t think it has been deployed widely yet. The downside is that it can be inconvenient for customers. For example, if I’m traveling or the bank can’t get ahold of me for some reason, I wouldn’t be able to transfer funds.

If I could restrict this to transactions above a certain value, or if the bank would restrict the extra verification for transactions that they deem unusual, transactional authentication could be extremely effective.

Jarrod • July 12, 2006 10:56 AM

@billb:

“The token is only valid for a minute, but once in, the phisher can maintain that session indefinitely.”

My understanding is that Citibank uses Safeword tokens. The token generates a new OTP with the press of a button, and does not cycle a new OTP in every 60 seconds. The server keeps track of the current count X, and maintains synchronization to X+16 entries.

Hypothetically, a site could act as a MITM and gather five OTPs before finally allowing one through. In reality, of course, the only password sent through is the first one, and the subsequent OTPs are cached for later use, allowing use hours later. Combine this with a time-sensitive malware that provides a local DNS poisoning during the login attempts and subsequently deletes itself, and the user could be sent to a legitimate URL and yet end up at the attacker’s spoofed site. Many of the safeguards that we tell people to use (except for the one about validating login credentials) could thus be undertaken and yet the information still be stolen.

piglet • July 12, 2006 10:57 AM

The article says: “this site acts as the “man in the middle” — it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.” This wouldn’t be possible if the code becomes invalid once used. I am surprised that this is not the case at CityBank.

“Once the phisher is athenticated, they can transfer all the money out of the account and then log out. The token is only valid for a minute, but once in, the phisher can maintain that session indefinitely.” This can be solved easily by requiring another token for making a transaction, as most German banking sites do. The best thing would be to protect both the login and each individual transaction. However, the banks I know all use either one or the other, I don’t know why. All in all, there is nothing in this story that proves that TFA has been “defeated”. If this particular site has been outwitted (and there isn’t even any indication that the phishers were successful), this doesn’t mean it can’t be done better. It seems to be an old obsession of Bruce’s to dismiss TFA but his case remains weak.

piglet • July 12, 2006 11:08 AM

“If you visit the site and enter bogus information to test whether the site is legit — a tactic used by some security-savvy people” – btw, what “security-savvy people” will fall for a phisihing mail???

daniel • July 12, 2006 11:26 AM

This is news? Hackers were using similar social engineering attacks against AOL employees to get the SecureID codes needed to access internal AOL systems such as the interface to account data (“Merlin”). The articles I could find now were all from 2003, but that’s the year I left and I’m pretty sure those types of attacks had been going on for a long while by then.

http://www.wired.com/news/infostructure/0,1377,57753,00.html

jbl • July 12, 2006 11:38 AM

@swiss connection:
“‘Evidently the issue is that customers are required to authenticate themselves to the bank, but the bank is not required to authenticate itself to the customers.’

“Exactly… bravo. Of course the banks will never do this because if something went wrong, they could be held liable! That in my view is the crux of the matter.”
==
Bank of America actually does something like this. When I log in, it shows me a thumbnail photo and caption (a “sitekey”) that I had previously registered with the web site, and invites me to confirm that it is correct. If it can’t show me the correct one, it is not the bank’s web site.

(NB: I just tried it from this computer. When I entered my userid the bank’s site did not recognize the computer (IP address or cookie? I don’t know) and went straight to my challenge question before showing me the sitekey photo and asking for the password.)

Unfortunately, a customized MITM site could handle all these things, as far as I can tell, so the problem still isn’t solved.

 /JBL

jmr • July 12, 2006 11:41 AM

What about a client-side solution tying credentials to a specific server-side SSL certificate?

The way it would work is as follows: You visit a web site, and accept its authenticity once. You then tell your browser the username and password for this site. The browser records the specific SSL certificate and associates it with the username and password.

Later, you come back to the site, and it has the same SSL certificate. Your browser then tells you (or the site directly) your username and password for that site, or lets you choose from a list of them for that site (if you have multiple accounts).

If the SSL certificate isn’t in the database of valid sites, as would happen if the previous certificate expired or you were being subjected to a MITM attack, a big honking explanation of what you now need to do comes up. Maybe the browser shows you the OU and signer of both the old and new certificates, thus explicitly requiring you to authorize the site to receive your credentials. You only need to go through this process once each time an SSL certificate changes.

Ahsan Rasheed Khan • July 12, 2006 11:46 AM

Just a plain question for bruce,
Is there any security system that cannot be broken, both in theory and lab.
There isnt. Security is as strong as the weakest link … if i remember it correctly.
you cant blame TFAs just cuz they are designed to work in a systematic way and phishers keep on finding new creative ways to fool the mechanisim. “The man in the middle attack” an old concept but not practical would leave not only TFAs but PKI and other techs defeated,bruce is missing the point here, TFAs are a replacement of weak single factor with 2 factor as per FFIC, if tommorow Man-Attack gets way common that every tom dick harry can execute it then before that time comes 3 factor would be in place or some other combination. so predictin somethin which eventually can and will happen someday is just like saying i will die one day… -You will die one day offcourse, so TFA or anyother sec technology and this field itself is an evolving one maybe when MnAttack gets too common bruce might introduce a counter measure… 😉 And you need to see the practicallity of the whole matter not just lab results, encryption usin bruce n friends introduced algo’s 2 fish n blowfish can be broken down if the NSA wants too, so nothing is secure.. In our field, everythin is put in place to delay the inevitable…
I agree with piglet here of bruce’s old obsession… Good news: read today tht barclays bank is introducing or introduced the SMS alert for e-bankin for debit LFT (large funds transfer), so thts an immediate way to dectect even if you have been phished and to stop the transaction or file a claim. so a good reactive control is wht needs to be added along with the TFAs which is preventive control…. Hope to see ur comment on this 1 bruce……….

havvok • July 12, 2006 12:01 PM

@jmr
The only problem with that is the underlying issue with browsers; they are really badly written!

A client side exploit would undo this control quite nicely.

Security in the client is a nice thought, but the clients are not the issue, the business process is!

common sense • July 12, 2006 12:18 PM

http://www.send2press.com/PRnetwire/pr04_062103-edisecure.shtml

Why are the banks or institutions are not using single use credit card number.
This single use credit card number (software) combined with a Offline card present encryption (hardware)
device keeps your information of the internet.
Then there will be no need to educate anyone about giving up
their information, because your information will never leaves your person.

Brandioch Conner • July 12, 2006 12:21 PM

@Brian

Yep, this would not, in every situation, allow the customer the ease of transfering funds that is available in the best case scenario.

And there’s a reason I phrased it like that. I believe we should be looking at the issue from that perspective. There should be a hierarchy. With the fastest, secure method at the top (with the most restrictions).

All the way down to you being in a foreign country, with all your ID stolen, trying to get access to your bank account. Because if you can do this, someone else can do it also.

All we’re doing right now is enabling fraud to happen faster, to more people, from further away.

Construct the hierarchy now, with the access levels, identification requirements, authorization requirements, etc. And don’t depend upon existing technology. So what if the technology does not exist for a particular level. That just means that you will not be able to use that level until the technology does.

I’d rather not be able to do something in a convenient fashion than open it up to easy/massive fraud.

Oh, and the system must fail gracefully and fail into a secure state.

Brian • July 12, 2006 12:47 PM

@JBL

a customized MITM site could handle all
these things, as far as I can tell, so the
problem still isn’t solved.

The idea with SiteKey is to alert the end-user that something is wrong. If you frequently login from a particular computer, SiteKey will store a cookie (and I think maybe some kind of Flash file) on that PC. The next time you access from that PC, the BofA web site can use that cookie to recognize the PC, and so it shows you the secret image.

This is hard to beat with a normal phishing site. Even if you can’t read the URL bar ,the browser knows what is there and doesn’t send the cookie to the phishing site. So the phishing site can’t show you your secret image.

Checking address bars and SSL certificates is too hard for most end users. SiteKey simplifies the task: they just need to recognize their secret image. Then they know they are on the right site. The idea is that people get used to seeing the image, and when it isn’t there they get suspicious and leave the phishing site.

Qian Wang • July 12, 2006 12:53 PM

I believe Bruce’s point in his article from last year was that banks were using two-factor authentication for the wrong threat. They will never work correctly for remote login because of MITM attacks. Some of the posts above say that TFA isn’t designed to stop phishing. But that’s certainly the way vendors have sold them to banks and banks have in term sold them to their customers. Phishing is undoubtedly the biggest threat to online banking customers. I’d be very surprised if banks really spent millions on TFA knowing they were not addressing phishing. But perhaps they knew it all along and decided that doing something ineffective is better than doing nothing at all.

Brandioch Conner • July 12, 2006 1:15 PM

@Brian

The problem with SiteKey is that the user can be manipulated into believing that there is some reason why his image is, legitimately, not being shown.

Banks “update” their webpages all the time. SiteKey depends upon the user recognizing a pattern. All it would take is for a phishing site to wait for one of those “updates” and to say:

“Due to recent site upgrade all images need to be re-selected”.

Or without waiting for that, just claim that the cookie could not be found and offer to re-direct the user to a page describing the possible malware reasons for this.

And I haven’t even started to address the issue of malware being installed on the PC. If that happens, all the cookies can be read by the phisher anyway.

SiteKey does not fail gracefully nor into a secure state. Sorry.

Jan • July 12, 2006 1:26 PM

The postbank in the Netherlands implements two-factor authentication using sms. Everytime you do an online transaction you get a sms message telling you how much money will be transferred. You have to type a code in the sms to acknowledge the transaction. This doesn’t completely stop fishing but limits the damage that can be done.

To get around this system the fishing site would have to trick the user into transfering money. But even if it succeeds it can only get the amount of money you transfer. Thus you can only loose a (relatively) small amount of money.

Brian • July 12, 2006 1:39 PM

@Brandioch

You’re right, of course – some ignoramous is still going to type in their username and password to the wrong site. Phishing and anti-phishing are a numbers game. All of the good solutions (think hardware certificates and/or transactional authentication) are expensive and difficult to use. So instead businesses need to measure success in terms of how much a given technique reduces phishing losses, and at what additional cost.

BofA claims SiteKey has significantly reduced successful phishing, but they also admit that it has increased customer support calls. They’ve refused to attach a dollar amount to either statement, but given that they are still using SiteKey I suspect it is saving them money.

About the malware problem – yeah, you’re right. Neither TFA nor SiteKey (or these stupid onscreen keyboards some banks are using) will help much with that in the long term. If the losses due to malware are significant enough, banks are going to bite the bullet and move to transactional authentication.

tc • July 12, 2006 2:09 PM

A couple of comments:

  1. SSL will not do anything (really) to stop the attack. It depends on the SSL certificate for the man-in-the middle attack. If the browser accepts the man-in-the-middle server’s certificate, the attack works just as described. The end-user creates an SSL session with the man-in-the middle system and the man-in-the-middle system then creates a seperate SSL session with the Citibank site. It all depends on how the user has their browser setup (i.e., do they have it set to notify them of invalid certificates), or if the man-in-the middle site can get a server certificate issued to them from a CA recognized by the browser. Add a combination attack where a trojen downloads and installs a bogus CA root into the user’s browser, one can even defeat the bogus server certificate for the man-in-the-middle attack.

  2. What should work is instead of just a two factor combination is to use a smart card with embedded PKI Client Certificate that is only accessible via Private Key known by end user. Then, have the real site set up to only accept known issued PKI Client Certificates authenticated by the server. The only way for the attack to work is for the man-in-the-middle site to get the private key. Since smart card based systems don’t ever store the key on the real system, it isn’t succeptible to trojan attacks, unless the trojan can attack the card itself. Of course it does involve additional software on the client computer to read the smart card, like ActiveCard software.

Rich • July 12, 2006 2:37 PM

@Brian and @Brandioch

Along with SiteKey, BofA continues to send clickable links in emails, thus training users that they should expect email from their bank with links in it.

Phishing is a complex problem that won’t be solved with technology alone. Education has to be a substantial part of the anti-phishing security onion. Instead of a link to a customer’s latest account statement, how about a blurb on “Why this email doesn’t contain any links” which goes into some instructions on how to verify a site’s authenticity?

Bjorn • July 12, 2006 3:09 PM

At SEB in Sweden you need to use your token twice to do anything meaningfull:

Once, to log in. The purpose of that is authentication.

To transfer money from the account you need to reach for your token again. This time you use it to make an electronic signature and sign off your transactions. If this sounds cumbersome it’s because it really is. Fortunately you can queue up bills and transfers and then sign them off in one go.

Besides satisfying the lawyers, this system has the added benefit of making MITM attacks difficult. Having the user give you the excact two tokens you need to empty his bank account is much more difficult. You would have to stall him while you login to his bank and prepare the transaction.

Brian • July 12, 2006 3:15 PM

@Bjorn

Any idea why SEB is so paranoid relative to most of the US banking industry?

@Rich

It’s funny how the marketing department and the security department don’t always have the same agenda, isn’t it?

Bjorn • July 12, 2006 4:04 PM

I’m not sure it’s because of MITM attacks, but then again there have been some very public Internet Banking break-ins recently so people are on their toes.

My guess is that it’s the lawyers that are to blame/thank. It is (to my knowledge) not allowed in EU law to discriminate against different valid signatures so a proper electronic signature (not the same as digital signature) is as valid as one made with pen and paper. Therfore, they can make the customer sign the transactions in the eyes of the law and probably transfer the liability to the customer. That’s always a popular move in this business.

Ralph • July 12, 2006 6:36 PM

  1. To those of you who think it doesn’t matter or is of small consequence:

It is not well documented publically but fraud EXACTLY like this is happening today. I examined another such live site this morning (co-incidence to be sure). The team(s) doing it hare making millions of dollars and if they are making it someone is losing it. It can days to get the paperwork done to shut sites like this down. You under estimate the skill of those involved.

  1. To those focused on ideas how this or that aspect can be fixed:

As Bruce states, this was specifically predicted 12 months ago, together with the solutions and options like the ones you suggest.

What we lack is not the technical ability, but the political will to fix these problems. As security people we have made little discernable progress in securing policical change.

Pete • July 12, 2006 11:55 PM

Bruce has written (both in the blog and his books) on the matter of externalities, and how different parties in a transaction have their own priorities. It’s helpful to think through some of the priorities and security externalities involved in internet banking.

Internet banking customers are typically very bad at knowing what is secure enough – it’s not possible to have a simple answer of “do this, and you’ll be secure”, so it quickly gets too hard and confusing. But at the same time they’ve got used to the convenience and personal control of internet banking and really don’t want to lose this, or for it to be dramatically more inconvenient.

Banks want revenue, and have been able to benefit enormously from the growth of internet banking (and its low transaction costs). They don’t want to have customers stop using this cheap form of banking and would like to increase the number of customers and transactions that are on low-cost electronic systems. They’re aware of the actual losses that are incurred, as in all countries the bank will end up wearing most fraud losses. As with many security breaches, the bank’s priorities – to encourage customer confidence and use of the service – means that they won’t publicize fraud details. [Disclosure regulations change the priorities enormously.] Fraud is part of any type of banking, and so banks will (individually) make decisions about how much money they need to spend to manage the fraud levels. I gather that internet banking fraud is typically less than 1/4 the cost of credit card fraud, so banks will prioritise their fraud management costs. Adding security steps that inconvenience the customer is one of the options to reduce fraud; it’s interesting that European customers seem to readily accept (or expect?) more inconvenience than UK or US customers. Most European banks have had stronger authentication or transaction signing for some years now.

Authentication is a process to verify the identity of some other party. Adding a second factor (or a second channel) to authentication can improve the level of trust in the identity, but of course it can also be attacked. The limitations of two-factor authentication should have been considered by any bank that has been adopting it, and considering whether they should actually bother to adopt it. With so many alternative approaches for user authentication and transaction verification (as well as subsequent fraud detection/response), it’s pretty difficult to assess how much value there is in two-factor authentication – but it may be of some value to at least help limit the potential losses.

The main concern that I have with two-factor authentication is that it shouldn’t be oversold as a security panacea. Security professionals have known this, and perhaps incidents such as this attack will raise broader awareness. Banks like to have a simple and comforting message and it’s been tempting for them to replace the “SSL makes you secure” message with “2FA makes you secure”. It’s clearly time for the general public to learn that it’s somewhat more complicated than that.

So is the current level of fraud too high, and are the current types of internet banking security measures good enough? With such limited public disclosure of breaches this is very hard to judge – so perhaps this is where we should try to apply our political pressure.

Colin Hart • July 13, 2006 12:51 AM

I first saw this kind of activity on a eBay phishing site in the middle of last year. Most phishing sites will accept fake usernames and passwords without question but this one would reject fake usernames, seeming to go away and check with the genuine eBay site whether the credentials were valid.

Not two factor I know but a similar MO.

Clive Robinson • July 13, 2006 3:31 AM

@Brian,

In my post further up I made a comment about not wearing a T-Shirt. A friend dropped me an EMail to say it could be read as an insult to you. Having re-read it I agree it could be read that way.

That was not my intention at all the point I was trying to make was that the average person would not walk around advertising something bad about themselves, even if everybody else has it in common, as it would reduce their chances of success in life. Likewise the banks are reluctant to advertise their failings as it would reduce their likleyhood of attracting and retaining business.

If you or any other readers feel I was being insulting, my appologies it was not ment that way.

Clive Robinson • July 13, 2006 3:53 AM

@Ahsan Rasheed Khan

“Good news: read today tht barclays bank is introducing or introduced the SMS alert for e-bankin for debit LFT (large funds transfer),”

It would be good news if SMS (Short Message Service aka texting) was a primary service and provided a best effort to deliver in a timmely manner. SMS is actually a secondary service which there are no gaurentees of delivery let alone in a timely manner.

Unfortunatly some of the larger mobile phone companies (T-Mobile being one that I have knowledge of) often do not deliver SMS for some time (ie the following day etc). This would not be an ideal system for doing this sort of thing unless extra precautions where taken.

Regular readers will know that I have posted to this blog about SMS used for TFA etc on a number of occassions. I built a practical system back in 2000 and found SMS to be unreliable. I eventually found a solution that worked with most networks which was to send an SMS wait around 30 Secs then phone the number and let it ring three times. This made the network find the mobile which got the SMS delivered. Also if the mobile was not on then the system would know from the response received.

jungsonn • July 13, 2006 7:51 AM

mmm baby! nicely done.

Well what is next? you know i am affriad of those paypal interfaces. Like you need to pay on a site, and that site connects to paypal where you must enter your information, just build a frame arround it

zencoder • July 13, 2006 8:24 AM

Damnit all Bruce, THIS IS NOT A FAILURE OF AUTHENTICATION. Why do you people keep saying that? This is a failure of the communicaiton session. There is no true mutual authentication. If the uninformed user assumes all is safe because he has some shiny token, then it is a failure of marketing and IS on the banks part, NOT THE AUTH SOLUTION.

I understand what you are saying and agree…but it’s not the auth solutions fault this happens, its the fault of sales and marketing allowing people to feel safe and secure because they have a token. It’s the same security argument that the TSA is funded on…it makes us feel safer, so it MUST be working. 😛

http://zencoder.net/2006/07/13/pundits-blaming-2-factor-authenticationagain/

anon_45697979 • July 13, 2006 2:09 PM

@zencoder et al.

I think Bruce clearly states in the past article that his assertion is that 2factor auth does not solve todays problems: phishing etcetera.

Clearly these methods have been put in place to “protect” consumers, in that sense, they fail since 2f was not designed to protect. You are turning it into an academic dispute when it needs to be more practical.

Nigel Sedgwick • July 14, 2006 2:10 AM

Bruce entitled the original posting: “Failure of Two-Factor Authentication”.

Various people have pointed out that the identified failing is not with two-factor.

It has been hinted that, perhaps, the failing is with the advertising by the bank: that protection is advertised that does not protect against the identified attack. I think there is something of a case here. The protection offered does not include adequate measures against man-in-the-middle attacks.

Thus, it could be argued that the protection offered by the bank is not “fit for purpose” in the modern world of Interenet banking.

However, I would like to argue that Bruce is guilty of a similar offence. He has, quite properly, identified a security weakness. However, he has then advertised it as the fault of two-factor identification; this is when the actual security weakness is different: is his analysis therefore not “fit for purpose” in the modern world of IT security?

Best regards

commonsense • July 14, 2006 10:20 AM

Bruce Was right in his predictions about two factor authentication failures. They were all compromised a year ago, but not widely reported.

When is a sense of security, SECURITY?

Again why haven’t the banks or financial institutions look into the “single use credit card number” as a solution.
This is a multi-factor authentication solution has been around since 2000. Is there something that I missed about this method.
This single use credit card number (software) combined with a Offline card present encryption (hardware) device keeps personal information off the internet.

  1. Authentication (card present transaction)
  2. Eliminated credit or debit card number transmitted over the Internet.
  3. Eliminated Key-logging.
  4. Eliminated third party storage of your information.

The need to educate anyone about giving up
their user name and password is a mute point, because your information never leaves your person.

We have to start thinking outside the box (OS), because hackers are in control of the box.

Have anyone read the white paper “It’s All About Authentication” By Doug Graham

piglet • July 14, 2006 1:26 PM

“Bruce Was right in his predictions about two factor authentication failures. They were all compromised a year ago, but not widely reported.” Bullshit.

Brian • July 14, 2006 3:43 PM

@commonsense

Think it through. A single-use credit card number wouldn’t have done a thing to slow down this attack.

solar • July 15, 2006 4:25 PM

What about SET?

Anyhow, the problem is probably partially insoluble, because the smartest phishers are way smarter than the dumbest users. If everything else fails, they’ll put a notice on their web site that the crypto/security isn’t working properly and it is okay to ignore any warnings. I bet it works quite often. And I’ve seen something to that effect on a non-phishing site, so don’t laugh too hard.

Another MITM attack works as follows; mafia sets up a porn site, collects payment information, and uses the user’s credentials to MITM to another web site, making a purchase of something entirely unrelated, like e-gold, delivered to them.

Building security into the browser chrome may help somewhat, but basically the UI people need to figure out how to ask for and convey identity (of a remote site), and the security of the communication, in an intuitive way. Maybe there is no way that is intuitive enough, so it will take a generation before people have grown up with the new idioms.

Another thing that would help is caching the server SSL certs the way ssh caches host keys. Then you have divided things up into two problems:
1) Initial contact – PKI
2) Subsequent contacts – local cache

You can even customize the local cache so it shows an image (selected at random the first time we connect) in the browser chrome, which stays with the cached certificate. That makes it both hard to spoof, hard to guess (since it’s random), and memorable for the end user.

This should make it difficult enough that black hats will just revert to breaking the security on the endpoint some other way.

John Crayon • July 17, 2006 1:56 AM

The point completely missed is that it’s all about risk mitigation, not elimination. If 2FA reduces the losses to an acceptable level, then as far as the bank is concerned the problem is solved.

Sagachi • July 18, 2006 7:58 AM

As other posters have stated, and Bruce has said in the past, the problem is one-sided authentication. My feeling is that three things should be authenticated: the customer, the bank, and the transaction itself.

Here is what I mean by validating the transaction. When I used to work at a financial institution, some of the tellers would get to know some of the customers. If a longtime customer came in with a strange person to close their 20-year account for no apparent reason, the teller would know something was up and alert the manager. In this way we did prevent several swindles. Bank systems need to be designed to detect patterns and issue alerts based on anomalies (such as transferring whole accounts to overseas banks in the middle of the night).

J.Pepino • July 18, 2006 9:22 AM

There is an emerging technology firm in Denver, id-confirm which has developed a personal biometric token which generates an 8 digit alpha numeric OTP each time an individual swipes their finger. Used in an on-line banking environment this 4 factor system would eliminate an attackers ability to move money from the account. Should they be able to follow an account holder into the site even though the account holder uses the OTP to get in, to make any transactions, the site should require an new OTP from the device for each transaction. A simple 5-10 second process to generate the OTP and verify against the backend server, isn’t too much to ask consumers worried about their financial security. This is a far more robust solution than RSA, secure computing, etc

Dotz • July 18, 2006 2:51 PM

Hi. I’m a student in the Ateneo de Manila University working with some CS graduates on a thesis regarding a USB token that holds a digital certificate embedded in a portable web browser that launches directly to the particular bank’s web site, preventing man-in-the-middle attacks.

Key Words:

Client-side Authentication
Two-factor Authentication – username & password, certificate
Certificate-based Authentication/PKI

Another product is a Biometric fingerprint-scanning token with the web browser and certificate for multi-factor authentication.

Would you like to discuss your comments? Pls. mail me. Thanks. 🙂

alma • June 13, 2007 9:00 PM

what is the best defence against man in the middle attack strong encryption or strong authentication

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.