Internal SugarCRM Project: Browser-Side Password Encryption System

sugarcrmdevelopers —  June 22, 2012

We asked our engineering intern, Jim Rybarski, to contribute to our blog and give some insight to the internal projects he’s been working on while at Epicom. In this week’s mini-series update, Jim discusses the new Browser-Side Password Encryption System he developed for the Secure Password Emailer. If you haven’t read Jim’s post about the Secure Password Emailer, check it out here.

Previously I wrote about our Password Emailer module, which securely sends passwords to clients. What I didn’t discuss was where those passwords come from and how they are stored.

At Epicom, we have to keep track of literally thousands of passwords and it is of utmost importance that those passwords are not compromised.  We also need the ability to control who has visibility to certain passwords.  We have long used SugarCRM to handle our password management and it has always been setup in a very secure manner. However, it was quite cumbersome to interface with because it required that we use a command line interface on our computers that used the REST client to get the data out of Sugar.

Recently I revamped the user interface (UI) of our password management system to work from the web browser.  What makes our system so secure is that the encryption of the passwords is done client side.  The Sugar server itself does not have the ability to encrypt or decrypt the passwords, so the unencrypted version of the password is never sent over the Internet (even though we use SSL).

When we need to create a new password credential, we create the record in Sugar and then there is a javascript encryption library that we trigger from the action menu that asks us to input a key.  This key is memorized by the engineers at Epicom, but not stored anywhere.  It is used to encrypt the password before the record can be saved.

The same thing happens in reverse.  When we want to lookup a password, we open that record in the CRM. The password is unreadable until you trigger the javascript action to decrypt it via the browser.

This encryption/decryption routine can work with any field in any module, so it could be used to encrypt things like credit card numbers and social security numbers.  Sugar does have the ability to have encrypted fields out of the box that uses Blowfish and stores the data in the database in an encrypted manner. The problem with using Blowfish is that the key used to encrypt/decrypt is stored in the file system of Sugar, so if someone gets access to the file system then they can also decrypt the field.  Also, the field of data is decrypted server side, so the clear text version of it is only sent over the Internet when you access that record.  With our technique you have to know the key and the data is never sent over the Internet decrypted.

Epicom has a strict policy on protecting client data and the password encryption system was just another way to further improve our security. To help our clients do the same, I’ve made the service into a module-loadable package which can quickly be installed on any of our client’s Sugar instances.

If you have any questions about the Browser-Side Password Encryption System discussed in this post, please contact us at info@epicom.com.