Hans gets more specific about Yahoo BBAuth

Several readers have asked me to comment on the recent post by Verisign's Hans Granqvist about “security problems in BBAuth”.  He writes:

I have had concerns about Yahoo!’s choice of security of BBAuth. Jeremy Zawodny responds to my posting to ydn-auth list:

“While I can’t comment on the choice of algorithm, I can say that some of the technology used in BBAuth was not developed solely for use with BBAuth.

Okay, fair enough.

But then he continues:

“In other words, we’re reusing some existing stuff that’s been tested in the field and proven to work well for our needs.”

Now, this doesn’t sound right. Not at all.

MD5 has been broken for a few years now. According to Ferguson’s and Schneier’s Practical Cryptography it’s possible to find MD5 collisions in 2**64 evaluations (using the birthday paradox). This was too easy 2003, and it sure is not more difficult now.

Be that as it may. Perhaps these collisions are purely academic.

What’s worse is the lack of a proper HMAC. In Yahoo!’s BBAuth, the MAC is created by hash(text + key) where ‘+’ denotes string concatenation.

This simplistic way of building a pseudo HMAC scheme is not secure. Readers of Practical Cryptography may want to turn to section 7.5 for more information. In short, tacking the key on to the end leads to key recovery attacks that are much easier to execute than they should be.

What scares me is that this broken scheme apparently is used in plenty of other Yahoo! products. I would not be surprised if there are attackers trying to exploit this weakness at this very moment.

My advice to Yahoo! is to change this to a proper HMAC right now. Other identity protocols, like OpenID manages to require HMAC-SHA1 or HMAC-SHA256. There are OpenID libraries for all major programming languages available, so it’s definitely not too hard to implement.

My thinking?

I believe that when it comes to security, it's better to use an algorithm that has been widely vetted (like HMAC-SHA256), and to avoid creating new ones unless you really need to – or have a long runway to test them on.  I also think protocols should use algorithm identifiers.  With security, it may become necessary to migrate to new algorithms when we least want to, without blowing all the downlevel clients out of the water. 

But despite my “high-minded principles”, if you look at the actual content of what Hans calls “text” in the BBAuth protocol, it looks to me like it is full of entropy (a good thing): although it contains some fixed information, it also contains a token, which is variable and not calculable by an evesdropper; a timestamp, which makes long-running attacks impossible; and a shared secret, which makes multi-site catalog attacks impossible.  So this is not toy cryptography given Yahoo's purposes.  That isn't to say Hans doesn't make some good points.

My concerns really originate with the user interface issues.  And OpenID has the same problems to the extent that people end up with multiple identity providers (which they will).

I'm talking about the fact that users are redirected from one context to another quite different one.  We have found that systems that work this way introduce a lot of “noise” – let's call it ambiguity – into the channel between the system and the user. 

The user can be confused – by accident or, worse, on purpose. 

It's the “I'm-buying-a movie-from-someone-but-now-I'm-at-Yahoo-and-now-I'm-not” problem.  In the midst of the redirections, the user can potentially be redirected to a wolf-in-sheep's-clothing, who can relieve her of her secrets and employ them for other purposes. 

Suppose that Google and MSN and AOL and eBay all do the same thing as Yahoo.  Then things would get really confusing for the user, wouldn't they?  As she visits different sites she would find herself redirected to a bunch of different home pages…  MSN here, AOL there, and who knows what else.  This kind of redirection is just not good from the point of view of users being certain about what's happening.  It's similar to getting a URL in an email.  This is one of the main reasons I think that a strong, consistent visual experience like InfoCards is key to building something safe, and why I want to see all of this converge.  But of course, everyone knows I'm like a broken record on this.

Some of my concerns may not matter much when it comes to controlling access to your photos.  But if this type of SSO were to become a massive success, that success would bring about its downfall.  For it would then be worth attacking and very vulnerable at the same time.  That's why I think it is best to combine it with the type of experiential system I've been talking about before any of these problems arise.