Friday, August 11, 2006

Citibank Hardware Tokens Defeated - but don't blame the tokens

A post today at Bankwatch » Citibank Hardware Tokens Defeated: The Beginning of the End
pointed to an AllPayNews article about the weakness of physical tokens (like the RSA SecurID). The article talks about how Citibank's online banking security was defeated by a fairly simple phishing method, despite the use of physical tokens.

As it turns out, the article was a push by a security token vendor, PhishCops. In any case, it did point out an apparent weakness of SecurID type security tokens when implemented without other anti-phishing measures.

According to the AllPayNews article, the scam worked like this:
In a textbook example of a "man-in-the-middle" attack, Citibank business customers were lured to dozens of counterfeit websites located in Russia where they were prompted to supply their token-generated passwords and other credentials. The counterfeit websites then swiftly sent the solicited credentials to the genuine Citibank website where they were used to access the accounts.
For background on tokens, see my recent posts around electronic signatures and the use of physical tokens
to strengthen the standard username/password pair for user authentication at online banking and other financial sites.


How did this work?

A valid Citibank online service would prompt the user for their standard login details, an account ID and password. Knowing which account the customer is attempting to access, the service now requests a one-time number to be entered from the user's token. SecurID and similar tokens rely on a user specific number being generated that remains valid for 30-60 seconds after being displayed on the device's LCD screen. The user enters this number into the online prompt, confirming that they are in possession of the token. The two-factor approach, an item that is memorized (password) and an item that is in-hand (token) ensures the authenticity of the customer.

The problem is that the scam used an advanced phishing approach. Not only did the scam direct customers to a website that presumably appeared exactly like a Citibank website, prompting them for all of their credentials, it immediately used these to access the real Citibank online service with the provided information. Assuming that the scam site completed this within the lifetime of the one-time password (30-60 seconds), it would be successfully authenticated, enabling the scammers to perform fraudulent transactions on the customer's account.


Tokens don't work?

Tokens with a limited lifetime passcode are still very valuable devices to ensure authentication of users. Even if both password and one-time passcode are stolen, the fraudulent user has to exercise them in a very short amount of time. Certainly this is a strong barrier preventing many keylogging and phishing attempts, but as is demonstrated here, not all.

The problem is that tokens don't close the loop. Although the banking service can confirm that the user credentials entered truly are the two-factor identification for the customer, the customer still has no way of being sure that the site they are entering this information into is real.


Need to prevent users entering credentials into fake sites

It is essential that online services provide a mechanism for very obviously confirming to users that they are using the real site. Educating users to study the URL is really insufficient. Anti-phishing toolbars are also an option, but since many users who travel may use PCs that are not their own for access to online services, this is also impractical to depend on. A good option is the SiteKey as used by Bank of America.

SiteKey is a way of demonstrating to a customer that they are looking at a valid BoA site. When attempting to login, the only information requested on the front screen is basic ID, the account number and state you live in. This is submitted to a the secure site, which retrieves a picture and a phrase. These two items were selected by the user when the online account was setup, and are only known to them. Users learn that they should only enter their password if they see this personal SiteKey. The SiteKey page shows how this works visually.


PhishCops goes a step further

The PhishCops 'virtual' token claims to be able to counter phishing sites, since even if the user's credentials are handed over, fraudulent use of them is impossible without the PhishCops token on the user's PC. PhishCops is not a physical device, and claims to be purely browser based.

The 'how' is not entirely clear to me, but it seems to be done by handling two way authentication and authorization of specific user PCs (I wasn't going to open the MS Powerpoint presentation to find out). It seems that the secure site presents a one-time key that the user enters into PhishCop, then the virtual token returns a one-time passcode to be entered into the website. This seems like a great idea, since it validates to the user that the website is real before they ever enter their credentials, and validates to the website that the token and user credentials are real.

The downside that I see is the need to pre-authenticate different computers that you want to use with the system. The process for performing this, and its complexity is not clear. I also wonder whether keylogging software, and scripting hacks could also break the system. A physical token is powerful since it is completely separated from a PC.


Summary

Physical tokens are not dead. But as the Citibank example has shown, without providing additional layers of protection to users to help them avoid phishing, a well crafted, realtime scam can defeat even this two factor authentication.

If Citibank had used a site authentication approach like SiteKey to prevent phishing sites easily convincing user to give up their personal credentials, it is likely that there would have been no question about the security of their physical tokens. SiteKey is not perfect, but probably reasonably effective.

PhisingCops may provide an approach, though I am wary of software based tokens as being thoroughly secure. Unfortunately, a hardware equivalent may be more bulky and expensive to produce and distribue. Banks will need to balance the risks and provide as much information as they can to users to protect them online.


Technorati tags:

4 comments:

Fredric G Gale said...

Thanks for that informative blog. You're right, of course, about the shortcomings of tokens, and I want to mention that there is another way that's new:a radically different anti-keylogging tool that encrypts the user's keystrokes at the kernel driver level, below the level where keyloggers can record them. Then the keystrokes are decrypted within the browser itself, so that any keyloggers will only record indecipherable, encrypted keys. This method works against known and unknown keyloggers and can protect more than just the user's login information. Free download at keyscrambler.com if you care to look at it yourself.

Randy Janinda said...

There is a common theme I am seeing in blogs that talk about phishing and authenticating the users/clients. Each one posts about how important it is to verify that the end user is who they say they are. Your blog started to touch on the other answer (with SiteKey) which is how does the end user know the bank is who they say they are. The online application providers (in this case banks) have a responsibility to "authenticate" as the end user. We cannot continue to expect the end user to jump through hoops (as you pointed out) by learning how URL's are constructed, or installing more toolbars, or adding more software, etc.

Anonymous said...

Does anyone know how bullet-proof the PhishCops machine authentication is? It seems to good to be true (no keyfob or software or client cert).

It strikes me that, if no software is installed, only a cookie (which is easily forged) or the information sent by your browser (which is not unique and can change if you update .net for example) can be used by the web server to identify a machine. Or am I missing something?

Anonymous said...

I don't see how a sitekey proves the user is on a BofA website. What prevents the fake site from grabbing the sitekey from the real BofA site?