25 Comments

Summary:

UPDATED According to white-label video management company Brightcove, rival Ooyala has been sending misleading information to Brightcove customers and the press, issuing a packet of information that purports to expose potential security vulnerabilities related to its media API. Brightcove says it has had at least two […]

UPDATED According to white-label video management company Brightcove, rival Ooyala has been sending misleading information to Brightcove customers and the press, issuing a packet of information that purports to expose potential security vulnerabilities related to its media API. Brightcove says it has had at least two clients come forward with the documentation, which includes four PDF files detailing an alleged security hole that Ooyala says could enable a hacker to access Brightcove clients’ media files.

At issue are the tokens that are accessed any time a Brightcove video is requested by its media API. Because some Brightcove customers use unlimited-usage tokens for read access of their files, once that token is exposed, Ooyala says it could be used to access any files that a customer is managing in the Brightcove system — even those that have not been published or those that are intended for internal communications only. In its documentation, Ooyala likens the use of these reusable tokens to “exposing a permanent username and password whenever an API call is made from the client.”

Brightcove rebuts the claim that its token-based system inherently puts its customer assets at risk, saying that customers are in “complete control” of how the token is accessed, and that many choose to make read access to their files available through the API in the same way that they make metadata available through public RSS feeds.

In an emailed statement sent to NewTeeVee, a Brightcove representative wrote:

“We enable our customers to select a variety of settings to utilize our features, each of which provide different levels of security. We offer settings / choices that include best-of-breed security technology and recommendations and best practices on how to utilize these settings. If a customer does chose to embed the token, then by definition, they are OK with the limited read-only access that providing a token entails. It’s not a security issue at all, as their media assets are not vulnerable. Again, this is all documented behavior. The API is flexible enough to allow the customers to choose and implement whatever level of access they want. There should be no surprises. It’s also worth noting that this read-only view of metadata is no different than Google’s read-only view via text indexing, RSS feeds for video content, or a video sitemap.”

While dismissing the alleged security hole, Brightcove vice president of marketing Jeff Whatcott said Ooyala’s handling of the situation was in “bad form” and “unethical.” Rather than informing it about the potential security risk, Ooyala decided instead to try to use the information to win over Brightcove clients. “They way they’re handling it is completely outside the norm. Even if there was a risk, which there’s not, they would be putting more clients at risk by spreading it this way,” Whatcott said.

Brightcove CTO Bob Mason added, “There should be a code of best practices and ethics where we are jointly working together in the industry as a whole to protect our clients, and these tactics are 100 percent counter to that,”

Ooyala CTO Sean Knapp acknowledged that his company had sent the PDFs to some Brightcove clients, but said that his company was trying to educate customers about issues that could arise from making read-access tokens available on the client side.

“First, they’re a competitor of ours and they’re not doing anything to help out Ooyala. Second, they don’t see this to be an issue, but if you tap any security expert in the industry, they would say that this is a terrible practice,” Knapp said. “People don’t quite fully understand the security risk, but as soon as someone has access to the account and has access to the token, at that point their content is fully available.”

While Knapp said that he hopes Brightcove “fixes this issue,” he also noted that security is a positive differentiator for Ooyala. To underline that point, the video management firm issued a press release earlier this week touting support for token-based authentication of its own customer’s video assets.

Update: Brightcove’s Jeff Whatcott has written an extended entry on his view of this skirmish on the Brightcove blog.

Related content on GigaOM Pro:

Report: Monetizing Digital Content (subscription required)

  1. Sean is indeed correct that this security hole exists within the Brightcove platform, but doing business in this way is just bad bad form. Seems like both sides lose on this one and the customer is worse off for it.

    Share
    1. Be careful, it seems once you have some customers @ Episodic the Ooyala security folk might come poking around your platform.

      Share
  2. I can speak from experience that these kind of negative attacks against the competition have quite the opposite of the intended effect. That includes misleading information about competitors FINANCIALS, as well as security issues. Just something they may want to consider.

    Share
    1. Bruce, this isn’t a negative attack. I am a former Brightcove customer before I decided to go with a homegrown solution. I’ve seen first hand the shoddy support and attention they give to their customers. This is pretty typical of Brightcove. Instead of releasing a fix for a very serious API design flaw, they release marketing fluff telling us that it’s all okay. It’s not.

      Share
      1. I’m not referring to the content of the message as much a tendency to make claims about a competitor as a way of selling your services. And I’m not limiting that to Brightcove or security issues.

        Share
  3. Am I missing something? What’s the big deal here guys? A competitor found a strong selling point over the other. After looking at Brightcove’s blog about the matter from reading this article, I don’t see where Ooyala did anything “unethical”. Sean Knapp is correct about this security hole, so to me it looks like BC just has their panties in a twist because a smaller company was truthful about it. Don’t think for a minute Brightcove wouldn’t have done the same to Ooyala’s clients had they found a crack in their system.

    Share
    1. Karen Lee wrote: “Sean Knapp is correct about this security hole” There are aspects of his assertions that are arguable one way or another, security is a continuum, not a binary topic. But he basis most of it on a refutable factual error: Brightcove Tokens are revocable. That is wrong, it is pretty simple, and it seems deperate to me.

      Share
      1. whoops. I think I was unclear in this sentence.

        “But he basis most of it on a refutable factual error: Brightcove Tokens are revocable. That is wrong, it is pretty simple, and it seems deperate to me.”

        It should read: “But he basis most of it on a refutable factual error. Brightcove Tokens are revocable. Ooyala asserts that they are not revocable. That is wrong, it is pretty simple, and it seems deperate to me.

        Share
  4. I have to agree with Karen. Ooyala found something that unfortunately harms the security for customers using Brightcove’s platform. This should be a good wake up call for Brightcove to have higher standards.

    Share
  5. This is like selling against the SaaS model yourself. Jeff W at BC had great points in his blog. This really was “unethical” and did not do the industry a favour.

    Share
  6. We take content protection and overall account security very seriously. Publishers entrust their content with us (and other OVPs) and expect that we will adopt the most stringent content protection methodologies to control the distribution of their content.

    Publishers have distinct security needs, and ultimately, they will be the ones to decide if Brightcove’s approach is acceptable.

    Throughout the day, publishers have reached out to thank us for calling this issue to their attention.

    We’ve put together a short overview on content security with a few examples outlining industry standards on our blog. (http://www.ooyala.com/blog?eid=118) If you have any questions, or concerns, please feel free to contact us at security@ooyala.com.

    Share
    1. Gloves off in this fight eh Bismarck?

      Share
    2. Do you believe in responsible disclosure? Are you going to respond to the specific points that Jeff W made? When again was your last security audit?

      Share
  7. Hi Tim, Karen, Noam,

    I think this is not at a all a case of a competitor finding “a strong selling point over the other.” If Ooyala went to customers and said that they think their security architecture is better than Brightcove’s that would be fine. Brightcove could do the same and customers can decide. That is not what they did. Rather, they hyped a potential security issue, they exposed third party sites to risk without permission, and assuming they actually believe their own words that the Brightcove design constitutes a security hole, they violated the principal of “Responsible Disclosure”, a well known best practice in the internet community:

    (from Wikipedia): Responsible disclosure is a computer security term describing a vulnerability disclosure model. It is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details. Developers of hardware and software often require time and resources to repair their mistakes. Hackers and computer security scientists have the opinion that it is their social responsibility to make the public aware of vulnerabilities with a high impact. Hiding those fact could suggest a feeling of false security. To avoid this, the involved parties join forces and agree on a period of time for repairing the vulnerability and prevent any future damage. Corresponding to the impact of the vulnerability it may require a period between a few weeks and several months.

    Further, their facts were just wrong–they made assertions that the Brightcove Read API Tokens are not revokable. This is just not true. If they had followed “responsible disclosure” best practice, they would have contacted Brightcove, realized their error, and not made the assertions they did. Brightcove might also have benefited from improving its communication. Customers would have benefited. Instead they spread misinformation, and caused many major (and minor) web properties stress and distraction to sort out the facts.

    Share
    1. I’d be interested if Ooyala has any response to this?

      Share
  8. I think Sean Knapp’s comment misses the point – while Brightcove may not be “doing anything to help out Ooyala,” they have not been out there making these sorts of comments, as far as I know. It’s surprising to hear someone who I’ve previously been impressed by make that sort of short-sighted statement. I’ll give them a pass this time and chalk it up to inexperience on the exec team, but in future they should raise the level of discourse. As others have said, these sorts of comments and practices undermine the growth and validation of the space.

    Share
    1. Really now. This isn’t the first time this “Exec Team” has made such comments about their competitors.

      http://newteevee.com/2009/10/12/ooyala-raises-10m-disses-competitors/

      Remember that?

      Share
      1. I’ve had the experience of dealing with Ooyala sales and what turned me to another OPV was Ooyala’s tendency to bash the competition – making statements such as “I’ve heard X is having funding issue.”

        Tell me why you’re better, not why the competitor is worse.

        Share
  9. I am frankly surprised by Brightcove’s accusations. As a sales rep from another competitor, I’ve come to see that Brightcove is making it a habit of offering their platform for free to beat Ooyala. And, they are still losing. If Brightcove wants to talk about harming the OVP space, it’s not a complete conversation unless this is mentioned. Moreover, I have always been impressed by Ooyala and the way in which they conduct themselves. Very rarely do I come up against incorrect assertions about our product. They tend to get their facts right about us and our features and this is no exception. Now, should they have gone about releasing the information in the way they did? Probably not. But let’s face it, Brightcove would have done the exact the same thing without a moment of hesitaton. Now that I think of it: This is something I’d expect of Brightcove but not Ooyala. Come on now, Ooyala, don’t let yourself stoop to Brightcove’s level. You are better than that.

    Share
  10. Not taking any sides here, but this caught my eye and the thing that I can’t understand, at least from the documentation publicly available is that Ooyala seem to use a very similar system to Brightcove.

    http://www.ooyala.com/support/docs/backlot_api#signing
    http://support.brightcove.com/en/docs/managing-media-api-tokens

    Though I did find this on Brightcove: http://support.brightcove.com/en/docs/media-api-security-best-practices

    Provided I knew what to do with the signatures (which I do from this link) I would be able to read the same content that I can from a Brightcove account? Also they speak about secure access, yet the examples I found in this documentation were over http.

    While I don’t agree with this type of behaviour and sounds like Ooyala are being rather hypocritical, it would appear that maybe the industry as a whole needs to tighten their belt buckles.

    Share

Comments have been disabled for this post