Network News

X My Profile
View More Activity

Citibank Phish Spoofs 2-Factor Authentication

Security experts have long touted the need for financial Web sites to move beyond mere passwords and implement so-called "two-factor authentication" -- the second factor being something the user has in their physical possession like an access card -- as the answer to protecting customers from phishing attacks that use phony e-mails and bogus Web sites to trick users into forking over their personal and financial data.

These methods work, however, only so long as the bad guys don't fake those as well. Take this latest phish, spotted by the people over at Secure Science Corp. It uses an impressively crafted Web-based e-mail that targets users of Citibank's Citibusiness service, which -- as its name suggests -- caters to businesses. Citibusiness also requires customers who want to log into their accounts online to use a supplied token in addition to their user name and password. The small device generates an additional password that changes every minute or so.

The scam e-mail says someone (a nice touch added here -- the IP address of the imaginary suspect) has tried to to log in to your account and that you need to "confirm" your account info. Not a whole lot that's revolutionary there, but when you click on the link, you get a very convincing site that looks identical to the Citibusiness login page, complete with a longish Web address that at first glance appears to end in "," but in fact ends at a Web site in Russia called ""

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.

Update, 4:41 p.m. ET: I forgot to mention that while this phishing site was active late last week and during the weekend, it has since been shut down.

By Brian Krebs  |  July 10, 2006; 4:24 PM ET
Categories:  Latest Warnings  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   StumbleUpon   Technorati   Google Buzz   Previous: Macromedia Flash Update Prompts an SF Rant
Next: Windows 98/ME-Friendly Security Tools


Interesting stuff. Brian, do you have the IE7 beta installed by chance? I'm wondering if that browser's phishing filter would flag this.

Posted by: Matt | July 10, 2006 7:17 PM | Report abuse

Brian, what do you think the banks will do in response to this? After all, they've made a significant investment in two-factor authentication and now it looks like their customers continue to be as vulnerable as before. Bruce Schneier's essay from last year ( pointed out that two-factor authentication is vulnerable to just this sort of man-in-the-middle attacks, but didn't offer any potential solutions to the problem. I think filtering out hosts or IP addresses that attempt to log in as too many (let's say more than 5) different users would work in this relatively simple attack, but would fail if the proxy role is delegated to zombied PCs from all over the world. I'm very interested in hearing your thoughts on what, if anything, can banks do apart from the never-ending battle of "user education."

Posted by: Qian Wang | July 10, 2006 11:23 PM | Report abuse

This company has a great solution that is gaining some traction in this space.

Posted by: Secure Online Two Factor Authentication | July 10, 2006 11:48 PM | Report abuse

I'm going to address two of the comments: first one in response to the solution to the problem - This specific phish attack was using botnet IP's, and so thus it could be deemed successful. The solution to these types of problems are usually defense-in-depth. There is no silver bullet to phishing, but there are ways to make your bank less of a target.

Second one - regarding the advertising for the viagra sounding online authentication, this solution is far worse than the already available 2-factor rotating token concept. A fingerprint only grants more access, and can be easily stolen one time, with less technical merit than this 2-factor session token.

Posted by: Lance James | July 11, 2006 12:14 AM | Report abuse

That depends on how intelligent the combination of fingerprint-reader + activeX client is.

The added security lies in the fact that you use a third party that is giving it's OK over a separate connection allways going to the bank's servers.
If that third party's address is hard-coded into the activeX (and traffic as wel as the activeX itself are well encrypted), it's still possible to get somewhere but it would be more difficult then the example given above.

Posted by: XTroniC | July 11, 2006 5:43 AM | Report abuse

One reader asked what the solution is. The solution is to move from USER authentication to TRANSACTION authentication.

Authenticating the user, whether by a password or with a one-time-password (OTP) token, will be vulnerable to this kind of attack. You can't stop it.

What is needed is a way to stop the attacker transferring funds once he has logged in. Some tokens include a small keyboard on which transaction details (beneficiary account number, amount) can be entered. The OTP thus generated authenticates these details as well as the user. This way, an attacker can't change the transaction details, or invent their own transactions.

This approach is already offered by some token vendors, and also underpins the MasterCard Chip Authentication Program (CAP), which uses your existing bank card in a small hand-held reader to generate OTPs. This last approach is beginning to see trial deployments in Europe.

Posted by: Jonathan Tuliani | July 11, 2006 6:11 AM | Report abuse

What you need is what some Swedish banks already have, a security token device that after you enter the correct pin code takes account numbers or currency amounts as input and returns passwords that you use to log into the bank and for each transaction. This way, man in the middle attacks are impossible as long as the user checks that the input they are asked to enter into the security token device is correct.

Posted by: Joakim Bengtsson | July 11, 2006 6:46 AM | Report abuse

A possible solution could go something like this:

- traditional username/password combination for authenticating to the online banking site.
- two-factor authentication for confirming payments.
- a mandatory delay (e.g. 2 mins) between authenticating to the site and being allowed to make payments.

This would ensure any one-time token submitted to a phishing site would have expired before it could be used. It's slightly inconvenient but every solution is a trade-off between security/convenience/cost.

Posted by: Tony | July 11, 2006 6:54 AM | Report abuse

It looks like that two factor phishing scheme targets tokens like the ones RSA makes where the code changes every minute or so.

Posted by: Sam | July 11, 2006 8:28 AM | Report abuse

The problem is two fold:

1. Inability for the user to authenticate the end point. It is difficult for the average user to identify what is the banks real website.

2. Social engineering is easy. People even security savvy people can be fooled.

The solution to 1. is difficult. Transaction security is one where the banks have excelled in the past but that was over dedicated links and closed networks. Transaction security over the Internet proves to be difficult as you have many users from many different browsers trying to access your server. Simply getting clients to move to more improved versions of SSL is difficult due to the need for backwards compatibility.

What is needed is verification of the bank's endpoint to the user and the establishment of a secure endpoint at the user's end.

Posted by: Ryan | July 11, 2006 8:40 AM | Report abuse

This is a real threat in online banking.
RSA rba(risk based authentication) adress this issue exactly in a way that eliminate the need to bother the end user with double and triple authentication methods and stop only suspected activities.

More info:

Posted by: LT | July 11, 2006 8:55 AM | Report abuse

- Add a 3 day delay on bank transfers
- Setup txt alerts on bank transfers e.g. call this number if you have not transfered £3000?

Posted by: woany | July 11, 2006 9:05 AM | Report abuse

Unfortunately, a man-in-the-middle attack could be generalized to the "some guy standing behind you who wacks you on the head after you login"-attack.

Out-of-band confirmation (text message, phone call, etc) is a good (though not usually cost effective) method of confirming transactions, but logging into the site is still a problem. Some vendors are pushing special magic USB tokens that have hardened browsers on them, so that you can reduce the chance of a zombie-fied PC hijacking your account, but it is virtually impossible to eliminate this completely.

Posted by: XYZ | July 11, 2006 9:16 AM | Report abuse

A solution to mitigate the man in the middle attack could be, to make the user enter alphanumeric characters embedded in an image generated every time on the login screen, along with the 2 factor authentication.This would ensure than no automated program/screen reader can simply pass on the 2 factor credentials to the actual site to login.

Posted by: Paras | July 11, 2006 9:40 AM | Report abuse

A solution to mitigate the man in the middle attack could be, to make the user enter alphanumeric characters embedded in an image generated every time on the login screen, along with the 2 factor authentication.This would ensure than no automated program/screen reader can simply pass on the 2 factor credentials to the actual site to login.

Posted by: Paras | July 11, 2006 9:42 AM | Report abuse

As an IT security professional it amazing that we continue to apply complex solutions for these issues. How many times have banks, PayPal and eBay notified the public that they DO NOT sent out emails that requires a user to authenticate via a link on there email. Just delete the email, do not respond to it or asked to be removed from the email list this will increase the SPAM. DELETE, DELETE, DELETE!

Posted by: Mike | July 11, 2006 9:48 AM | Report abuse

@ Paras

CAPTHA used to work, but now are seen as pretty broken. OCR software is much better and even if they couldn't read it, they could just push the CAPTHA back thru the phish site to the user and make them break it.

I see this trick all the time on phishing sites. Reported one for CNUA recently that was doing exactly that, but of course it was being hosted on a "more adult focused", so you can guess what the CAPTHAs were for.

Posted by: Technocrat | July 11, 2006 10:04 AM | Report abuse

Its not only about identifying this as spam and deleting it.

It has happened before that a registry has bend the DNS entry for some legit website to a malicious server simply by acting on the written request of someone who impersonated the web site owner.

Sure, after that little incident (ebay anyone?) registries are supposed to verify the identity with keys, but that does not mean it won't happen again.

Thus, if a system is vulnurable to man-in-the-middle attacks, the solution should not be to close just one attack vector.

Posted by: Carsten, The Hague | July 11, 2006 10:04 AM | Report abuse

I'm not impressed at all by this phishing email. While the phishers may be sophisticated in their techniques, what they still lack is a mastery of the English language. This should be an obvious red flag. Examples:

"Unsuccessfull"? Bad spelling. This should be a huge red flag.

"...send you an Activation Code by post..." = non-standard use of terminology (that is, a native English speaker would have said "by [or before] email" or "by [or before] US Mail" (whatever "by post" means). Another red flag.

"Confirm your address until 06/30/2006": a native English speaker would have said "by 06/30/2006" not "until 06/30/2006". Yet another red flag.

Also, the first sentence of the email has too many commas, its construction is convoluted, and it runs on. Definitely not the kind of professional writing you'd expect from a major corporation like Citibank.

Etc. etc.

The sad thing is that most native English-speakers also don't have a mastery of the English language, so the bad spelling and clumsy grammar in a phishing email looks perfectly professional and acceptable to them.

Posted by: Mark | July 11, 2006 10:16 AM | Report abuse

The trivial solution, as mentioned above, is to email or text message you every time something is deducted from your account.

You could even set it up to require a click-back in the email to allow the deduction.

The biggest problem with this is probably that spam filters might prevent the mail from getting through. Not to mention that it makes online banking more cumbersome so people are less likely to use it.

And, of course, if a virus or trojan is running on your computer, it could automatically eat the verification email. So text messaging might be best since it is completely out of band.

Posted by: OldMacGuy | July 11, 2006 10:30 AM | Report abuse

why do people still fall for this stuff? Just don't respond to ANY e-mails of the sort. If you think your bank has a legitimate issue with your security verification, call their 800 number of just go to a branch.

And always check the domain of the page your on. It's easy and foolproof. That site was clearly not a Citi URL.

Posted by: joe | July 11, 2006 10:32 AM | Report abuse

Would symmetric key signatures help here?

If the banks all publish public keys the end user could validate that they site is passing a signed message that matches the public key.

The UI for it would have to be user friendly, but I think this can be pulled off.

In short, it's a problem of authenticating the server that's missing. They'll have the whole problem boxed in then.

Posted by: Kris Bravo | July 11, 2006 11:03 AM | Report abuse

Instead of pushing even more user authentication,out-of-band verification (click back, phone backs), and business robbing delays, the need here is to come up with a robust method of verifying the identity of the bank web site to the user. This needs to be done in a way that is user friendly but impossible to spoof.

Some companies are offering a user image display that provide visual confirmation to the user that the bank is real. This may work.

Posted by: mark | July 11, 2006 11:08 AM | Report abuse

Wouldnt public/private key encryption solve this problem if you could have a preset public key so it doesnt need to be downloaded? If you did a USB key with a hardened browser on it you could have the public key preset.

Should keep the man out of the middle.

Posted by: Anonymous | July 11, 2006 11:27 AM | Report abuse

This is silly. There is NO WAY to prevent phishing attacks outside of user commonsense. Bank of America has a two-layered scheme that is also vunerable to a man-in-the-middle attack, and I told them as much but they would not hear me. I got the official "We've tested and researched it and it works", and I stop short of telling them that if I wanted to I could foil their "elaborate" scheme with less than a day of coding. I would NEVER do such a thing, but as a software engineer, it was all to obvious and easy to think of many EASY ways around their scheme.

There is no remedy for the idiot factor.

Even if you know better, there are still possible attacks, but they require more effort on the part of the phisher. For instance, your computer could be rootkitted with something that comprimises the network stack or even just record keyboard strokes.

Someone earlier mentioned using ActiveX ways to foil attacks, but of course that solution will leave everyone who does not want to use IE out in the cold. And IE is a window to all kinds of malware, anyway. So, requiring everyone to use the least secure browser to "enhance" security is just plain silly. And I personally refuse to use a service that requires me to run IE under Windows just for access. I neither use IE nor Windows for *anything* serious.

Posted by: Flajann | July 11, 2006 11:31 AM | Report abuse

Hmm... Let's see... Why not just use the SSL server authentication that is already part of every https web transaction!

SSL was specifically designed to prevent man-in-the-middle attacks. SSL provides two features, authentication of the server and channel encryption. The authentication of the server is required, since encrypting data to a server that hasn't been authenticated is just a waste of CPU cycles (you could be encrypting the data using the bad guy's key).

The problem is that users don't know how to check the SSL server authentication (most browsers don't make this obvious, although I understand that IE7 is better), and the Certificate Authorities have devalued trust in SSL certificates by removing any real verification during the SSL certificate enrollment (one can get an SSL server cert by just having a domain name, the CA doesn't do background checks, etc. to validate the entity getting the SSL server cert).

Posted by: SSL | July 11, 2006 11:32 AM | Report abuse

A comment on CAPCHA:

A few months ago I saw a phishing attack against a large bank in Europe. Unlike other attacks, when you clicked on the URL the page that opened didn't ask for any personal details, but rather presented a CAPCHA that you had to solve. Once you solve it, an error is presented.
My guess was that this was a man-in-the-middle-CAPCHA-solving attack. The attacker grabs a CAPCHA, presents it to the incoming user, and send the answer to the site that uses the CAPCHA. Turns us Internet users into smart (or stupid, depending on your point of view) CAPCHA solving cheap labor. So even CAPCHAs that are immune to OCR programs can be cracked by using human beings who fall for a spoofed email. Scary? Aye.

Posted by: Uri | July 11, 2006 11:37 AM | Report abuse

We should close off the Internet to everyone outside the United States. When other countries begin policing their Internet traffic then we can let them back in.

As for scammers that are within our country... we need to begin treating these scammers as the criminals that they are and throw them in prison. It is a serious offense to defraud people. The fact that it's easier to send out 10,000 phishing messages than it is to steal 10,000 purses doesn't make it less serious!

Posted by: Speed | July 11, 2006 11:44 AM | Report abuse

I've said it time and again: phishing is not a user authentication problem, it's a web site authentication problem. Providing users with two-factor authentication is like changing your motor oil to address a brake problem. You're fixing the wrong thing.

What is needed is a clear, easily identifiable way for users to confirm that they are on a legitimate web site, and there's no easy fix for that right now; probably never will be. Any solution will involve some sort of user education, which is always hit-or-miss.

Phishing in one form or another has been around for centuries, the only thing that changes is the technology surrounding the con. It's human nature to fall for things like this. Don't expect that to change an time soon.

Posted by: BobD | July 11, 2006 11:49 AM | Report abuse

I'm enjoying this interesting discussion with a lot of good ideas for potential solutions. But I agree with Mark's comment and feel that, at least in the U.S., more authentication does not seem to be the right answer. The marketing message to the consumer here has been focused on the convenience and speed of online banking. And the marketing message to banks from various vendors and analysts has been focused on the cost savings of moving customers online. With fraud rates still relatively low here in the U.S., to burden the majority of users with extra authentication will probably have an adverse effect on usage rates, which will in turn reduce the cost savings for the banks. Similarly, it is not cost effective to distribute authentication tokens or analogous devices to users when online banking was supposed to save expenses, not create new ones.

I also feel that there's a general tendency in the financial services industry to downplay the fraud issue. To a certain extent this is perhaps justified since customer liability is limited in fraud cases in the U.S. anyway, why scare your customers away from online banking? Just as going into a neighborhood where every house has iron bars on the windows makes you feel the neighborhood is unsafe, too much talk of security measures may actually make a bank's customers feel a sense of insecurity.

So I pose the question again, given these fiscal and marketing constraints on U.S. banks, what can they do? Perhaps they should do nothing for the time being and wait until the problem gets worse and the losses from fraud begin to make the business case for additional authentication. Or perhaps there's some technology that is not yet mentioned? Will IE 7's (and Firefox 2's) built-in phishing warning have a measurable impact?

By the way Mark, I don't think using user images (e.g. SiteKey by Bank of America) would help in a man-in-the-middle attack since the attacker can simply grab the image from the bank site and display it to the user.

Posted by: Qian Wang | July 11, 2006 12:13 PM | Report abuse

Check out this company, 41st Parameter, who is develloping anti-fraud, anti-phishing technologies for internet merchants etc. They just got a load of investment capital two months ago!

Posted by: jMoMo | July 11, 2006 12:52 PM | Report abuse

I wrote one possible solution here:

"Making Phishers Solve a Captcha"

Posted by: directorblue | July 11, 2006 12:58 PM | Report abuse


I say this, because ONLY a geek would come up with all of these complex, intricate ideas, systems and safeguards for something SO INCREDIBLY STUPID!

The solution is simple.

When a customer opens an account with a new bank, sit them down to watch a video. That video is nothing but a one-minute loop with the Emergency Broadcast System warning tone, and the following phrase scrolling across the screen.


Then you have the customer sign a EULA that essentially says,

"I understand that X Bank will never send me any email, for any reason whatsoever, and will only contact me by phone. If I ever give out my bank details because of an email, I will be out of luck, because I am a moron and a sucker."

Posted by: Ion Otter | July 11, 2006 2:25 PM | Report abuse

To the last commentator, well, two bad phishers are geeky enough to use caller-id spoofing and will call you too. How do you solve that one Mr. non-geek?

Posted by: Lance James | July 11, 2006 2:29 PM | Report abuse

PKI mutual authentication, perhaps using a USB flash drive with onboard smart card, can do mutual SSL authentication through the browser. Combined with certificate whitelists, you can do mutual authentication of both the site and the user.

It's also immune to network man in the middle attacks.

Posted by: DaveJ | July 11, 2006 2:36 PM | Report abuse

Riight. MS of all people are going to have a filter to prevent this. Sorry - BRB but I have to laugh for a while.

I am sure all readers of Crypt-O-Gram are now shaking their heads and muttering 'Bruce told you so'.

Posted by: Rick | July 11, 2006 2:57 PM | Report abuse

Not all identity solutions are built the same. Solutions today have to be adaptive and offer security layered like an onion. If you haven't seen it before. Look here...

Posted by: SA | July 11, 2006 3:02 PM | Report abuse

Speed - what a stupid comment "close of the internet to foreigners". I'll have you know that some ameture in Seattle tried to Phish me just the other week. Perhaps we should close the internet to all Seattleites?

Posted by: Brendon | July 11, 2006 4:01 PM | Report abuse

Speed - what a stupid comment "close off the internet to foreigners". I'll have you know that some ameture in Seattle tried to Phish me just the other week. Perhaps we should close the internet to all Seattleites?

Posted by: Brendon | July 11, 2006 4:01 PM | Report abuse

Phishing isn't going to be fixed because it is still cheaper for the banks to loose some money to phishing scams than it is to employ staff to carry out transactions manually.

It is simple mathematics: profit (minus some $ to phishing plus some $ from staff wage bill savings) equals increase in profit!

It is cheaper for banks to interact with their customers online than to have the customers walk into the branch, even if they have to refund $ to customers who have lost it in phishing scams.

It is similarly cheaper for banks to loose some $ to bank robbers than to pay wages to security guards at the doors like they used to have.

Posted by: WillB | July 11, 2006 4:03 PM | Report abuse

People need to realize that from the web sites' perspective ALL communications are coming from a single user (the hacker) and from the users perspective all communications are coming from the hacker, too.

If you send additionaly challenges, the hacker will send them on to the customer and let the customer reply and then pass on that reply.

Also, this is different than somone standing behind you because of the scalability. Scalability puts this into a whole new realm.

In order to solve it, education is important, but still will not stop this attack coupled with DNS cache poisoning. Dual-key SSL is also a possible solution, but here the user would need to know enough to only trust the server key that they carry with them.

Posted by: Anon | July 11, 2006 4:41 PM | Report abuse

Good News :

Firefox 2.0 ( This is browser like internet explorer for people who don't know ) has a built-in antiphishing tool. So give a try.

Just got release.

Posted by: Nag | July 11, 2006 7:43 PM | Report abuse

While this kind of MIM type of attack is hard to prevent unless the client has some sort of phishing detector software installed, there are other second factor authentication program that changes the authentication challenge for each authentication process will help. For example, Entrust makes IdentityGuard that is very cheap and easy to deploy and will be able to prevent or minimize the risk of MIM attack to a certain extent:

Posted by: SyncMaster | July 11, 2006 8:04 PM | Report abuse

easy, here it is..
HQ controls all devices remotely by a series of serial codes and complex aritmethic algorithms... the token produces a 6 digit numer, that changes every minute.. webpage asks your name.. password.. ID number and ur token number at that instant... u got a minute to put everything in


Posted by: Anonymous | July 11, 2006 8:53 PM | Report abuse

If you use tokens, it should be easy to not only use them for authentication during login but also force the customer to enter a new, different one for every fund transfer.
Even if the phishers manage to get to the account, they would need a valid token to initiate a transfer.

This is what HSBC does: you need to use their token generation device for every transaction that moves funds around, not just to log in the website.

Posted by: Renaud | July 11, 2006 9:52 PM | Report abuse

Very good article and alert. Thank you ever so much.


Posted by: Uatu | July 11, 2006 9:59 PM | Report abuse

Digital Signing and verification of individual transactions (say using "visual" dialog or handheld device containing the transaction details to be confirmed by the user prior to signing) combined with a user held card which requires a PIN (like a SmartCard) is the only real effective mitigate to the MIM attack... this will protect the integrity of the transaction so it doesnt matter if the user is fooled or an attacker intercepts the signed message (it is now tamperproof by the signature).
This "visual" approach is used by PKI schemes (such as IdenTrust) to prevent/reduce MIM attacks. Our bank has used this to great effect.
Of course, you have to ensure that a phishing email cannot access the device the directly and spoof the user with a phony dialog, this is where PC self-integrity checks (in your software or using 3rd party products) is used.

Posted by: joe-blow | July 12, 2006 1:32 AM | Report abuse

(I am a Systems engineer and an Internet bank user.)

Not opening emails from scammers won't protect you completely.

Most Internet banks security can be compromised if the computer you are using has been hacked. A hacked computer can be used to perform man in the middle attacks or to copy security certificates and sniff passwords as they are entered on the keyboard, or even to access hardware crypto devices attached to the computer.

The _only_ secure solution is to base the security entirely on some hardware device that requires physical user interaction, an external security token device for example. And as I said in my previous post, that device must take transaction relevant numbers as input and generate a one time password for each transaction. This combined with a vigilant user is the only way to handle transactions securely. This is also better then using software you install on your computer for another reason - you can access your Internet bank from _any_ computer.

I do not agree with the argument that using such a solution would be too much work for the customer. In a typical usage scenario (paying 5 bills), I have to enter an 8 digit code into the device and an 8 digit reply into my computer 2 times. This is because my bank uses a recipient list that the user creates, to add a payment recipient you must use the token device, but once added you only need to use the token device twice in most cases, once to log in and once to allow the transactions you have scheduled to proceed (the sum of all transactions is then used as input for the token device).

An attached security device that requires physical user interaction to function could be as secure and would not require the user to press as many buttons, but it would limit the ability to use the device on any computer

Posted by: Joakim Bengtsson | July 12, 2006 3:50 AM | Report abuse

Clarification, with "vigilant user" I mean that the user checks that the input they are asked to enter into the security token device is correct. This way, man in the middle attacks are impossible.

My guess is that only rich people and businesses are targeted by man in the middle attacks since it takes some effort to pull off such an attack. Normal users are pretty safe even if they don't check for such attacks.

Posted by: Joakim Bengtsson | July 12, 2006 4:00 AM | Report abuse

I agree with many commenters that the defense really depends on the threat scenario you want to address.

For some, only a trusted computing environment is good enough and if you have that, two-way TLS/SSL is the text-book solution.

However, end-users and banks so far didn't like the idea to have a full-fledged device/computer dedicated just to online-banking for various reasons. Also, rolling out end-user certificates/private keys has proven to be a significantly larger challenge than initially anticipated. Thus the text book solution does not appear to be very practical in short-term.

We have come up with an alternative solution that achieves roughly the same as two-way TLS, but works with most of the already existing population of 2+-factor authentication devices.
A detailed technical paper will shortly be available.
One big advantage is that the end-user need not be able to decide whether the bank's server certificate is good and the bank can determine on its end of the TLS/SSL connection whether a MITM was present or not. The proposed method "TLS-session-aware authentication" or "MPA" also works if the attacker chooses other means of attack than traditional Phishing emails with deceptive links (e.g. Pharming and all kind of DNS attacks...)

Posted by: | July 12, 2006 5:23 AM | Report abuse

Ralf, if someone hacks the users computer, your solution still fails to protect him.

Posted by: Joakim Bengtsson | July 12, 2006 6:29 AM | Report abuse

There will always be exposures. Anyone thinking they can 100% secure against phishing or other exploits, is mistaken.

Im certain that decades ago, there were similiar discussions such as this but the topic was "How do we protect our physical bank branch 100% against a robber"?

Guess what.

Posted by: Montgomery Co Reader | July 12, 2006 8:53 AM | Report abuse

Before typing all of these massive, detailed responses:

Are you "professionals" aware, that we are talking about the following conditions being met.

#1. User is simple enough to fall for the basic phishing scam, and believes the email.
#2. Believes the email, sees the ".RU" at the end of the URL, and continues his idiocy.
#3. Enters his credentials, including the pincode that changes every 60 seconds. Oh..and he enters the code on second 1 of a newly generated code.
#4. Hacker sits down on the other end, and delay..IMMEDIATELY...receives the userid, password, pincode...and within 58 seconds...uses that valid pincode for that session.

It would be easier to commit strong armed robbery and get the physical card/pin #.

Posted by: Joe | July 12, 2006 8:58 AM | Report abuse

What ever solution evolves, it needs to be simple and easy to use. It should not depend on an external device that would require support or distribution, especially to a consumer market to truly be cost effective and reasonable from a usability perspective. This creates somewhat of a support nightmare for any financial institution...remember windows-based online banking? Banks gravitated very quickly from windows to web-based online banking so they could get out of the software distribution and support business. As someone who works in marketing at a financial institution, I don't see the ideal solution available in the market yet. I hope that it will come about very soon as it is needed, along with continued focus on client education. Of course, isn't there a saying about someone can always build a better mousetrap, but the mouse still gets away with the cheese.

Posted by: SC | July 12, 2006 9:28 AM | Report abuse

"The solution is to move from USER authentication to TRANSACTION authentication."

"A possible solution could go something like this: - traditional username/password combination for authenticating to the online banking site.
- two-factor authentication for confirming payments."

This is what German banks have been doing from the very beginning. No transaction without a one-time code. I wonder why the example hasn't been followed? Btw I would prefer TFA both for login and for each transaction. This would mean that an atacker needs to obtain at least two one-time codes in order to get money. Try to beat that. Strange but it seems nobody is using such an pproach.

Posted by: piglet | July 12, 2006 12:15 PM | Report abuse

This response by phishers is completely predictable since 2FA is not designed to mitigate these attacks. It is designed to mitigate spying attacks that take place either or the user's PC (i.e. spyware) or on the network.

The only way to mitigate phishing attacks (which are all essentially man in the middle attacks) is to have a mechanism that authenticates the browser to the machine hosting the web site. SSL attempts to do this but most users don't ever look for the padlock or whatever other symbol the browser uses to show that the connection is using SSL. Browsers need some really obvious way of flagging session as secure or not (coloured boarder around the page?)

Even this will not solve all the problems because SSL only verifies that the site name in the url is the one registered to the site. Bad guys can (and do) get certificates that are then misused in phishing scams.

Ultimately people have to check the site name and follow the standard instructions issued by all banks to be safe.

The use of 2FA for transations also helps but does not fully mitigate the problem -- it just forces the attacker to jump through more hoops.

Posted by: Russell Fulton | July 12, 2006 5:35 PM | Report abuse

A few more ideas to consider:

1. Any point-to-point security can be broken by MIM attacks so long as the MIM can duplicate the security measures. A cryptographic scheme not published to the public would slow down this ability for a time. Then layer multiple schemes to make it even harder.

2. Banks could produce custom software that does not use HTML or HTTP. Since the bank owns the software DNS spoofing attacks do not work and MIM is impossible.

3. Users register their computer with the bank. Access is granted to that user at that IP. Initial access can be setup at a secure location (e.g. a bank branch) using an OTP.
Obviously the IP would require a subnet mask that covers the ISP's range for the user's area, but only that ISP's customers would be able to access the account, greatly reducing the pool of potential attackers.
To get around IP spoofing (hacking together a network data packet with invalid return IP), the webserver can use a ping-like method to validate the user is where they say they are. Yes this open a port, but only after the user attempts to log into the site and only until the server sends the "ping." This could validate the server to some extent as well.

Keep in mind that every option discussed on this page is but the dreamers' dreams. I know for a fact that there are even more and better systems coming -- and soon.

No matter the dilema, don't get discouraged. A way has always been found and will continue to be found that minimizes trouble for everyone.

"Every time someone creates a fool-proof system, the universe creates a better fool to break it." - Unknown

Posted by: Bob | July 12, 2006 5:48 PM | Report abuse

My solution is somewhat more arcane. Why not find the miscreant(s) and remove them, their living ancestors and progeny from the gene pool? Bullets are much less expensive than trying to replace your stolen money or rebuild your credit.

Posted by: OldWestJustice | July 12, 2006 7:50 PM | Report abuse

I am a CitiBank Business Customer and have the code generator. The problem that EVERYONE is ignoring is that the original SPOOF message (as shown in the picture at the top of the article) has failed the CitiBank "Valid Email" check. If you look in the upper right of the image (and read the warning at the bottom of the image) you will note that the last word in the box is "Verify" NOT the correct last 4 digits of the user's ATM Card. ANY message that lacks this 4 digit number (or which has VERIFY or something else there) is a SPOOF and not a valid message from CitiBank. If you follow the URL at the bottom you will find a message from CitiBank EXPLAINING THIS.

Posted by: Bob Rosenberg | July 13, 2006 12:45 AM | Report abuse

Try this, using challange response feature that some of OTP token has.
Challange code is 6-12 last digit of the destination account. Although i think challange and response algoritm for today tokan need to improve, eg try to input the same number, the response will always the same.

Posted by: SkyWalker | July 13, 2006 4:55 AM | Report abuse

The token password expires within 1 minute and cannot be reused again. So, the culprit has to be very fast to reuse the captured token password. A solution is to reduce the rotating period from 1 minute to 15 seconds. This is not a perfect solution but can temporarily reduce the risk to an acceptable level, until a better permanent solution comes out.

Posted by: XL | July 13, 2006 12:08 PM | Report abuse

SkyWalker: the challenge could be combined with the current time with allowance for some clock drift.

Posted by: Joakim Bengtsson | July 13, 2006 12:27 PM | Report abuse

XL : actually OTP token has other mechanism which is Anti Replay Attack. with this if the password already being used, it cannot used again until it's expire. But in the MITM attack it is posible to change the data before passing it to the real web, and it's fast enough.

Joakim Bengtsson : it's a good suggestion.

Still the best solution is Bob Rosenberg, people need to be aware on what he/she click/receive :))

Posted by: SkyWalker | July 13, 2006 10:15 PM | Report abuse

I guess any authentication system relies on a secure channel. Success of MIM means the channel is not secure. One practical solution may be "out of band" or second channel for the communication between the two ends. The implementation could be SMS message to a pre-registered mobile phone for delivery of an OTP. It is not 100% secure as the MIM can be in both channels at the same time, theoretically. But, do we expect 100% secure in the authentication, or any defense, while we don't see the warware will cease in the near future?

Posted by: KTY | July 14, 2006 9:39 AM | Report abuse

Hello Brian,we have "the" solution:
use server-based computing. The code of the programm you use runs not on your machine,
and to compromise this code might be not impossible, but too expensive. Combine this with a biometric authentication method. Roland Sassen

Posted by: Roland Sassen | July 15, 2006 6:48 AM | Report abuse

The problem here is that the request was for MULTIFACTOR not Dual or two-factor. Multifactor should have prevented this as well as a properly layer-7 firwall which should have caught that the phishers were spoofing the session.
With multifactor, a trust factor would have caught that the users were logging in from overseas and no the US and would have forced additional security validation.

Posted by: Eric | July 17, 2006 4:08 PM | Report abuse

The phishing has become a great issue nowadays. Though there is two-factor authentication, the advancement in technology makes the phishers invent a new technology to carry online fraud. So its good to have our bank passwords to keep on changing constantly. Also the user should be able to have their passwords set in a way that it should be hard to think for the hackers. Somepeople they keep their passwords easily which could be guessed easier. If a password is say alpha-numeric like #(r%78ju29*) then it would bit difficult for the hacker to get this. Really a nice article which is pretty good to know about security.



Posted by: Yuvaraj | August 1, 2006 12:58 AM | Report abuse

How can I verify username password using PHP code ?

Posted by: Nasim Ahmed | August 21, 2006 5:54 AM | Report abuse

The only real solution is use something one off, that can not be duplicated, cannot be stolen, and ties together to entities. The solution someone mentioned about using strong passwords, would be easily broken by a trojan key logger or MIM. The only serious contender is the transactional based authentication. The user would enter the amount and recipient account number into the site and then enter the same into the token generator. The same algorithm is applied and the token is generated with amount and recipient details hashed together. This token is entered into the site, where it is de-hashed, if the details entered don't match the de-hashed result, then the transfer is blocked. The only downside to this is the strength of the hashing algorithm. I would expect the hashing algorithm to contain a datetime stamp as well to ensure repeating transfers do not generate the same hash. It would also need to incorporate the customers bank number or other number unique to the customer.

Posted by: MikeF | September 15, 2006 11:41 AM | Report abuse

I just wonder the security of the usb token.How can we make sure the driver connect our usb is the truth one ,but fake one,or Trojan horse.So I cannot belive the use of usb token.

Posted by: JONE | September 26, 2006 4:08 AM | Report abuse

One thing Microsoft is looking to do as part of their new identity initiative called "CardSpace"/"info card" is to extend X.509 certificates to include a site image. So they would have the benefits of the Bank of America "SiteKey", but it is actually signed into the certificate (used for TLS/SSL) with a digital signature so it cannot be proxied in a man-in-the-middle attack.

The thought is that having a picture to authenticate the server is more intuitive to most users than trying to verify the domain name, trusted CA and expirations etc.

This seems like a step in the right direction - there is no silver bullet.

Posted by: Tom | October 3, 2006 12:58 PM | Report abuse

The comments to this entry are closed.

RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company