I've worked with systems like this in the past. It becomes a huge burden eventually when you have teams like marketing, analytics, etc that need access to the raw data and you eventually have to store all this stuff somewhere else unencrypted.

Have you thought about solving the problem from a different direction? Providing a read-only, sanitized clone of the database that can be accessed outside of the core application code?

Seems like that could kill more birds with the same stone?

So if the fields are encrypted by the proxy on the way to the DB, how do queries and indices work since it would be pretty much invisible to the DB and the query planner? Thanks!

I really like the approach you are taking since it could be a quick drop-in deployment that solves a huge problem for us.

How easy is it to rotate encryption keys in the event of a compromise? Eg a key was accidentally included in a log file, so the data encrypted by that key now needs to be re-encrypted with a new key.

How did you solve range queries? Prefix/suffix queries? Index performance? Aggregation on database end?

Idk as you loose the index and several operators your database might get useless and this solution would not scale well.

From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.

I liked very much the idea of dynamic masking. However, I wonder how good it works in practice. I was actually assessing one of your competitor (www.satoricyber.com) and found an easy to workaround the masking - I was able to essentially access any mask data using not-so-advanced SQL functions. Do you guys have a publicly available test suite against your proxy that people and security researcher can review? Also, do you have a bug bounty program and / or a clear disclosure policy when a vulnerability is found?

So I've seen something like this before i.e. https://github.com/cossacklabs/acra

So for me everything has to be infrastructures as code. I don't want to log into a UI and start configuring connections etc.

Also not keen on giving you production accesses to my databases, but maybe I misunderstood your implementation.

So I like the idea of a docker container that does this as a proxy.

It's a tough market you're going into, $395 per database is a big ask.

FYI, I think there may be a typo on your `https://jumpwire.ai/pricing` page on the `How are keys handled?`

``` How are keys handled? We generate unqique encryption keys for every account and store them in a secure secrets manager. Subkeys are routinely created and rotated from the master key. For additional security, we support user provided keys on our Team and Enterprise plan. ```

`unqique` --> `unique`

Cool product. Just curious, is there no existing encryption at the DB level? I would expect modern DBs to be able to do that.

Nice! I've been using a plugin [1] for Prisma that does something similar, but this sounds much more comprehensive.

[1] https://github.com/47ng/prisma-field-encryption

Do you guys post any details about the storage format?

Like if I had the encryption key and any salt etc, can I decrypt it without your product?

Also how much has the encrypted format been vetted?

I saw your example and the last name seemed to be massive even compared to using something like KMS.

Congrats on the launch! Interesting product.

How are updates handled, if I’m hosting the container in my cloud? How should I plan for troubleshooting if there are incidents involving JumpWire?

Congrats on the launch! This sounds pretty cool.

Did you have to get into the weeds of the wire protocols that Postgres/Mysql use? What was that like?

What's the risk to your business of other data security companies (like BigID) offering this kind of functionality?

Any comparisons to https://www.tonic.ai?

> Based on policies you define, individual fields can be encrypted/decrypted... Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything? Or is it more granular even within the main app? Like can I teach JumpWire about my app's users and our AuthZ ruleset?

> or they partition the data by putting some fields in a data vault and others in the main database I was considering using VGS to tokenize sensitive data, but I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?

> We’ve seen entire teams dedicated to just maintaining ETL pipelines for scrubbing PII into secondary databases!

I do this to make staging environments more realistic, which makes them double as debugging tools on production when you can't give engineers any sort of direct production access. We whitelist non-sensitive fields (most importantly foreign keys), and fill in the rest with faked data. The app looks like production, but if all the users were bots who were saying nonsense at each other. At my scale (50 person company), it works reasonably well enough with just me maintaining it.

Dang this sounds awesome, really dig that clients won’t require changes to play nice

This sounds great, but I’d really prefer a fully-hosted solution. Do you offer one?

Any plans to support mongodb?

Amazing work guys! Excited to integrate this to shore up our security practices

Looks great. How do you guys compare to something like Voltage?

amazing! we've been looking for smth like this! just registered via website

Great work guys! Looking forward to integrating with JumpWire!

I suppose your company in theory could read all the incoming data? Could engineers at my company decrypt the data? Or are the keys not available to us?

I suppose its more about ensuring the data sitting around in the DB isn't exposed to random employees or hackers yeah?

What I'd like to have is an app that allows me to easily select specific vocab that I want to learn (with flashcards).

Essentially, I would pick "cooking" and get a list of vocabulary, sorted by usage/importance that contains all the words that I need for "cooking" such as tools, ingredients, techniques and so on.

Or the same for traveling, hiking, cycling, ordering in a restaurant, buying a house, ...

That would be super useful.