How not to fail like Ashley Madison! or a guide to hackproof application (part 1)

Ashley madison failure


The irony of a company so built around secrecy and gigabytes of profile informations roaming around internet is hilarious!

Even Ashley Madison’s advertisement is inferring: “We are here to keep your secret”

So how did such a scandalous failure happen? I don’t know but in this post I will try to describe a (near) hack-proof architecture with the hope that it does not happen to your application.

Whatever your company does, if there is customer data somewhere, there is a risk it could leak. Security should not be taken lightly. A data breach can crush a successful company to dust in one day! And in the cloud era, you should make sure not only your application is secure, but also a breach in cloud provider does not jeopardize your data.

On the other hand, security stays in the way of productivity. Making it hard for hackers to access your data will make it hard for your own developers and analysts to do the same. The valuable resources that need to go to building the product has to go to the security.

So, “What is the minimum we should do to make our application hack-proof?”

In these series of blogs I will address this question, and we will discuss an architecture to particularly prevent these hacks:

  1. Separating data that uniquely identifies the customer from the rest of data and securing this data separately.
  2. Encrypting data such that even the breach of data and some encryption keys does not cause a problem.
  3. Hot to make sure only authenticated services from specific hosts can access your sensitive data.
  4. In the worst case scenario that a hacker has access to your application and your main credentials, and can imitate your service to get data, how to prevent large scale data breach and catch them early?