Encrypt the data on the server side

[almet]

The goal here would be that nobody operating the server would be able to see what's happening there.

Some information should/might still be visible for us, but I'm not even sure. By default everything should be encrypted, exept maybe contact email, and the last time the project was used, in order to be able to contact the users, and the do some cleaning at some point, for projects which are not used anymore.

In order to achieve this goal, we need a sort of key to encypt everything. A key that isn't known from the server operator.

The only thing we have right now is the projet "code" or "password". Due to the fact that people can currently access the project without knowing the password, it may not be practical to do this, I'm not sure.

Another thing that comes to mind is that the current password / code we use is not strong enough, so we might want to do some key streching, or we might want to enhance the strenght of the key, to start with.

Another thing that comes to mind is the fact that currently everybody connects as one entity, but we might want to do things differently.

In any case, I'm starting to see that this is the tip of the iceberg, and that changing the way we store and share all this data might also change a lot how the project is currently done, and the features it has.

Any ideas on what we could use to achieve this goal? I'm summoning a few folks who might have some valuable input : @Natim @warner @jvoisin ? If you have any pointers for us, they would be very useful. If this is bothering you, I'm feel sorry about it, let me know and I will try to to ping you in this way. I've done it because I've had interesting discussions with you in the past, and I feel that you might be able to help us in here.

Here are some projects and documentation related to this :

• https://signal.org/blog/secure-value-recovery/
• https://github.com/portier is the spiritual successor of mozilla personna. It was coming with keys that were not known from the server, but I'm not sure how practical this would be for shared projects like this one.

Thank you !

[jvoisin]

Since this is a web-application, there is no way to protect users from a malicious server.
What you could do, is to encrypt the data on the server, with a key provided by the user, but this would only protect the data from compelled decryption.

[almet]

Thanks for your input @jvoisin. It makes me think about different things 👍

First, it makes me realize that we actually need to define a (set of) threat model(s), and from there we might want to take design decisions ;

Secondly, and I realize you might already be aware of this, for this discussion I believe we need to make it clear that no measure will completely defeat an attacker, it will only make things harder to do, and that's (somehow) okay. No defense measure will be 100% secure, but we currently really lack a security model on this application. Anybody with administrative rights can access the data and browse it freely.

[almet]

As a long-term strategy, we should define a threat model for this application. I'm kind of aware of how that works, but I actually never did this kind of work. I wasn't sure if this discussion should happen in here or elsewhere, but here we go.

Here are a set of questions / items (taken from here) that I believe can help us define a threat model for this :

A description / design / model of what you’re worried about

Currently, the data is held on the server and server admins can browse trough it very easily, because it never was seen as a problem. Data that can be seen this way includes the name of the project, the emails and the bills themselves.

A list of assumptions that can be checked or challenged in the future as the threat landscape changes

• The software is made of a web application and an HTTP API ;
• There is no concept of users ;
• In order to access a project, one need to either enter project name + password or use an invite link ;
• The data is stored in plain text in the database ;

A potential threat to the system

If someone accesses the server, they can access all the data stored in there, for instance the email and code used together. This can happen if there is a security vulnerability, or if one of the server keyholders leaks them in some way;

A list of actions to be taken for each threat

We might want to encrypt the data on the server side, with a key not-know from the server operators, which would make it harder for somebody with access to the server to directly access the data.

[Glandos]

Anybody with administrative rights can access the data and browse it freely.

This can also be restricted. For example, the provided key can stored as a hash, but used for decryption. So, even a site administrator can't read project data.

[indatwood]

This discussion seems both interesting and complex :-)

If we want to keep the data away from the server owner, then it seems that there is no way to fix it for good : the admin can intercept all the data he/she want.

That being said, in security it seems that it's a matter of making things harder for the attackers. We could encrypt the data on the server side with a key known only to the connected users, this way it prevents the data from "cold" attacks.

Currently, the only thing that's known only to the users is the project code. I'm not sure it's complex enough to be useful, but that's a lead to follow. It also seems that there is an alternative login mechanism, using tokens. I've been looking at it, and it seems that it encodes directly the id of the project with a salt only known by the server, we could add another secret in there as well, which could be used to encryp the data if we wanted.

I'm actually not sure where to go from here, but it seems to be an ongoing discussion. Anybody with insights on this?

[almet]

Closing this, let's reopen if we really want it :-)

[rafutek]

Hello there :)

I was looking for a FOSS alternative to the Tricount app, and found Money Buster with ihatemoney. I works perfectlly, but the data is not encrypted... Is this going to be implemented ? It is the only thing that prevents me using ihatemoney.

Thank you

[Glandos]

Hi,
We don't have any plans to encrypt data stored on the server. It might be a blocker, but remember that you can quite easily host an instance by yourself, on a server that you control.

Implementing good encryption is hard. If the issue is protecting you from the server administrator, then the only solution is encrypting data within the client. This could be done, but only to some extents, e.g. we can't hide amounts or the server won't be able to compute a reconciliation.

Anyway, I still think that using MoneyBuster/IHateMoney is still better than Tricount from this point of view.