Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Disclaimer: I am by no means a security expert. I simply needed some client-side encryption for my project and did my best to understand the options and lay them out here. All feedback and corrections are welcome, and I apologize in advance for any mistakes!
For the past couple months Iâve been working on a side project, SoulSaga. I wanted to build a space for people to be able to reflect on their lives, their identity and their personal growth. In other wordsâŠan application with lots of sensitive user information.
Firebase solves a lot of these problems, including secure transmission and server-side encryption. But, as anyone who has used Firebase Database or Storage quickly realizes, you as an admin can see any user data that gets stored in there. So out-of-the-box, Firebase is good, but not good enough âuser trust requires and deserves full protection, so some form of client-side encryption (encryption prior to sending to the database) is necessary.
In this article, I hope to enumerate some of the options I considered to address this, the final one being the one I settled on.
The encryption itself is simple enough to perform with existing libraries, using a symmetric key (a key that can both encrypt data, and decrypt the encrypted data) like AES. As the usual problem goes, we now need to find a secure place to store this all-powerful key.
If stored in your own servers, it provides no security, since you yourself could use the key to decrypt your userâs data, and therefore anyone hacking your system could do the same. It shouldnât even be an option, so weâll call it Option 0Â :P
Option 0: Storing Key With Data
Option 1: Password Encrypted Keys
You could store the key on your server and ask the user to keep a strong password to encrypt the key. Thatâs not ideal, since it requires work on the userâs end, and if the user forgets this password, the key likely isnât recoverable. That said, there is merit to this option, and seems to be a relatively popular one.
Option 1: Password Encrypted Keys
Option 2: Store Key on User Device
Most closely resembling end-to-end encryption, this stores the key on the userâs device, so the key is never in the application servers. The problem with this approach though, is that the key, and therefore the data, is not accessible from other devices. Itâs not a bad solution, depending on the situation, but definitely not what IÂ wanted.
Option 2: Storing Key in User Device
Option 3: Google Key Management Service (KMS) for Key Encryption
At this point weâve exhausted the options for where the key can be placed along this pipelineâââbut there are more options to consider by adding on other systems.
A popular and well-thought out solution is by Andy Geers, and involves encrypting the key with another data key stored in Google Key Management Service. The userâs key encrypts the data, and then the key is encrypted by a KMS key and stored in the database. As Andy points out,
Importantly, the KMS key belongs to a different Google account to the Firebase database, so no one user (e.g. me) has permission to both read the data AND decrypt it. A hacker would need to compromise both accounts to access the unencrypted data.Option 3: Storing Key with Key Management Service
I personally wanted to design a system where the key was still in possession of the user, and did not want the burden of having to manage two accounts.
Option 4: Stash the Key in the Userâs Google Account! (With User Consent)
I was already using Firebase Authentication as my authentication solution for Google accounts, so this solution was a natural extension of that. Right away, locking in to Google as a sole authentication provider is a considerable downside for this method, but I hope that this concept may inspire some, or that similar APIs exist for other authentication providers.
When the user logs in, we get the OAuth credentials to request the userâs personal encryption key, or create one if we canât find one, from the userâs Google account. This way, the key is always fully in the userâs possession, but they never have deal with it directly. Obtaining the key would require hacking the userâs Google account, at which point the hacker could just read the data in the application anyway.
Option 4: Storing Key in Userâs Google Account
So, what does it mean to âstashâ the key in someoneâs Google Account? Google Drive provides an API for creating a special application data folder (user consent is required during OAuth). The contents of this folder are not visible to the user, and is only accessible via your applicationâs credentials!
Caveatâââthe user can see how much space is being occupied in their Drive by an app, and has the ability to clear the appâs data, so this method does rely on the user not accidentally deleting their own encryption key.
Key Storage in App Data folder in Google Drive
Thanks for reading!
Client Side Encryption in Firebase Database and Storage was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.