search

ONLYOFFICE / CommunityServer

Free open source office suite with business productivity tools: document and project management, CRM, mail aggregator.
http://www.onlyoffice.com
Apache License 2.0
2.74k stars 619 forks source link

Feature Request: User / Permission Specific Encryption #411

Open nixjdm opened 2 years ago

nixjdm commented 2 years ago

Hi, I'm interested in #409, and it spurred me to try to better understand how permissions, access, and encryption work in ONLYOFFICE.

Right now, there is "encrypted storage" available in /controlpanel/storage that seems to in-place encrypt the contents of various (all?) things in the Data directory on the server. All full portal admins can toggle this on/off. In addition to this, all backups taken with /controlpanel/backup are fully unencrypted. It seems access to content is protected on an application level, but not enforced by encryption, generally. By that I mean the running application server can simply unencrypt whatever it wants on demand. Is that correct? Is that all with the same key? I haven't found all the details yet. If there's a better doc page, please link me :) Side note, if that doesn't exist, IMO more thorough technical docs on exactly how the encryption works could be considered a marketing effort and energy well spent.

We could tie content encryption to users and their permissions, similar to what LastPass or Matrix does. In LastPass for instance, data could be available to its owner only, or also to other individuals it is shared with. I couldn't find details on how the shared content is handled, which is the interesting part, but I think it is encrypted via knowledge of public keys of various users, where those keys are in turn abstractions partially based on master passwords, and maybe other metadata. I'd love to know more about it. Matrix is similar in how it handles giving message access to users of its chats through asymmetric encryption.

Applied to ONLYOFFICE, all user data could be naturally encrypted at rest with keys based on users and their permissions. This could augment the other current layers of security, like at rest encryption which is not user specific. With encryption being user specific, and fundamentally based on users' passwords, backups could be taken that do not undo this encryption. Indeed, the encryption couldn't be trivially undone, because the server (hopefully) doesn't even have the users' passwords. A restore would restore the same encrypted data, and users on a restored system could access it with their old passwords.

Personally, I'd love this feature, though it may not appeal to everyone, and I acknowledge it is probably a heavy lift. I think privacy interested folk like me would be even more attracted to ONLYOFFICE than we currently are. It in effect would mean users "own" their data. Relating to #409, I'd feel more comfortable if I as a user had explicit control of who could read my data, and not worry about sysadmins snooping around. Even if sysadmins are trustworthy, it is simply a greater attack surface to be concerned with. If an organization has a business requirement that everything is visible, they may not want this, or maybe they'll just give admin access to things like exists now on the Common dir. This feature would also involve some performance hit on the server. So this might be better as an option, like at rest encryption currently is, however, it could not be toggled off easily, since the server doesn't have the passwords in the first place. Toggling on/off may be dependent on users logging in so the server can generate keys.

Carazyda commented 2 years ago

Hello @nixjdm Sorry for the late response. Some information you can find in our helpcenter. Encryption on a per-user basis is quite a complex feature and takes a lot of time to develop. We may implement this in the future. Maybe you have some specific suggestions, please write them point by point.