18

The company I'm working in wants to develop a CRM that is cloud-based and we will need to store the data safely.

I've been searching for a way to create a strategy to save and secure data but I don't seem to find the answers I'm looking for.

We don't want to have access to sensitive data, so that data should be encrypted.

We looked at some solutions like MSSQL Always Encrypted or Mysql TDE but our host provider (DigitalOcean) doesn't support MySQL TDE and doesn't offer MSSQL, so we would either need to change the host provider or host the CRM ourselves.

My Manager also wants us to do client-side encryption as it would be the most secure way to encrypt the data without us having access to it. He wants us to do something similar to Passbolt, but there are some issues, I think.

The first issue is that Passbolt only encrypts the passwords that are normally no bigger than 20-50 chars using OpenPGP. A CRM would contain data that is much bigger than that, so this would be a problem, no?

The second issue is if we do client-side encryption, we would need to store the users' private keys in the browser with WebSQL and I'm not quite sure how secure this would be.

The third issue is that our application would have claim-based access, meaning some users would have access to the planner, for example, others would have access to invoices, etc... So before the encryption, we would need to ask the server for all the public keys of the users who have access to the "section" where we want to encrypt the data. More importantly, if we add or change the access of a particular user, then we would need to decrypt all the data he had/will have access to and encrypt it again to all the users.

Keep in mind we are open to change our Host provider (Change to Azure, AWS, Google, etc..).

schroeder
  • 123,438
  • 55
  • 284
  • 319
Wilson Silva
  • 291
  • 2
  • 5
  • 7
    What you are describing is known as a `zero access` system, where the provider of the service has 'zero access' to the client's information. The client's information is encrypted at the client side, so that the provider only sees the encrypted ciphertext. See www.protonmail.com for a good example of such a system. – mti2935 Sep 20 '21 at 19:23
  • WRT where and how to store private keys on the client side: see https://security.stackexchange.com/questions/231818/how-to-secure-a-web-only-end-to-end-encrypted-chat-with-message-persistence – mti2935 Sep 20 '21 at 23:40
  • 9
    One really important aspect here is to make sure you and your bosses understand the very significant limitations that this requirement will put on your application. If the server can't access the information because it is encrypted, the server can't do *any* kind of filtering/search based on that data. You have to pretty much design your entire application around that restriction. – Mad Scientist Sep 21 '21 at 13:03
  • 3
    Also note that there's a fundamental limitation with browser based zero access systems — they aren't. Or rather, they're only "zero access" as long as the server serving the JS code isn't compromised, since the server chooses what code the client will run. Combine that with the considerable limitations a zero access architecture puts on you, as noted by @MadScientist, and it's worth thinking carefully about whether such a design really offers a worthwhile security benefit. – Ilmari Karonen Sep 21 '21 at 20:18
  • 1
    (Of course, the same issue also applies to any app with an automatic update mechanism, but in that case at least the updates often have to go through a *supposedly* trusted third party, and there may be an unskippable notification to the user. It's not much, and bugs and malware can certainly sneak in through such updates, but at least it's slightly better than a web app that, in effect, silently updates itself through a direct private channel every time you open it.) – Ilmari Karonen Sep 21 '21 at 20:20
  • @Ilmari Karonen The server doesn't necessarily have to have control over what javascript the client runs - you could have all the clientside code in a browser plugin instead. – kloddant Sep 21 '21 at 20:38
  • @kloddant: Yes, a browser addon or PWA with all code cached in the PWA serviceworker and designed not to update itself or allow updates would also work. – R.. GitHub STOP HELPING ICE Sep 21 '21 at 22:11
  • @kloddant: Good point. Of course the server can still send *additional* JS code along with the page that the browser will execute by default. Preventing it from doing that might be tricky (though possible at least in some browsers; see e.g. the NoScript add-on for Firefox), but at least there's some sandboxing so that the plugin may be able to keep any secret keys hidden from in-page scripts. Of course the plugin would also have to ensure that any in-page scripts can't e.g. log the user's keystrokes or capture screenshots of sensitive content. – Ilmari Karonen Sep 22 '21 at 11:10
  • 1
    @IlmariKaronen wrt, `Also note that there's a fundamental limitation with browser based zero access systems ... since the server chooses what code the client will run.` - this is sometimes referred to as the 'browser crypto chicken and egg problem'. In other words - if you can't trust the server with your secrets, then how can you trust the server to serve secure crypto code? See https://security.stackexchange.com/questions/238441/solution-to-the-browser-crypto-chicken-and-egg-problem for some interesting ideas around solutions to this problem. – mti2935 Sep 25 '21 at 17:13

1 Answers1

68

Your company should hire a security expert to help with the project, and start fresh.

I know that not answering your immediate technical questions might seem frustrating, but I can promise you that no amount of technical detail that can be reasonably provided in a StackExchange answer is going to significantly benefit you, or your organisation, given the current trajectory of this project.

The project design process so far appears to be:

  1. Your organisation has identified a business requirement that is not currently met by existing capabilities, and you have decided to build a cloud-based CRM to fulfil that requirement.
  2. Your manager has decided that client-side encryption is a requirement, and delegated the responsibility for designing this to you (someone who is not a security specialist).
  3. You have investigated a number of technologies to implement the client-side encryption with.

While it's good that security is a priority, the organisation's current approach to the project has a number of issues.

First, and most critically, everyone is moving too far ahead, too quickly. You're already looking at software stacks to support the implementation details, but the security of a system like this is grounded in the architecture and design, not which database or web storage solution you use. A lack of planning in this area will almost always land you in a situation where the system cannot achieve its business goals and security requirements, and attempts to patch up the gaps will leave you with a ton of technical debt.

A custom cloud-based CRM has been chosen as a solution to a business problem. However, it isn't clear that sufficient security analysis went into this decision. Instead of "we need X => we can do that with Y => that could be secured with Z => how do we do Z?", your company should be asking "how do we achieve X in a secure manner?". It doesn't seem like there's a threat model, nor does it seem like any of the security decisions are being driven by that threat model.

You've realised that the task your boss has asked of you is beyond your current area of expertise, and you're looking for help. That's a good thing - you've identified a knowledge gap and you're looking to fill it. Unfortunately, when it comes to projects like this, getting help with individual technical details isn't going to be enough. These systems have a lot of hidden subtleties and pitfalls, and navigating those is as much about experience as it is deep technical knowledge. This type of project security support is a completely different job to developing software.

I'm also worried that your organisation has committed to this approach without first performing a feasibility study to identify whether you have the prerequisite knowledge and experience in-house. Building a secure multi-party document exchange solution around an untrusted server model is a complicated undertaking that requires deep knowledge of security and cryptography. Interactive features like planners and calendars are even more complicated. The smallest detail can hide a footgun that breaks the entire security model, sometimes in ways that can't be resolved without completely re-designing the system (which is obviously not feasible). I've worked on designs for these types of systems, and I've assessed many more, and I'd consider them to be one of the hardest types of system to get right.

To be clear: these criticisms are not intended to be negative or accusatory. I've worked with hundreds of organisations over my career, on thousands of projects, and it's far from uncommon to see this type of approach to a project. When you don't have someone to steer you in the right direction, all you can do is forge ahead, muddle your way through, and try to get things done. There's no shame in that. But the one constant throughout all of those engagements is that companies who get security experts to help guide them at the earliest possible stages - when they're just deciding that they might need to build a system - are the ones who don't end up with a pentest report full of critical severity issues at the end, and don't end up spending thousands on re-tests and additional security controls for a system that only half does what they wanted it to. From a purely fiscal perspective: spending money on security consultation at the start of a project saves you far more money in ongoing costs later.

I'm sympathetic to the position you're in. I've been a developer, and I certainly didn't get to make the big project decisions. If you take this answer to your boss and the project lead/stakeholders (hi!), I hope it steers them in the right direction and saves both you and the company some headaches along the way.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 4
    +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. – CBHacking Sep 20 '21 at 21:21
  • @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. – Polynomial Sep 20 '21 at 21:31
  • 3
    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. – CBHacking Sep 20 '21 at 21:54
  • 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. – Stilez Sep 21 '21 at 02:25
  • 2
    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. – throx Sep 21 '21 at 05:58
  • 1
    @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. – Polynomial Sep 23 '21 at 11:53