alt Hacker NewsSomething here seems to not fit together to me on the assumptions this is based on, because you say
> We're explicitly not claiming to defend against an attacker who fully owns your running application with valid credentials.
and dandraper says:
> I was CTO [...] and the engineers all had access to patient data. They needed DB access [...] but not access to the sensitive values > [...] > CipherStash solves the following: > * Hide sensitive data from direct database accessors
So putting these together is this implying that a developer who wants to test things on a large data set is given access to the database directly, but not access to debug the application? Surely for example if they could load the app in a debugger, step through it, and execute arbitrary code (eg. if they are developing on it) that includes "fully running the application"? So are you saying that scenario is not secure?
If so then I'm struggling to see how a developer would use this realistically. As a dev how am I supposed to work on an application without access to be able to change the code (assuming here then that "change the code" means I can also add a statement that dumps a decrypted value to the log)?
If the security level we want is something like "devs need to be able to test migrations work on the actual data" then why would I use this instead of just NOT giving direct db access and having an audited environment spin up a db copy and container and just output the logs of whether the migration worked, without access to query the db directly. If I do that then nobody needs direct db access right? But then why would I need CipherStash?
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?