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.
Join the DZone community and get the full member experience.Join For Free
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.
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.
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.
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.
Opinions expressed by DZone contributors are their own.