Encrypting data before sending to SaaS tool and decrypting on browser view

Question

I'd like to send data to a SaaS tool, where the data is stored in the cloud. I'll use Google Analytics as an example, but it applies to any similar service.

Google Analytics does not allow you to store personally identifiable information (PII), and there are many examples of online services where you might want to send user data but don't want the service to be able to view that data.

The best solution I have to this problem is encrypting the data before it's sent to the third party, appending a special token that distinguishes the data from other hashes, and then storing both the original value and hashed value in a database. For example, a username like johndoe could be hashed into s8d7f89sd7f, then appended with hashed- to get hashed-s8d7f89sd7f. You would then store both johndoe and hashed-s8d7f89sd7f in your database.

When you visit the third party's website (say, a Google Analytics report with all the hashed values), you could crawl the DOM looking for values that match your special pattern (e.g. words that begin with hashed-). Then, using a Chrome extension, bookmarklet, or some other local program, you could replace that hashed value to the original value and display it on the page in human-readable form. Unless the website was monitoring the page for changes and phoning them home, they would never have access to the translated values.

The closest solution I've seen to this problem is this Chrome extension, but it stores data in a CSV (not as robust as a database, but that's fixable) and is specific to Google Analytics.

Is there an existing solution to this problem? If not, why? And would the solution proposed above work?

Answer 1

Based on what you have outlined, your solution seems overly complex and I'm not sure why you wouldn't just encrypt the data rather than hashing it. There may be limitations in what you can store in the remote app that may require encoding the encrypted data (similar to what needs to be done when sending encrypted email). This would eliminate the need to maintain a local database mapping hashes to original text. Requiring that sort of mapping would require sharing of the database between all possible clients, which could be a problem - easier to share a secret key than a database in most cases.

However, fundamentally, I think the problem is trying to add security to something which was not designed for it. This is rarely a great path to take. The solution often ends up overly complex and frequently has holes which aren't easy to spot. The real solution is to use a SaaS which includes the level of security you require and avoid any solution which attempts to add security on as an afterthought.

Answer 2

What you've suggested is one way of doing it. However, there is a simpler way. Like Tim X has suggested, encrypting the PII data before sending it off to the SaaS tool is a better idea as all you need to share with clients needing to see the plaintext version is a secret key. And not a database.

You haven't mentioned the workflow of the collection of user data and displaying it. So I'll make an assumption that the collection of PII happens when user performs an action on their browser, app, etc. Let's say you have a website and when a user clicks on a particular link, a notification is sent to Google Analytics to record the click.

In this case, you can either pass the click notification to your own server-side code which encrypts the PII bits and forwards it onto Google Analytics -or- if Google Analytics requires a direct connection, the encryption needs to happen on the client side itself (using Javascript for example). The secret key will be stored on the server-side in the first case (recommended) and on the client-side in the second case (not recommended).

If you're not bothered about the secret key being stored by the SaaS vendor, you're better off choosing a SaaS tool that automatically encrypts PII for all notifications coming in from the user thereby requiring no additional action on your side.