Is it worth encrypting database?

Asked

Viewed 486 times

3

Recently I’ve been having the curiosity about the utility of encrypting all fields of all tables in a database.

The idea is this:

  1. Create two Crets (one in the bank and one in the application);
  2. The application is responsible for encrypting/decrypting the data;
  3. All data going to the bank is already encrypted;
  4. The application uses the two Secrets (hers and the bank) to encrypt/decrypt the data.

The advantages I see are:

  • Any form of point data extraction other than by the application results in encrypted data, and therefore useless to the attacker.
  • Even in the case of a complete copy of the bank, the attacker would have only encrypted data, no utility.
  • The attacker would succeed only in the event of a hack on both servers: BD Server and Server with application code.

It’s worth working with this level of security to prevent large-scale leaks in the event of intrusions?

  • You need to evaluate the performance of the application to encrypt/decrypt the data, or you will not take this into account?

  • Why encrypt a data that is public? For example, the name of a user or product

  • @Costamilam is public to some extent. If you add the user name to other information also "harmless", in a leak with millions of accounts, you have ensumos for phishing campaigns, spam, social engineering, etc.

  • But the difference is between taking this data by hacking into your database (which is very difficult) and parsing the data provided by your application (much easier)

  • 1

    Armed escort for truck change , the price of the operation does not pay the theft , It has to weigh how much would cost the data loss , a few years ago Petrobras would have lost a computer with data of oil reserves , the data would be worth billions of times the price of the machine , how much your data is worth ?

  • @Motta I am starting from the premise that the data is highly valuable and sensitive.

  • I don’t really work with encrypted data , I don’t know the impact but I believe that the data would need to be very sensitive to make use of encryption , but even encrypted the issue falls into a weak spot , a user with access to information extracts the confidential data and sells it , wanted even some bibliography about it.

  • I would say that nowadays no longer, because the security standards are abstracted in various layers, but if you are for example using an older technology, then maybe it would be worth it, but knowing that any process between encrypt will hurt your application to suffer performance loss.

Show 3 more comments

1 answer

3

This is not an answer that is given to a global scenario, because much influences the decision to be made, among them:

  • The degree of confidentiality of the information stored in the bank;
  • Machine performance by the seat;
  • Customer performance of the machine;
  • The size of the information stored and the queries to be performed.

The main idea of encrypting the contents of a database is to protect its contents. The principle of cryptography is to protect that someone does not understand/read/intercept what two points share. In any case, it is possible to intercept information before it is encrypted, or after it is decrypted.

Even, it is possible to intercept the shared key once you mentioned a symmetric transaction where the A end and B end share the same private key.

  • Any form of point data extraction other than by the application results in encrypted data, and therefore useless to the attacker.

If he was able to extract information from your bank without a legitimate "authorization", your bank is unsafe and there are security holes in it. Protecting its content makes you wait exploits and leaks from it. Therefore, one of the reasons for protecting internal information is the science of insecure authentication.

  • Even in the case of a complete copy of the bank, the attacker would have only encrypted data, no utility.

Complementing what I said above, if he managed to break into your bank, he will be able to hack into your application, and then the private key. Often, banking hacking techniques may be global and not intended for banks, for example, it may have accessed the server where the bank is hosted. Soon, it will have the symmetric key. But it makes no sense to have the private key stored on the target server.

  • The attacker would succeed only in the event of a hack on both servers: BD Server and Server with application code.

In fact, if he hacked into the client, he would already have access to both the database and wouldn’t even need the application code. Transactions between the client and other servers could be intercepted in a targeted environment. As much as the package comes encrypted from its origin, it must be decrypted in your client, and briefly stored in your memory that information.

You can encrypt your transaction with another end using SSL/TLS, where its name already explains what is happening there. The protection is divided into an asymmetrical key between the two tips. The Cloudflare does it well, and also optimizes the delivery of that transaction.

If you want to protect the disk where your bank is stored, you can use EFS. It is also recommended to use an authentication certificate SSH to access the server where your information is stored. Using a simple password to access a server where there is so much confidential information makes no sense.

In the wikipedia there is an article explaining exactly this subject, it is good to complement what you read here.

In short, encrypting your database will not prevent a data exposure. Maybe a little, but not enough. Protection should be invested in authentication and security for transactions, and of course, for your client. Here it is well explained how you protect your client with secure uploads, and here shows how to protect a string, in your case, a symmetric key.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.