Timeline for CRM with Client Side Encryption
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 23, 2021 at 11:53 | comment | added | Polynomial | @throx On that front, a good conversation to have internally is whether there's budget to embed a security consultant (or two) into the project team, on contract or as a temporary hire. Gaining an understanding of the requirements and risk appetite isn't too hard for contractors when they're sitting in on key meetings, but getting a broader familiarity with the business operations and pressures, budgetary constraints, stakeholder motivations, etc. is much easier when they're embedded with the team for a longer period. That increased level of understanding translates to tangible benefits. | |
| Sep 21, 2021 at 12:29 | vote | accept | Wilson Silva | ||
| Sep 21, 2021 at 5:58 | comment | added | throx | You also need to validate those requirements against the costs they will impose. Do you really need zero access? What are the risks you're actually mitigating with each requirement? Most of the statements appear to actually be system level rather than stakeholder. A good security expert will go through all of this with you and drill down to whether your statements are actually rooted in need, want or nothing in particular. | |
| Sep 21, 2021 at 2:25 | comment | added | Stilez | I add to this answer, one common statement: "Good security is hard". You need to get a lot of highly subtle stuff absolutely right, and not one medium to major thing wrong. You and your employer (from the question) just do not have the in-house competence to do it, and that's not an accusation, that is absolutely usual for companies without a dedicated security specialism. The money you/they put in will be wasted, and perhaps worse damage later, if you don't get that help. As this answer says, get a specialist expertise involved NOW to help you succeed. You wont succeed if you dont. | |
| Sep 20, 2021 at 21:54 | comment | added | CBHacking | Sounds like something fun, or at least complicated! E2EE/zero-access is actually one of my favorite design areas but it is hard to get right for any but the simplest systems. Add common requirements like being able to search, share, or back up the data; reset user passwords; access data across multiple devices; or handle various malicious use cases, and it gets way trickier (and compromises must be made). Not to mention the thing where any pure webapp will always be unable to provide reliable zero-access E2EE because the server can just inject arbitrary scripts into the client. | |
| Sep 20, 2021 at 21:31 | comment | added | Polynomial | @CBHacking I would tend to agree. I'm actually advising on a roughly similar project right now, and we're a few months into the design process. The other consultant working with me has a career twice as long a mine doing secure systems design work, and even then we're still going back and forth and finding potential issues and edge-cases in each others' designs and analyses. It's a hard design problem for sure. | |
| Sep 20, 2021 at 21:21 | comment | added | CBHacking | +1, I'd also add that there are many questions that the OP doesn't even know that they need to answer, and others where their beliefs are wrong. For example, it's quite possible to do client-side encryption without storing the key persistently in the client (or anywhere else), and also OpenPGP encryption works just fine on longer data blobs. There are simply too many misconceptions here to clean up. As somebody else who has designed a zero-access system, it takes weeks or months of refinement to hammer out the details even for the MVP, requires compromises, and wants an expert. | |
| Sep 20, 2021 at 16:57 | history | answered | Polynomial | CC BY-SA 4.0 |