Breach this!

We ended last the last post with a promise to come back to the subject of data breach and how to protect your data even if it gets leaked. For the sake of simplicity, we will not enter on how to protect your system from being breached since, that would not be possible due to the diversity of systems. In this post, we will show how you can protect your data in case it gets leaked.

Since there is a lot of data that may need to be protected, we will just focus on user password and credit card numbers.

User Passwords

When storing a user password, it goes without saying that, you should not store the password in clear text. What you should do is apply a good one way function (for example SHA256) to the password and store the resulting hash value.

Due to the characteristics of one way functions (bit.ly/1T3Aaai), when you apply them to the same content, you always get the same result. This means that if you store the hashed password, when the user authenticates, you will be able to apply the one way function to the password and compare the result with the one that you have stored.

With this, you are now able to store the hashed passwords.  Although hashed passwords may seem enough, they are not! What happens if you have two users with the same password? Both will yield the same hash value. To avoid this, you should introduce entropy on the hash.

Introducing entropy on the hashed values can be done using a “salt”. These, are big random generated values that can be prepend to the password before applying  the one way function. After doing so, you can then store the hashed password and the salt on the database.

Store password

To authenticate the user, you can retrieve both the hash and the salt, prepend the salt to the password, apply the one way function and compare both hashes. If they are equal, the password is correct.

By employing the method described above, even if you password database gets leaked for some reason, it will not be possible to obtain the passwords. This is due to the fact that by introducing both the one way function and the salt, traditional attacks won’t work (bit.ly/1b6eFMZ).

Credit Card Numbers

If you are thinking of storing credit card numbers, DON’T! If you have a service where clients are required to pay for goods (or something similar) you should rely on Payment Service Providers (bit.ly/1PzICJE). These, are PCI DSS (bit.ly/1ONAycB) compliant meaning that, they are qualified to store credit card numbers and use a tokenization (bit.ly/1ooxGYC) process.

The tokenization process is a way of generating a random token (may contain 4 numbers from the credit card) that links the clients credit card numbers to the merchants bank account.  This means that a token can only be used to transfer money from a the client to the merchant. Tokens may be stored for recurring payments and, since they may contain at most 4 digits from the credit card number, you may show them to the client as a means of differentiating credit cards.

If you really have the need to store credit card numbers, you should encrypt them before storing. DO NOT, at any time, store the CVV since, it’s only required to verify that the card holder has the card.

When encrypting credit card numbers for storage, you should use a very strong key and a robust encryption algorithm like AES-256 (bit.ly/1MTTbKu). However, you are now presented with the problem of storing the key. The answer to this is simple, DO NOT STORE THE KEY. Instead, use the users password and a generated salt as a seed for a deterministic key generator algorithm. After encrypted, you can store the number. If you require, you can also store four number of the card so that, when presenting cards to a user, they can identify which are which.

Store credit card numbers flow

When you are required to retrieve the credit card number for any reason, just ask the user to reauthenticate over a secure channel get the salt from the database and recalculate the key from the password.

Employing either of the described methods will protect the credit cards numbers. When using tokenization, the token links the credit card number to the merchant. This means that, even if it gets used it will transfer money from the client to the merchant. Upon detection, the merchant can cancel the tokens and return the funds to the clients.

By encrypting the credit card numbers as described, since the key is never stored, it will not be possible to decrypt the credit card numbers in case of data leakage.

In light of what you read along this post, how do you feel about your stored information?