channelregister.co.uk — A bogus security warning ostensibly from Citibank, and targeting customers of its Citibusiness service, urged prospective marks to visit a website and enter not only their account details and password (as with conventional phishing scams) but also the code generated by the customer's token. These authentication key codes change every minute or so.
Jul 15, 2006 View in Crawl 4
gohoosJul 15, 2006
SecurID has always been vulnerable to a race-condition attack. If your attack program monitors the code entry and opens 10 separate threads which simultaneously enter the code as the mark enters the digits, then enters each unique last digit before the target does, thereby gaining access.The method in the article is much less creative - grab the current code and use it within 60 seconds - and easily fixable. Some of the ACE clients do this anyway - every so often they ask also ask for the NEXT code on the card. Or maybe it's time for a hard-wired token.
johndiJul 16, 2006
Sorry that comment was supposed to be a reply to the one below.
roustkJul 16, 2006
The really real solution is even simpler: use software like RoboForm (on Windows) or 1Passwd (on Mac OS X) to login to bank and other websites. Not only this software helps again phishers, it protects against keyloggers as well.Disclaimer: I created 1Passwd and might be a bit biased.
terrenceshawJul 16, 2006
They did bet the RSA system by acting as a middle man and authenticating against the real sight to log in. Once loged in they can change the password, etc...The actual URL they used had citibank in it but was a domain in Russia so if you looked at the URL you could tell the sight was fake.
bubba_Jul 16, 2006
And it was not reported that this was an RSA token, it could have been another two factor token (perhaps secure computing). We had an RSA rep on site last week and I asked him about this and he said that Citibank does use RSA tokens, but not for this particular setup.
againJul 17, 2006
This issue was previously covered:<a class="user" href="http://digg.com/security/Phishers_Defeat_2-Factor_Authentication">http://digg.com/security/Phishers_Defeat_2-Factor_Authentication</a>There are three parts to the solution to this problem. The first is the existence of the SSL protocol which allows the authentication of remote hosts. This is the part of the solution that we already have. The second part is that we have to get the implementation of SSL correct both in terms of the browser interface (to make it as absolutely easy as possible for people to follow very simple and clear rules to work out whether or not they are dealing with a site they can trust) and in terms of the PKI infrastructure (to reduce as much as possible the opportunity for failure in this area). I think a lot of the elements of this part of the solution are already in place and there is work progressing on the others -- ultimately perhaps the thing which will slow this down the most is the deployment of browsers which implement these sorts of things and getting these out to enough people to actually make a difference. The third part of the solution is user education, specifically getting them to know how to interact with the browser in a reliable way and also to be able to verify the identity of the site they're dealing with by doing things such as checking the name of the site on the certificate. Of course, this third part of the solution has proven to be the most difficult but ultimately if people continue to lose money then perhaps they will eventually have enough incentive to take sufficient care!
bluebruinFeb 1, 2008
Just a quick note. I know that the RSA tokens were defeated directly, but the point isn't that. The point is that the RSA tokens were rendered moot, thereby being defeated. If the RSA token is designed to prevent a phishing attack from happening and a phishing attack happens, whether the token itself was manipulated is not relevant. What is relevant is that the Toke didn't do its job. Here's the reason why: Tokens and other authentication solutions only deal with the end-user. It makes the end-user authenticate , but it does NOTHING for making the server authenticate itself. What do we know about most end-users? They're all just not savvy enough to know when they're either being phished, or when their information was compromised. The key is bi-lateral, or as my company likes to call it, mutual authentication where you know you're logging into the correct server.The RSA token, or other tokens, are sucepitble to not only phishing, but Man in the middle Attacks. All you need is a proxy set up between the end-user and the server. That can be done easily by poisoning DNS where you're taken to a different place without knowing it. With the MIT attack, the information is relayed immediately. Yes, there's a guy there doing it, but the point is that the Token can be circumvented. Phishing can also happen. 60 seconds is plenty of time for someone gathering that info to log the information and get in. It's harder, yes, but it's doable nonetheless. All this is happening, because the user doesn't know he is in the wrong place!!!!! How to educate the user? Raise the level of security. Use Digital Certificates. PKI. Yes, but PKI is just not practical. True, but what if there was something that could make it practical???TRY THIS : www.multifa.com This is digital certificate protection, without pki hassles. This is non-phishable, browser-based, but also, it's BI-lateral authentication. Now the USER knows that he or she is in the RIGHT place. And it's all goign on in the background, without a hardware token or anything of the like.
bluebruinFeb 1, 2008
BY THE WAY, I wrote that incorrectly; it should say that I know RSA tokens weren't deafeated DIRECTLY.