Over a million developers have joined DZone.

A Five-minute, No-jargon Introduction to Data Encryption

DZone's Guide to

A Five-minute, No-jargon Introduction to Data Encryption

Distinguish encoding, hashing, and encryption. Avoid pitfalls in key exchange, configure https correctly, and don't re-invent the wheel.

Free Resource

Download the Guide to Open Source Database Selection: MySQL vs. MariaDB and see how the side-by-side comparison of must-have features will ease the journey. Brought to you in partnership with MariaDB.

Data encryption has become very important aspect of security. And users expect high standards of security from your application. User data is an invaluable asset to your business and today's applications cannot provide the best user experience without knowing quite a bit about users, their relationship with the business and their preferences. On the other hand, users are now more willing than even to share relevant information with you for getting better experiences, provided you behave responsibly. Here is a no-jargons post to get you started.

Know What is Not Encryption

It is surprisingly easy to get confused between encryption, encoding and hashing. Often even well-intentioned developers build poor security implementations because they are in a hurry and they think they have roughly figured it out.

1. Encoding is not encryption. Just because something looks unreadable in a text-pad doesn't mean its encrypted. Base64 is not encryption.

2. Hashing is not encryption. It's quite a different beast. Usually, even the legitimate user cannot get back the data after hashing. It is mostly a one-way process (the only exception is when you hash tiny bits of data like passwords... in which case, it could be possible to figure out the data from the hash.). So, MD5 and SHA don't qualify as encryption.

What is Encryption

Encryption is the use of a secret/password to transform a data in such a way that only someone with the same password could restore it to the original form. The problem here is that the sender needs to know your password to send the data in the first place! (and we frown upon sharing passwords to client applications).

A better variation of the same is to use a public key to transform the data in such a way that only a matching private/secret key can restore it to the original form.

The Usual Pit-falls

Even after "getting" what is encryption, we tend to think we can get away with a slightly hazy understanding of whats happening. There is a need to think through the whole process and make sure it is solid.

  1. The hand-shake is important: The initial handshake where you exchange the key(s) is important. Think it through. Don't assume you can leave a loophole there and the hacker will "miss" that loop hole. It is the first place someone would look. Public-key encryption by itself will not save you, unless the handshake is solid.

  2. Don't try to reinvent the wheel: Look for established ways of doing usual operations. There are established practices for login, session management, logout, data transfer, etc.

  3. Keep it simple and solid: Don't create unnecessary overheads and layers of encryption. For example, if you configure HTTPS properly on your sever, it will be way safer than having a poor HTTPS configuration and having a whole other encryption process for your data on top.

Avoid Sending/Receiving Data in the First Place

If you are reading this post, you have probably decided that you need to encrypt data in transit. But maybe you haven't made that decision.

Here is something that you should consider at the very beginning... Encryption of data in transit must always be the last resort - without exception. Don't transmit any data unless its absolutely unavoidable (don't trust the client to keep data secret). Don't accept any calculated values which you could derive yourself (don't accept any help from the client). 

To sum it up, go through the minimization exercise and decide on the bare-minimum data that has to be transfered. Look for existing encryption support on the communicaiton channel, which could be enabled just through configuration, and use such an option if one is available. If no such option is available, take to designing an encryption process with care, while avoiding the usual pitfalls. 

Further reading:

1. Encoding vs. Encryption vs. Hashing 

2. Public-key cryptography

Interested in reducing database costs by moving from Oracle Enterprise to open source subscription?  Read the total cost of ownership (TCO) analysis. Brought to you in partnership with MariaDB.

encryption ,security ,database

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}