» Archive for July, 2006

Problems we should solve instead of stronger authentication

Friday, July 28th, 2006

I want to pick back up on the discussions from a week or two ago about what threats authentication can protect against. The driver for two-factor authentication to protect on-line banking from phishing attacks is that it makes phishing harder, but this has already been broken up to and including Secured Hard Tokens.

As I see it, this should really be a wake-up call that the security industry’s authentication strategy needs to say (among other things), it’s time to get over the obsession with authenticating the User and focus instead on the actual threats. First, we should be deploying & using mutual authentication. The reason that Man-in-the-Middle attacks work is because it’s easy to impersonate a server

Overcoming this inertia is going to be hard, because there are a lot of vendors making a lot of noise about how all we need is stronger authentication, by which they usually mean moving away from free credentials (passwords) to expensive credentials (tokens, biometrics, or commercially-issued certificates) which they, of course, would like to sell us.

That’s not to say that there’s not a lot of value in the second factor, but more in some cases than others. Two-factor, combined with pre-shared keys to perform mutual authentication provides excellent protection for VPN connectivity. But in phishing, Two-factor only raises the bar for an attacker, and only to the extent of filtering out the dumb ones. Even they will get toolkits in six months or so, though, and fraud will return to “normal” levels.

Unfortunately, the reason that free credentials seem to be failing is generally because people lack the necessary sophistication to protect them, not because they’re somehow inherently weak. Application vendors are trying to solve this problem (Both Firefox 2.0 and IE 7 are both going to have anti-phishing features). This may help, but only by minimizing the impact of the weakness between the keyboard and the chair, not the client and the server.

The best way to tackle this problem is to minimize the reliance on the weakest link (the user). I don’t claim to have a solution (other than pre-shared keys or some sort of meaningful large-scale PKI, and anyone who reads this ‘blog probably rolled their eyes as soon as they read those words), but If we can get general agreement that there is a problem, then there will be demand (paying customers) for a solution and one will turn up sooner than later.

Personally (and I know I have a bit of a bias here, being a big de-perimeterization fan), I think that another problem we should be taclking is the that endpoint location should be irrelevant. Within the corporate world, we operate under the paradox that we don’t consider “somewhere you are” to be an authentication factor, then structure most of our risk and security assumptions around which network the endpoints are on (Internet, Intranet, DMZ, etc.). I know it will take significant architectural changes to get to an endpoint-agnostic model, but every journey begins with a single step.

Finally, I believe we should apply security as close to the data as possible, which is fairly congruent to “Location should be irrelevant.” How does stronger authentication move security closer to the data?

As to what we can do about it, I think that promoting protocols which support Mutual Authentication (and using them) should be a key tactical goal for the security profession. This is something we can do today which would will put us ahead of the game longer-term as the security assumptions inherent in “somewhere you are” evaporate.

Eventually, we will be forced by events to secure both high-value transactions and high-volume micropayments (think vending machines). We need to be ready for either or both of those, and the current obsession with stronger authentication isn’t going to get us there.

So here are some Real World goals I suggest we should be looking at.

  1. Improved authentication should focus on (cryptographically) strong Mutual Authentication, not just improved assertion of user Identity. This may mean shifts in protocols, it may mean new technology. Those are implementation details at this level.
  2. We need to break the relationship between location & security assumption, including authentication. Do we need to find a replacement for “somewhere you are?” And if so, is it another authentication factor?
  3. How does improved authentication get protection closer to the data? We’re still debating types of deadbolts for our screen door rather than answering this question.

One-Factor, Two-Factor, Red Factor, Blue Factor

Tuesday, July 11th, 2006

It’s not as fun to read as Dr. Seuss, but in October 2005, the FDIC declared single-factor authentication inadequate for online banking authentication:

  • Single-factor authentication methodologies may not provide sufficient protection for Internet-based financial services.
  • The FFIEC agencies consider single-factor authentication, when used as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
  • Risk assessments should provide the basis for determining an effective authentication strategy according to the risks associated with the various products and services available to on-line customers.

IanG at Financial Cryptography recently noted and added valuable commentary to a WashingtonPost.com blog entry about how phishers have already adapted to this countermeasure WaPo sets it up:

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.

But IanG adds the value:

More bad news for suppliers of 2-factor tokens and also US Banks which got a quasi-recommendation to implement something like this. I say, quasi-something, because the FDIC carefully did not recommend any specific technology, choosing instead to recommend that banks carefully review their _risk-based exposure_. The banks themselves may have assumed tokens or similar, for whatever reason.

(emphasis mine)

Of course, you would never know that the official guidance specified only that the bar had been raised (no more single-factor), not what it had been raised to (Buy two-factor authentication products!) unless you went and read the guidance document itself–not a difficult task since it’s only one page long and it’s the first result if you google for “fdic authentication”. (The Account Hijacking page is the second link, btw)

Also interesting, though, is that the FDIC did recommend two-factor authentication–in December 2004! If you look at “Putting an End to Account-Hijacking Identity Theft, an allegedly consumer-targeted page (but which talks a lot about things like log analysis and infrastructural analysis opportunities), they say:

Financial institutions and government should consider a number of steps to reduce online fraud, including:

1. Upgrading existing password-based single-factor customer authentication systems to two-factor authentication.

Of course, that report also speaks well of SenderID, so we would all be well-served to remember what become of that Silver Bullet.

Personally, I agree with IanG. It’s not the FDIC’s place to provide prescriptive guidance in this situation. It’s one thing to provide a common problem statement, “Single-factor authentication is not adequate.” Unfortunately, the people least likely to understand that there are many ways to provide a second authentication factor besides hard tokens are also the ones most likely to fall for the vendor pitch that some sort of hard token is the only second factor.

I will never know why the FDIC decided to pull back from “upgrade…to two-factor” to, “Risk assessments should provide the basis for determining an effective authentication strategy,” but I strongly believe it’s the appropriate approach to the problem. Banks do a lot of things, some visible and some not-so-visible, to reduce the risk of a successful breach (successful probably being defined as funds successfully transferred beyond recovery or large-scale enough to make the press). Since no two banks have the same set of risks and countermeasures (remembering that risk is the combination of asset value, threat & probability along with varying opinions of what is or is not an externality), no two banks should come to the same exact solution set, even if their risk position seems identical to an outsider.

Maybe someone pointed out that they guidance would remain and still be adhered to by the less-informed long after it had been overtaken by events. To reinforce that argument, on October 12th, 2005 (the same day that FIL-103-2005 was published), the Register had a story about phishers successfully compromsing a one-time/scratchpad system in Sweden. Perhaps a coincidence, but it would have been a bit ironic if the FFIEC had issued prescriptive guidance at the same time as that guidance (in the absence of other compensating controls) was shown to be inadequate.

John Quarterman at Perilocity has now picked up on this, as well.

Updated: Fixed the missing link, added a title and intro tie-in

Net Neutrality made simple

Saturday, July 1st, 2006

Dan Kaminsky has a
great essay on why Net Neutrality matters over at ComputerWorld. If you’re not aware of this issue (and even if you are), go read it. It’s one of the more accessible explanations of the debate I’ve seen and provides some excellent analogies for introducing the concept to the uninformed.

“Oh, sure, there’s UPS and DHL and the US Postal Service. But imagine if they were all proposing that, because people make money based on the contents of packages other people shipped, that they should see some of that money. Imagine they implied that, if you or your company did not pay a reception fee… well, things might happen. Packages might get lost, you see.

“Now imagine they informed you that they were going to deploy equipment that could analyze the contents of the packages they shipped. A six-ounce letter might contain a multimillion dollar contract, while a twenty pound box might just have some intern’s new laptop. Suppose their equipment could tell the difference. Would you pay to not have that contract “lost” in a sorting facility?

“Of course you’d pay. You’d also pay not to have your knees broken. But kneecap integrity should not be a business expense.”

Just read it.