Data encryption features in development for our current and future web services

  Follow me: Follow Bruce Kirkpatrick by email subscription Bruce Kirkpatrick on Twitter Bruce Kirkpatrick on Facebook
Sat, Feb 18, 2012 at 11:55PM

This weekend, I have been looking at OpenSSL and GnuPG open source cryptography tools for the best way to handle encrypting sensitive information in future applications. OpenSSL is used for protecting SSL data streams and GPG/PGP is best for protecting stored data.  These free tools and libraries already provide security for a huge amount software including the Apache web server and many others.

In the process of doing my research, I found there are basically 2 ways to go with data encryption. You can use symmetric or assymetric encryption.

Symmetric Encryption For Simple Password Protection

Symmetric encryption is basically when you put a single password on your data.  The only way to view the file is with the password you encrypted the data with.   Hopefully, you'll choose a reasonably safe algorithm such as AES-256 or TripleDES or perhaps a combination of multiple algorithms.   Some algorithms have been found to have weakness such as SHA-1 and others such as MD5 have been easily cracked on cheap computers so some care must be taken to choose algorithms that are still appropriate to use for the level of security you desire.

The disadvantage to using a single password system for encryption is that the password that encrypts the file needs to be stored in plain text on the server in order for the application to encrypt the data automatically. If the server is ever compromised, the encryption password and database may both fall into the hands of the attacker.

Asymmetric Encryption For Data In Motion

Most web sites processing financial information and other sensitive information are protected by SSL encryption and secure certificates. These certificates are part of an asymmetric encryption system. In this kind of system, there is a private and a public key. Before any data leaves the server, it is encrypted with the private key. The web site visitor's browser automatically downloads the public key and uses this key to decrypt the information that is received automatically. This design allows you to hide the private key from the person who will view the information encrypted with it.

On web sites, they combine this public/private key with your domain name(s) and an expiration to ensure that information that is passed back and forth are coming from the expected place.  Additionally, many secure certificates are signed by a third party Certificate Authority such as Verisign, Thawte, Godaddy and others.  The idea is that larger companies with a greater emphasis on security are verifying and guaranteeing certain information to be accurate which helps to improve consumer confidence in your products and services.

Asymmetric Encryption For Storing Data At Rest

So how does assymetric encryption apply to storing personal information like financial records? Well, the main benefit that I've found is that you no longer have to store the decryption key in plain text on the server and you can also have multiple keys to unlock your information. You can require a password to be provided by the user each time the data is viewed and never store that password in a way where it can be retrieved by using one-way hashing algorithms. Hashing is essentially a method of converting the password into something of such high mathematic complexity that it would be unrealistic to attempt to crack it even with supercomputers. By adding multiple layers of encryption on passwords and the store data in combination with assymetric encryption, you further reduce the chances that if someone stole your database, they would have more difficulty decrypting the information.

In addition to using advanced algorthms, I'm also configuring them to have greater mathematic complexity by choosing longer key lengths. This ensures that as computers get faster, someone is still not able to gain access to your encrypted data. Imagine if your password was over 2,000 characters long. That's how complex many of these modern algorithms are. Fortunately, we can still allow users to enter short passwords by combining symmetric and asymmetric encryption techniques.

Upcoming Secure Electronic Contract & Signing System

The first application I'm trying to build with this new work is an eletronic contracts and secure signature system where all the contract data is encrypted and all signers are verified through their email account and password. The only way to access the contract will be when someone has come through a link in their email and entered the correct password. Each party involved as well as the system administrator will their own isolated encrypted versions which prevent them from needing to share a password. I have thought hard about this system and I'm really excited about the level of security I'll be implementing on this system.

Encrypting data makes it harder to search and browse this information because each record in the database in encrypted and not using plain english. In some cases, it may be desirable to disable security on specific customer information in order to make it easier to use the web site. I'm going to make options available that will allow a variety of security levels so that different applications can take advantage of increased security when desired.

Current Development Progress

Contracts are not as sensitive as credit cards, so it will be a good one for debugging the system to ensure I can protect other things later safely.   I built working encrypt/decrypt scripts based on GnuPG yesterday as a proof of concept that it will be possible.   I thought out the whole process of securing the user's password, encrypting the decryption key with it and using public/private key encryption to protect the data without having to store the decryption key in plain text anywhere on the system.   This was the major problem that I didn't know how to solve until yesterday.  Symmetric encryption requires the key in order to both encrypt/decrypt, so you can't store anything encrypted unless the app has the key.   But with asymmetric encryption, you don't need to hide the key on the system at all, which is exciting to me because if I achieved success on a higher level, there would be higher risk that data would be stolen.

The hardest part was figuring out how to get the random number generator to be fast.  It initially took 3 to 10 minutes to create a key because linux depends on keyboard/mouse input to generate random numbers and it was also a manual process requiring input.  I found resources on how to automate the commands and a tool that reduced key generation to 3 seconds by using the hardware random number generator in the CPU, which is also more secure. 

I achieved file encryption/decryption with both openssl and gnupg, but gnupg is really the only option for free database security because openssl command line only support making certificates and doesn't encrypt files unless you integrate the C library.  PHP has integrated the openssl library, but I didn't want to depend on PHP scripts since I'm using other technologies like CFML.  I made a working php script though because I was stuck on gnupg at first. It was an all day project to have the 2 approaches fully working.  It's also better using these tools then built-in coldfusion/railo because many of the Java libraries have less secure algorithms included due to licensing issues.  OpenSSL and GPG have managed to legally make these algorithms as C/C++ open source projects.   This is one area where PHP & C languages are better then Java & Coldfusion because more libraries exist for C then any other language.  According to research, the current higher levels of encryption that are reasonably fast would effectively protect data for decades, possibly forever.  

Credit card numbers probably have expiration dates because they have measured the risk and determined that should attackers gain access to this information, it still wouldn't be enough for them to get anything useful if the data was already expired and if it hadn't expire, the abuse and limited timeframe to steal further reduce's the banks losses.  However, bank account numbers and social security numbers would not expire and it would be a bigger problem if someone got them years later.  Fortunately, we probably won't need to store that information for most web applications unless we were trying to make government web sites and our own system competing with paypal.  In those situations, you'd want to use a compiled language as well so that if the application is stolen, it would be harder (not impossible) to crack it without the source code.   So, perhaps one day, I will rebuild this part of the code with a compiled language as well.  Security is about making the attacker jump through enough hoops that they are forced to give up or try another approach.  It is not possible to have 100% security, but in many applications, you can have sufficient levels of security to mitigate the risks and be compliant with regulations.

I made an effort to describe security without describing my exact methods since part of security is obscurity. What someone doesn't know, increases your security, but ultimately the weakest link is your password.  If someone has access to your personal computer, you can still lose everything on your account so I have to protect my personal computer where the password is entered as much as the server for this approach to be reliable.  This is also true for PCI Compliance Scans, they check security on both the client and server.

Implement Smart Cards To Further Reduce Risk

There is also the Java OpenCard framework which provides a programmatic way to combine smart cards with a web application so that only people with the password and the device could logon.  A smart card is hardware device with a unique secure certificate on it.  Smart cards and the reader cost as little as $30 per user, which makes it a reasonable option for each client to have one to protect the master account passwords. This would probably protect you from remote attackers fairly comprehensively assuming the application is otherwise secure. Someone would have to steal your card and your memorized password. This is quite difficult without torture and breaking a bunch of additional laws in the real world.  A lost card can also be disabled within a short time window, so even if they gained access, they would have very little time to get into the system.   It is also possible to restrict system access to a static ip, so this would further require them to have access to your computer/network to get in.  Perhaps in the future, we will consider adding smart card support since this does solve more security concerns and further increases the chance of an attacker getting caught if your physical office has additional security in place.

Security Is An Essential Requirement For Web Applications

Security is a serious matter when it comes to protecting financial information. It is required for all merchants to meet certain requirements with regards to the PCI Data Security Standard (PCI DSS) and also various laws protect privacy and confidentiality of personal information which makes this important for everyone to do their best with implementing better security measures. We try to do more to achieve increased security then just use SSL and encrypt your stored data. We protect our systems from unauthorized access with firewalls, validating user data, preventing automated attacks, limit the number of failed logins, and more. We host our web sites at larger companies which apply strict physical security standards at their datacenter.  We frequently upgrade our software and monitor our systems.  We perform research to discover the latest techniques and threats so that we can implement the best methods to proactively improve our security. Data theft can be a serious problem for any company and I want to ensure that our future services provide effective and up to date security techniques.

Bookmark & Share

Popular tags on this blog

Performance |