[dandraper]

This doesn’t have anything to do with being able to change the code. Devs can code and change things as they need. The database is also the same as it always is.

What CipherStash does is let you specify specific columns that you want to encrypt. The application (via our SDK), encrypts values for that field before it’s saved and optionally decrypts it again when it’s read. Decryption is performed when the user provides a valid credential (JWT).

This would allow you to give your devs full access to the production DB. You don’t have to give them permission to decrypt any or specific fields if they don’t need it.

So for your use case that would possibly save a lot of effort - no need to create a santized copy of the database (which in itself is fraught).

What James was referring to was the attacker threat model. Decryption happens in the application code. So an attacker who can steal encryption keys as well as be a valid JWT would be able to decrypt data for as long as the JWT is valid. That scenario is not something CipherStash can fully prevent.

What it does prevent is unauthorised access to data. Whether via the database directly or via the application.

What’s important here is that it’s the data itself that protected. If you move encrypted values from your prod DB to test or dev, the same rules apply. A user who can’t read “email” values that were encrypted in prod would still not be able to read those values if you moved them somewhere else.

Does that clarify things?

[sigseg1v]

It's still not piecing together 100% for me, sorry I'm not trying to be obtuse or anything.

So maybe let me simplify my question: If I set up both a copy of a database with values encrypted by CipherStash, and an application server connected to it, and the application server has enough access to do queries on sensitive data (eg "WHERE sensitiveField = ?", pretend it needs that for a migration), and a developer has root access on the application box while it's running, and a gdb session connected to the app, can they see any sensitive data or no?

If they can't, then that's genuinely cool, and I probably need to look into the workings a bit more!

[dandraper]

Applications do not have access - individual authenticated users have access. A user must be authenticated & authorised in order to be able to create encrypted query terms. This is enforced by CipherStash's key server (ZeroKMS), not the application.

Having a copy of the production database and a local copy of the application and a debugger is insufficient to be able to encrypt/decrypt any values or run any queries involving encrypted search terms: you'd still need to authenticate with ZeroKMS.

Having root access to a production server running an application is a different matter because you'd have access to the entire address space of the app that real authenticated users are interacting with. A sufficiently motivated adversary would be able to intercept auth tokens allowing impersonation of an authorised user.

The application server process is a trust boundary in this model and thus requires appropriate access controls.

To address this last point, we now support decryption in edge workers like Cloudflare or Supabase Edge Functions. We also have browser-based encryption/decryption in the works. Both of these approaches mean data is never decrypted in the app, not even in production.

[catmanjan]

Your last point is very cool, this seems like a slept on technology