Salty.im Blob Storage - HedgeDoc – Sanity check a design proposal I’m working with @email@example.com on? 🙏 Basic idea is to have a secure blob store that clients can store arbitrary files/objects to, like ratchet state that is private to the client, as well as a place to upload arbitrary files to for sharing with other users in chat.
@firstname.lastname@example.org the proposal does not include a threat model nor a discussion of how the proposed encryption protects against threats. What exactly is the purpose of encrypting the contents other than the fact that other software encrypts stuff? Why is a new blob request signed?
There is a statement
This implies that it is not possile for other clients and users to access another’s blob store as all requests are signed by the client’s private key, verified and used to construct the path(s) on disk.
Does it? Has that property been verified?
(that’s my 2 cents, if it helps at all)
@email@example.com I can’t write the whole thing; besides not being informed enough, I definitely don’t have the time. But here’s a start:
The notion is that you produce a list of threat actors (who you’re worried about misbehaving), affected data (what data these actors might have some affect on), and vulnerabilities (what could the threat actor do to the data that you don’t want them to do. Vulnerability can be driven by the “CIA” triad: confidentiality, integrity, and availability. With any data, you potentially want it to remain confidential (the C); you want the integrity to remain intact (the I; you don’t want it spoofed, or modified, or deleted by someone else without authorization); and you want that data to be available to whoever should have it when they should have it (the A). You need to put some thought into this and fill out these lists as fully as you can. Probably everyone who uses salty should help.
Then, a threat model is a table like the one I put below. The one line I entered should be read “it is possible that one salty user can learn the IP address of another salty user”. You may or may not care about that, so there is a priority column. Again, this table could be crowdsourced among salty users.Threat Actors
- other salty.im users
- salty.im server operators
- VPS operators
- network operators
- casual eavesdroppers
- law enforcement
- state actors
- login id
- login (IP) address
- login session times and durations
- chat session times, durations, participants
- contents of chats
- learn the data
- spoof the data
- delete the data
- prevent owner from reading the data
- prevent recipient from reading the data
- prevent owner from modifying/deleting the data
- prevent recipient from modifying/deleting the data
| Threat actor | Affected data | Vulnerability | Priority (1-3; 3 high) |
| other user | login (IP) | learn the value | 1 |
I know it seems tedious, but you really need to go through this exercise carefully and thoroughly if you care about security. You can’t just encrypt some stuff and hope for the best–that’s hacky, and will not really help with security. There could be gaping security holes you overlooked because you didn’t think it through even with encryption.
The good news is that once you’re done, it’s a great resource to always go back to. The priority column help you prioritize where to put development effort and what to do. It also helps you write documentation where you can tell users, with some confidence, what they can expect to stay safe and what they cannot expect to stay safe when they use salty.
@abucci Great introduction to threat models! I’d love to have seen that when we were about to create one ourselves at work. :-)
- Crowdsource it. Everyone who uses salty or might use salty who’d be willing to help can participate
- Reduce the lists. For example, It’s almost surely unrealistic to expect salty to be secure against state actors. But also that’s a design choice. It seems to me that, realistically, you’re unlikely to do what would be necessary to make salty secure against state actors, so why even try?
- Not all pieces of affected data can be affected by all the actors. Also, some of the combinations tend to be trivial. Finally, you can sometimes group threat actors together (“we don’t want anyone except the recipient of a message to be able to read the message” instead of 7 distinct lines, one for each threat actor) and possibly group affected data together sometimes too. It’s not usually an all vs. all matrix
- Focus on the high priority items first when constructing the matrix. Again that’s partly a design choice
- If you’re clever, you can semi-automate the process of converting the matrix into code! (that’s why I mentioned the casbin library–you can usually convert a threat model like this into
casbinauthorization policy files.
But, yeah, a thorough threat model will probably have a lot of rows–that’s kind of what it means to be serious about security instead of bolting it on. The matrix size is a feature. You only have to do it once, and then revise it through time, and you can probably reuse some of that work on other projects that have a security aspect.
@firstname.lastname@example.org I’m happy to help fill out any of these lists and the threat model matrix if you want. Nice thing about it is you can create a spreadsheet and invite whoever you want to fill it out and stop when you feel it’s been filled in enough. People can work on it asynchronously when they have the time.
Check out this site of ethical alternatives for more possibilities.