OK, so I’ve been getting some flak from my post the other day about two-factor authentication and phishing. Pete Lindstrom over at spire gives me the wagging finger on the issue, saying that just because there is one phishing site using two-factor, it still has value; Mike Rothman over at Security Incite sides with Pete, pointing out that there is a security benefit to two-factor and saying that we shouldn’t downplay it because of one event. In light of the criticism, I thought it would be a good time to point out why I hold the position that I do – since I didn’t really do a full job of explaining my point in the previous post (at the time I wrote it, I didn’t think it would be so controversial) I think it makes sense to more thoroughly explain it.

Anyway, let me start by saying that I think both Pete and Mike are very astute analysts. More than that, I think they’re right: two-factor does have tremendous value from an overall security perspective. And suggesting that two-factor has no security value whatsoever would not be accurate or useful to our industry. However, I think it’s important that we, as users of these systems (and ultimately the folks who will bear the cost) stay focused on where the value of two-factor is – and where the value isn’t.

Historically, vendors have told us that two-factor will eliminate the phishing threat. For example, Microsoft said “If you get two-factor authentication to the consumer level, you reduce the phishing threat”, RSA said “Providing consumers with two-factor authentication… protects against phishing and identity theft” and Entrust told us that their solution would “provide identity theft protection and protection from phishing attacks.” Journalists told us that “The forced use of two-factor authentication for banking systems accessible over the Internet is our only hope for the mitigating the phishing threat” and the Anti-Phishing Working Group told the DHS that two-factor auth was a key step in preventing phishing attacks. When somebody suggests “forced use” of something, you probably want to make sure that it does in fact solve the problem in question. So does two-factor do these things? The answer to this question is the crux of the point I made the other day.

You see, just because a tool is good at doing one thing doesn’t mean it’s good at everything. For example, a pipe wrench is useful, but probably not for changing your tires. Sure, a pipe wrench can be used to turn nuts and all, but try to twist a lug-nut with it and you’ll get frustrated pretty quickly. It’s all about choosing the right tool. I think two-factor is like a pipe-wrench: a good tool for one thing (authenticating users), but not for doing other things (authenticating institutions). If the reason phishing exists is because of insufficient client authentication, it would be a great tool for phishing. But that’s not the cause of phishing. The cause of phishing is lack of server authentication. In other words, more authentication of the user doesn’t solve the problem. Sure, maybe it helps a little bit – maybe it makes it harder for a phisher to attack a given institution – and in so doing causes phishers to go after “the other guy.” But does it, like RSA and others said, “prevent” it? Clearly the answer is no, since somebody pulled it off the other day. Is it really our “only hope” like we were told by SecurityFocus? I hope not…

So, while I’m not saying that two-factor is completely valueless, I am saying that we should probably re-evaluate our assumptions about whether or not it solves phishing – particularly in light of direct evidence to the contrary.

Apparently, a phishing site has been found that allows phishers to take advantage of users even when two factor authentication is employed. Here’s what happens – you get an email telling you to follow a link to “your bank” (really a bogus site.) You connect to it and enter your two-factor authentication data. The site then opens a connection and uses your credentials to log in. The result: your bank account gets drained even though you used a second authentication factor. It’s a little more complicated than a regular phishing scenario, but not rocket science.

This proves the point that I’ve been trying to make for the past two years – namely, that the reason that phishing works is not because we don’t have sufficiently robust user authentication. No, the reason that phishing works is that we don’t have sufficient authentication of the server. Mark my words – you could use as many user authentication vehicles as you want and phishing is still a possibility.

Man I love being right.

Today, I saw a press release from Green Armor hyping that Six Credit Unions Choose Green Armor Solutions’ Identity Cues Two Factor for FFIEC and NCUA Compliant Two-Factor & Two-Way (Mutual) Authentication. Do I even need to say why this irritates me?

You probably already know that it infuriates me when vendors use FFIEC guidance to try to sell product. Green Armor is in that camp – they set the tone in the title (“Two Factor… for FFIEC… Compliant… Authentication”) and progress from there:

Identity Cues Two Factor will allow the credit unions to improve authentication for online banking and to meet new FFIEC and NCUA guidelines without sacrificing user friendliness, and without having to endure a complicated and costly enrollment process… they provide strong two-factor authentication (exceeding FFIEC guidelines) as well as effective two-way (mutual) authentication that protects against phishing, pharming, and online fraud…

Clearly, in order for something to be “compliant”, the implication is that there is a regulatory mandate to which they are responding. In this case, Green Armor is implying that there is a mandate from the FFIEC 2005 that two-factor be used; more specifically, the claim is that the 2005 Authentication Guidance requires that FS institutions implement two-factor authentication and that Green Armor helps companies fulfill their required, mandatory, activities. Far be it for me to point out that documents entitled “guidance” are rarely prescriptive. But, let’s take a look at the document anyway, shall we:

“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.”

Look at that phrasing: “where indicated…”, “or other controls.” Decisive. Powerful. Prescriptive. What’s that – not decisive or powerful at all? Maybe not. Let’s compare that language with something that is a clear mandate; something that FS is unambiguous about. How about SEC Rule 33-8590 governing Edgar filings and reporting:

We are requiring that certain open-end management investment companies and insurance company separate accounts identify in their EDGAR submissions information relating to their series and classes (or contracts, in the case of separate accounts). In addition, we are adding two investment company filings to the list of those that must be filed electronically and making several minor and technical amendments to our rules governing the electronic submission of filings through EDGAR.

Now that seems more prescriptive to me: “We are requiring…” compared to “where indicated”, and “that must be filed” compared to “should implement multifactor … or other controls”

For humor value, substitute the same clausal structure into this Rule as is used in the 2005 Authentication Guidance. The rule now reads like this: “When necessary, investment companies should separate accounts identified in their EDGAR submissions information relating to their series and classes or identify separate accounts through other mechanisms.” That’s the same thing, right?

OK, you’ve all heard of phishing. New, and probably growing, is pharming, which seeks to use other means to send users to bogus websites. Quoting from the Register article’s advice on how to mitigate the problem, this stands out: “Banking sites could adopt two-factor authentication as a comprehensive defence.” And it’s not just el reg saying this either: Microsoft is saying it along with pundits at RSA.

Here’s the straight dope: identification of the user is not the problem. It’s identification of the institution that is at issue. I won’t go into the numerous ways that phishing is still possible even in a world of two-factor authentication – it would take too long to go through all the ways that it can still happen; suffice it to say that it is not only possible, but likely that phishing would still occur even in a world of ubiquitous two-factor user auth. In other words, phishing is about fooling the user into thinking that the rogue site is the real bank when it isn’t, not about fooling the bank that the hacker is the real user when it isn’t.

What we need, instead of more user authentication, is some authentication of the institution. And guess what? The current protocols in place for HTTPS support this already; it’s already there, just not being used! Really, in order to support SSL, Bank of America has to get a cert from a (semi) reputable party that is stamped “BANK OF AMERICA” all over it. The problem isn’t that the information isn’t there, it’s that today’s browsers do not expose any of that information to the browser user – all the user sees is a lock icon. Divorced from all of the other associated data, the lock icon is binary – it’s “secure” or it isn’t. The question is: secure from what? If the lock icon is there, the session is secure from eavesdroppers but not necessarily secure from anything else (like impersonation.) If the words “BANK OF AMERICA” appeared next to the lock icon (or even at the top of the browser window) for the legit BOA site and came up as “shady h4xx0r” (or whatever the bogus site’s address/owner information is) for bogus sites, do you think people would be as succeptible to this crap? I don’t.

So, in conclusion of this rant: more user auth vs. more site auth? I see it like protecting a house. If your house has a front door which you keep locked and a back door that you keep unlocked, and robbers keep coming in through the back door – is the answer to put another lock on the front door? Of course not. But that’s analogous to what’s being proposed here and what’s being proposed by the industry. It won’t solve the problem.

How much do I love this? Phishers getting trounced by defacing groups; all in all, I think it’s probably less about defacers turning away from the “dark side” as giving them a ripe target on the open Internet that they can’t get busted for defacing and that will get them media attention. Unlike the reporter covering this, I think this activity is likely to increase given that fact.

TriCipher put out a press release today saying that they prevent phishing. I’m not sure that these people are really clued into reality. Why do I say this? Here are a few reasons:

1) Saying Eric Greenberg is the “one of the developers of the SSL protocol” is an interesting turn of phrase. Quoting Eric himself, he was “Group Security Product Manager for Netscape, where he led the rollout of the SSL protocol.” Project Manager? Rollout? Is Project Manager the same as Developer? Just as an exercise, take a look at the SSL 3.0 spec, is Eric’s name on it? Wonder why not…

2) This press release does not address all types of phishing – it’s careful to remain limited to “man in the middle phishing,” which is arguably of less usefulness than regular run of the mill fishing. “Man in the middle phishing” is a scenario where the fake phishing site proxies the logon page in real-time in order to steal the credentials. Describing it, the press release says “The phisher’s server automatically uses this information [the stolen credentials] to immediately log in to the legitimate site, then either keeps the session open automatically until the phisher is ready to hijack the session or simply alters the user’s transaction to benefit the phisher. ” How often do we see this type of phishing, where an attacker puts up a page that looks like (but isn’t) the legitimate server? Personally, I have yet to see this scenario in action. Regular phishing, where an attacker puts up a page that looks like the legit site, but isn’t is much more effective (and much simpler for the attacker to implemen.t) This isn’t addressed by TriCipher.

3) The press release says, “Further, using SSL means no new software at the web server, making deployment fast and easy.” What they don’t say is that in order to support this “easy deployment” we need to effectively replace the plumbing of SSL on machines that wish to connect to the webserver. It’s true; it took me a while to get there when I was talking to their chief scientist at RSA, but eventually he agreed with that. Read between the lines on their product page. This page says that only “double armored” protects against phishing; “double armored” (following the link to see what “double armored” means) is the one where they split the certificate private key up into two parts. Note that this is not the way SSL currently works. In order to get SSL to behave a different way than the way it behaves today, you need to supply underlying software that does this (either through a browser plug in, activeX control, etc.) Installing new software on a client machine is problematic.

The reason that phishing works in the first place is that end-users aren’t necessarily clued into the technical reality of what’s going on under the hood of a web connection. If they did, they could spot an obfuscated URL or a bogus email and not start the bogus transaction in the first place. Now, these same users are expected to replace the underlying socket plumbing in their browser and we expect no support calls about this?

I’m not expecting TriCipher to be used for anti-phishing. I could be wrong, but I’m not sure this is the right solution to the problem.

Citibank and their customers are the latest victims of a spam/redirection attack.

In the past the email subject, mispellings in the email, and link URLs have been dead giveaways that the email is fraudulent. But recent spams have become more sophisticated in an ongoing effort to trick users into parting with their account and password information.

It’s becoming harder for users to discern what communiations are legitimate. Best rule is to *never* click a link that doesn’t look valid and don’t give out any account information unless you’ve typed in a site’s URL yourself and are sure it’s a site you trust. It’s not a 100% guarantee, but it’s a start.

An IDG News Article at NW fusion reports: Fake bank Web site scam reaches U.S. This one targeting Bank of America customers. Though it could have been any bank.

Take a look at the URL of a site before entering personal information. It’s not a foolproof protection, but it’s a great place to start.