Recent twts in reply to #f4tp54q


  1. Crowdsource it. Everyone who uses salty or might use salty who’d be willing to help can participate
  2. 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?
  3. 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
  4. Focus on the high priority items first when constructing the matrix. Again that’s partly a design choice
  5. 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 casbin authorization 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.

⤋ Read More

@prologic 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.

⤋ Read More


Login or Register to join in on this yarn.