Security, Real or Imagined?

I’ve opined on the security of cloud solutions in the past, usually stating that the odds were good that established cloud vendors have better security than the average data center. Yesterday, I saw an shared an article about how researchers reversed engineered the Dropbox client. While this isn’t necessarily a critical issue for Dropbox, it does raise some interesting discussion points around security through obfuscation.

First, the Research

The researchers decompiled the Dropbox client which was compiled in a manner that decompiling was difficult. Once the researchers were able to do it, they hijacked the account. Given that a program would already possess full access to a person’s machine to accomplish this, there wouldn’t be new data to access through the client.

The researchers did share that they still use Dropbox and that they weren’t concerned about the security of the client. They went on to say that the obfuscation didn’t make much sense for Dropbox:

We wonder what Dropbox aims to gain by employing such anti-reversing measures. Most of Dropbox’s “secret sauce” is on the server side which is already well protected. We do not believe these anti-reverse engineering measures are beneficial for Dropbox users and for Dropbox.

Which takes me back to a topic from my old hardcore developer days. How do you achieve security?

Security Through Design

The first thing I remembered when I read the article is a talk from an old security pro at an Association for Computing Machinery seminar. The speaker stressed that while obfuscation may make things challenging for a hacker and thus more secure, the security was fleeting and illusory. There will always be someone who can reverse engineer the code and replicate, or subvert, the process. While primarily discussed in the context of proper encryption, the concept applies to all computing security applications.

Hiding your code isn’t going to make your software secure. This doesn’t mean that every vendor should be open source. When you assume that your code will be accessible by anyone with enough resolve, security has to be built into the design.

5 thoughts on “Security, Real or Imagined?”

  1. I always thought that security is all about reducing the possibilities. The more gates you have, the more people will get discouraged. The more difficult it is, the more you reduce the possibilities. Limiting the access to the code is one way to reduce the possibilities. No?

    My two cents.

    Alain

    Like

    • You are correct. The goal is to make sure that security it good enough that the time to circumvent it isn’t worth the reward. When we are talking Enterprise software, the reward is ALWAYS worth it for someone to devote massive resources. I didn’t say that obfuscating code doesn’t increase security, but it is a one-time thing. Once circumvented, it never needs to be bypassed again.

      The point is that if obfuscating your code is the primary line of defense, then I hope it is just a solitaire game. The underlying code needs to be properly designed so that when someone looks at it, they haven’t gotten anywhere.

      Like

  2. Bas says:

    Obfuscation has another use. When we didn’t obfuscate our Java library, customers would inevitably use internal classes and then complain when stuff broke. Obfuscation helps avoiding this.

    Like

    • I’ve encountered that problem from the “customer” side. We only did things like that when the API was either incomplete or wasn’t documented enough. When customers do that, the first thing I would ask is why they are hitting the code at that level and not at the API?

      I haven’t encountered the necessity an a product for quite some time now, but I haven’t been developing against a “young” product in quite some time.

      Like

  3. This is true. Those who use the software are not going to the trouble to hack it, especially if you have an open API. With our sw product MOVE (move.qtility.com) we know it needs to be secure from a user standpoint but also that if someone want to hack it they probably can if they have access to the install code. I do not know how much good it would do them if they did. In fact if they get their head around our code, based on Andy Taylor’s Benow platform (benow.ca), please send me their resume. The security standpoint needs to provide role functionality control, object based access control and user based authentication. When it gets into the cloud, as ours will soon, then this gets to be of paramount importance. BTW, we have an adapter for Alfresco Cloud that we want to make free in our licensing but there seems to be some kind of session control that kills out transfers after a few objects are imported. I suspect it has a bot detection function in the firewall. There is another security question. How do you allow enterprise scale apps into a cloud app without opening up bot penetration?

    Like

Comments are closed.