0

We have a process where data is sent from one database to another for distribution. The process chosen at the time was to encrypt the data because of all the people that could access the database. However, de-crypting the data is a slow process. What are the alternatives to securing the data on the servers to prevent access?

user1898525
  • 133
  • 4
  • 14
  • Maybe we could suggest alternatives if you tell us some more details about what you're encrypting and why it hajs to be encrypted. Best if you also mention who got access to the data, and who it have to be hgifdden from, and for what reason. Used software (DBMS, Server, ...) is worth mentioning, too. – Johannes H. Feb 06 '14 at 16:14

3 Answers3

1

It all depends on your requirements.

If you really need to keep the data private from people whom have access to the database then you pretty much have no option but to encrypt.

If you are sending the data to other locations and it is the transfer itself that needs to be secure you can use encyption for just the communication, ie webservices over https or custom encryption over tcp/ip, or saving to flat files and encrypting it as a whole..

If the data itself needs to be hidden from the people whom have access to it then there is a question of how secure the data needs to be.. If you are just wanting to avoid clear text there are some pretty fast encryption algorithms that can be used, here is a List of different encryption algorithms.

But if you are storing things like medical history or banking information then you have no option but to either upgrade your hardware to improve performance or take the processing time like a man ;).

If we are talking about passwords, where you only need to know if the user entered the correct password or not, then you could hash the passwords with a salt, and compare with the database hash, read more about that here: Link.

Community
  • 1
  • 1
JensB
  • 6,663
  • 2
  • 55
  • 94
  • 1
    My 2 cents on the choice of algorithm: if performance is an issue, always choose AES, as most modern processors have dedicated hardware for that one. If AES isn't considered secure enough, double key length - it's still a lot fastr than every other algorithm on hardware that supports AES. If security is way more important than performance, use either Serpent or Twofish. – Johannes H. Feb 06 '14 at 10:14
0

Easy answer: none. The only way to prevent people with physical access to the database table (note: the database TABLE - most DBMS can set access rights for indivifual tables) from reading it, is encrypting the data. It really is that simple.

Johannes H.
  • 5,875
  • 1
  • 20
  • 40
  • what about hashing the data instead? our process takes 2 hrs to decrypt 160,000 rows. Seems a long time. – user1898525 Feb 06 '14 at 09:57
  • hashes are irreversible. It indeed prevents everybody from reading it - that is, EVERYBODY. You cannot get plaintext out of a hash. Ever. – Johannes H. Feb 06 '14 at 09:58
  • It gets better. The solution choosen did not work in the first place. I guess accessing the description key is trivial. – TomTom Feb 06 '14 at 10:04
  • May be possible, if stored o0n the server as well, yes. – Johannes H. Feb 06 '14 at 10:12
  • @JohannesH. You can't say that hashes can NEVER be reversed, it's just not easy http://en.wikipedia.org/wiki/Rainbow_table. Its basically the same thing for all encryption, they can all be reversed, but for some the time to reverse is so long that it is considered impossible. – JensB Feb 06 '14 at 10:14
  • @JensBerfenfeldt Rainbow tables don't necessarily give you the ORIGINAL data. Just ANY data that has the same hash. This is a huge difference, as different data can produce the same hash (which is unavoidable if the hash is shorter than the data). – Johannes H. Feb 06 '14 at 10:15
  • @JohannesH. Very true, all I'm saying is that you can't consider hashes as something that can never be reversed and is completly IMPOSSIBLE to undo. I wouldent want to store my banking information in an MD5/SHA even with salts ;) – JensB Feb 06 '14 at 10:18
  • Agreed on that (especially for MD5, which is not considered a secure hash any longer for quite some time). Still hashes are not an option if one wants to reliably decode the data again. – Johannes H. Feb 06 '14 at 10:19
  • So, for example, how is a website supposed to de-crypt encrypted data and have a reasonable response time to the end user? – user1898525 Feb 06 '14 at 10:44
  • I hope you're not encrypring entire websites (that is, html-code)? THat's a stupid thing to do. The html code isn't secret at all, just the contents are. – Johannes H. Feb 06 '14 at 16:13
0

Couple of recommendations

  1. Work with DBA to create roles and restrict access to sensitive columns. In this case you don't have to encrypt.
  2. Few columns you have to encrypt due to regulatory requirements. Selectively encrypt only the columns having sensitive data.

Also use relatively faster algorithms like AES. You can also cache the crypto object if not already done.

Saran Makam
  • 126
  • 7