Howdy all,
Are there plans to add an option in remoteStorage.js to encrypt data before sending it to server? Or would it have to sit as another layer on top of remoteStorage?
Thanks!
Yes, we discussed solutions for this a while ago, and weād like to add it at some point.
Want to help?
@silverbucket Wanna look at this again and hack on this with me during Hacker Beach?
@raucao absolutely!
@silverbucket and @raucao, have you had the chance to work on this?
Could you provide a little status quo of this question?
Donāt we already support HTTPS/SPDY so every connection is already encrypted?
Which additional way of solving the data privacy issue were you thinking of, @diafygi?
Only questions.
Encrypting the transport is the absolute minimum, but for critical data like e.g. credentials, you might want to encrypt the data itself as well.
Good. What kind of key exchange / storage encryption implementation / workflow ideas are already around?
The idea is to ask the user to optionally encrypt their data after connecting their storage. Then you either enter a password (first time or the one you used before) or you donāt. The password would be kept in memory during the session, and as soon as you reload or revisit the app, youād have to enter it again.
So some kind of encrypted storage container like BoxCryptor or TrueCrypt (in some configurations). Nice; why not.
No, itās not a container. Every piece of data would be encrypted and decrypted on demand all the time.
I agree with @raucao that client-side encryption would be really important to me if Iām using a commercial server like 5apps instead of hosting my own server.
ā¦ at least when it comes to credentials is what I meant. I donāt think Iād want to enter my password every time I open an app with uncritical data.
2 Likes
We can encrypt only part of file tree, for example encrypt /user/notes/secrets/* and donāt touch /user/articles/*. So until you decided to read/change your secret notes you donāt need to enter password.
Itās also possible to ask for passwords only for some files with specific extensions, for example /user/notes/ids.gpg.
All major browsers vendors work on implementing WebCrypto standard now. It will provide to Javascript access to first-class random generator and basic cryptography methods. In the meantime we can use a WebCrypto polyfill.
@dogada the file extension is a a possibility, though Iām not sure if thatās a good long-term solution as it could cause issues. Also, we donāt normally store anything with extensions, the modules themselves decide on naming patters, and usually with advanced usage there are more complicated indexing going on to ensure speed and organization of large amounts of data (at least, thatās the goal).
Itās been on my roadmap for the past couple months to do this (implement a way to encrypt data, and retrieve it easily via. the widget), even just to prototype it, but Iāve been pretty busy lately with other things. I hope to get to this soon.
Currently remoteStorage is kind of backed-up with some large changes coming down the pipes, so Iāve been delaying working on this until the dust settles.
If you are interested in helping out, perhaps we could talk this over more (@raucao as well).
As I said, Iād propose to do something like a crypto hack day, where we could remotely pair on prototyping the whole feature in order to see if our ideas would work and gather feedback on it. How about putting up a Doodle for a date?
This is crucial IMO, Iām very interested in getting this done.
How can I help?
Howdy all, Iāve been working on a side project that implements encryption into an unhosted-style library (https://github.com/diafygi/byoFS). Itās still super alpha, but itās been fun so far. Thereās some trade offs in order to provide client-side encryption, and Iām not sure if it would be compatible for the remoteStorage spec.
The biggest tradeoff: Iām only allowing direct key lookups for reads and writes, since the remote server stores only hashed filenames. This prevents listing all the files or searching for a filename in a remote server since the hash is one way. For the byoFS demos, they use a known āindexā filename to keep track of all the other filenames, so inserting or changing a filename actually requires updating the index file, too (e.g. two writes on the remote server).
If remoteStorage didnāt want to make that tradeoff, it could keep the filenames unhashed in order to allow listing filenames. I chose not to make that tradeoff and force the app developer to manage their own filenames.
Alternatively, you could encrypt (instead of hash) the filenames and then decrypt when listing files. However, that would mean any filename search beyond a straight key lookup would require downloading the entire list of files and decrypting them all to see if they match the search. Nowhere near ideal, but possible.
2 Likes
For what itās worth, I also use encrypted credentials storage in https://meute.5apps.com/. It still needs error handling added, but as long as you donāt mistype your master password, it works.
Oh, and my plan is to submit this upstream, of course. See also Working on a social library on top of remotestorage.js
Well, I see 2 main use cases for encryption support:
- Provide encrypt/decrypt routines for explicit encryption/decryption.
- Allow to to enter master password once and then implicitly decrypt data on read and encrypt them on write.
First use case is simple. We just need to add encryption support based on proven standards (WebCrypto?) to allow application developers to call RemoteStorage.encrypt(data, secret) and RemoteStorage.decrypt(data, secret). To use it developer will only need to implement an UI callback that will ask for password.
Second use case will need some way to detect should an object be encrypted/ decrypted? I agree that extension isnāt good idea and probably better idea is to use RemoteStorage.defineModule. For example if an module defines preSave and āpostReadā in own exports RemoteStorage can call these functions immediately after read and before save to the underlying datastorte. Encryption/decryption (and any other pre- and post-processing) can be done inside these functions. Functions accepts raw objects, analyse it, change if required and return original or modified copy. What do you think about this approach?
We also will need a default way to ask user for master password (it can be just trivial window.prompt. Application developer can customize this prompt also on module level defining in exports callback with name like passwordPrompt. Once we obtain master password from user, we can derive real password with a standard function like PKDF2 and use it for actual encryption/decryption with AES256 as chipper. So user will enter master password only once and we will use it until session expire or an timeout. We can discard master password immediately after generating of derived password and keep it private in memory only.
We even can have option to use own master password for each module, this
will lead to better security but weaker UX probably.
Yeah, Iām interested in it. If we all agree desired solution and requirements to it, I can implement it.