Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB Releases Queryable Encryption Preview

mongodb.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: MongoDB Releases Queryable Encryption Preview

#31

Post by SkyPuncher »

snorkel wrote: post #27
SkyPuncher wrote: post #10

This is a really neat technology, but I don't understand it's use case. I've worked in HealthTech and currently in the compliance space. I'm skeptical of Mongo's claims (and their familiarity with compliance laws). Kind of feels like a solution in search of a problem. "In use" implies that you have a need to process that data. It doesn't matter if the end client is submitting queries in plain text (protected in trans…

This seems more applicable for the SaaS hosting model where the database service is managed by a 3rd party. So the use case is "I trust your SaaS service is compliant with my legal obligations to protect my customer data, but it'd be easier for everyone involved if your database service also has no way of seeing sensitive data fields. That would make it easier for me to pass my compliance audits, otherwise I need to…

The problem is that situation doesn't really exist.

At an organizational level, it's extremely hard to control what information get put into a SaaS. There are far too many ways in which data can be de-anonymized or inferred against (e.g. a field existing can have privacy implications).

It's far safer to use a SaaS provider that meets general control requirements than to try to shoe-horn encrypted data into them.

Re: MongoDB Releases Queryable Encryption Preview

#32

Post by ihucos »

GTP wrote: post #30

The problem is: is also the full query encrypted or just some values that are considered sensitive? I remember a research form some years ago showing that if an attacker is still able to see the SQL code can recover the content of the database by looking at the queries, the responses and "putting the pieces together". Now, if the target was to get the exact values inside the database (think about employees wages) it…

I like it. There is always a way to hack something. This is an additional layer of security that yes, can be also broken.

Re: MongoDB Releases Queryable Encryption Preview

#33

Post by mahmoudimus »

GTP wrote: post #30

The problem is: is also the full query encrypted or just some values that are considered sensitive? I remember a research form some years ago showing that if an attacker is still able to see the SQL code can recover the content of the database by looking at the queries, the responses and "putting the pieces together". Now, if the target was to get the exact values inside the database (think about employees wages) it…

You're on the right track. I work in the data security space and while this is a cool release, it's not novel[0] and has been around for a while[1]. As a general rule of thumb, the first thing to check is if the provider is asking you to pass in your query in plain text AND without a local client (very important, because if you're sending data in plaintext, the threat model is now transitioning to a honest-but-curious model).

This is obviously not that. They're encrypting locally. However, Simon Oya & Dr. Kerschbaum's paper, https://arxiv.org/abs/2010.03465, demonstrate a fantastic efficient attack to recover keywords on most constructions without a lot of queries. It is yet to be seen how effective MongoDB's implementation will be.

This is a very interesting space but structural encryption is the right way to put the theory into good use.

Most of the other encryption mechanisms such as homomorphic, partially homomorphic, etc. are just too impractical or require very specific niche use cases to be useful.

There are other misnamed technology I've seen in marketing such as "polymorphic encryption" or "vaultless" - but most of these haven't had real research or cryptanalysis behind it.

[0] https://info.ionic.com/hubfs/IonicDotCom/Resources/Assets/Se... [1] https://eprint.iacr.org/2017/111.pdf

Re: MongoDB Releases Queryable Encryption Preview

#34

Post by mjr00 »

SkyPuncher wrote: post #31
snorkel wrote: post #27

Earlier quoted context omitted.

This seems more applicable for the SaaS hosting model where the database service is managed by a 3rd party. So the use case is "I trust your SaaS service is compliant with my legal obligations to protect my customer data, but it'd be easier for everyone involved if your database service also has no way of seeing sensitive data fields. That would make it easier for me to pass my compliance audits, otherwise I need to…

The problem is that situation doesn't really exist. At an organizational level, it's extremely hard to control what information get put into a SaaS. There are far too many ways in which data can be de-anonymized or inferred against (e.g. a field existing can have privacy implications). It's far safer to use a SaaS provider that meets general control requirements than to try to shoe-horn encrypted data into them.

Not sure about any specific use cases for this Mongo feature, but security requirements are often just checkboxes without much thought put behind them, or not valid in certain contexts, like SaaS/cloud.

Classic example is on-prem enterprises requiring data encryption at rest when moving to a cloud vendor. I can explain to a client that encrypting an S3 bucket with an AWS-managed key doesn't really prevent anything beyond someone physically stealing a hard drive from the AWS data center, and that the cloud provider can still see all of their data because they control the encryption key... or I can just click the "encrypt data" flag on the S3 bucket, make their security and compliance officer happy, and be done with it.

So, you're totally right, but this might be a case they needed to satisfy where an enterprise security team or regulatory agency said that they couldn't put X data field in the cloud unless it was encrypted, but X data field was really important to the application team.

Re: MongoDB Releases Queryable Encryption Preview

#35

Post by throwaway2016a »

Help me understand this...

It says it will support prefix search, substring search, and the like. Can anyone point me in the right direction on what the algorithm may be here? I don't get how you could do those things without making the encryption less secure and/or decrypting every record the fly.

Another interesting use case I found that isn't mentioned here is sort. I've had customers ask me to be able to sort the results by PII and we tell them... no, we can't do that because the field is encrypted.

Re: MongoDB Releases Queryable Encryption Preview

#36

Post by hapiri »

throwaway2016a wrote: post #35

Help me understand this... It says it will support prefix search, substring search, and the like. Can anyone point me in the right direction on what the algorithm may be here? I don't get how you could do those things without making the encryption less secure and/or decrypting every record the fly. Another interesting use case I found that isn't mentioned here is sort. I've had customers ask me to be able to sort the…

It is less secure than your standard symmetric encryption. I guess they would use deterministic encryption in which 2 entries with same email address will have the same record string ( this leaks information to attacker ). Prefix search & sort can be achieved by using order preserving encryption. Not really sure about sub-string though.

Re: MongoDB Releases Queryable Encryption Preview

#37

Post by GTP »

mahmoudimus wrote: post #33
GTP wrote: post #30

The problem is: is also the full query encrypted or just some values that are considered sensitive? I remember a research form some years ago showing that if an attacker is still able to see the SQL code can recover the content of the database by looking at the queries, the responses and "putting the pieces together". Now, if the target was to get the exact values inside the database (think about employees wages) it…

You're on the right track. I work in the data security space and while this is a cool release, it's not novel[0] and has been around for a while[1]. As a general rule of thumb, the first thing to check is if the provider is asking you to pass in your query in plain text AND without a local client (very important, because if you're sending data in plaintext, the threat model is now transitioning to a honest-but-curiou…

Thank you for the information. Just one question: what do you mean by "without a local client"?

Re: MongoDB Releases Queryable Encryption Preview

#38

Post by mahmoudimus »

GTP wrote: post #37
mahmoudimus wrote: post #33

Earlier quoted context omitted.

You're on the right track. I work in the data security space and while this is a cool release, it's not novel[0] and has been around for a while[1]. As a general rule of thumb, the first thing to check is if the provider is asking you to pass in your query in plain text AND without a local client (very important, because if you're sending data in plaintext, the threat model is now transitioning to a honest-but-curiou…

Thank you for the information. Just one question: what do you mean by "without a local client"?

At a very high level, there has to be some sort of client-side encryption before transmitting the query to the server. That's usually the basic premise, client-side encrypts then transmits to the server which operates and returns a result that (in a simple 2 party system), the client (and only the client) will be able to decrypt. That is usually how these types of encryption protocols work.

That's what I mean by a "local client," there has to be something on the client side and it cannot just be something that communicates over the internet to a server w/o some sort of local encryption first.

Re: MongoDB Releases Queryable Encryption Preview

#39

Post by bradstewart »

mjr00 wrote: post #34
SkyPuncher wrote: post #31

Earlier quoted context omitted.

The problem is that situation doesn't really exist. At an organizational level, it's extremely hard to control what information get put into a SaaS. There are far too many ways in which data can be de-anonymized or inferred against (e.g. a field existing can have privacy implications). It's far safer to use a SaaS provider that meets general control requirements than to try to shoe-horn encrypted data into them.

Not sure about any specific use cases for this Mongo feature, but security requirements are often just checkboxes without much thought put behind them, or not valid in certain contexts, like SaaS/cloud. Classic example is on-prem enterprises requiring data encryption at rest when moving to a cloud vendor. I can explain to a client that encrypting an S3 bucket with an AWS-managed key doesn't really prevent anything be…

> that encrypting an S3 bucket with an AWS-managed key doesn't really prevent anything beyond someone physically stealing a hard drive from the AWS data center

It does, though. To get that data, you now need access to the bucket itself _and_ the KMS-managed encryption key. You might not be protecting the data from AWS, but one bucket misconfiguration doesn't lead to wholesale data loss now.

Is it perfect? No. You can misconfigure both. But misconfiguring KMS access is harder to do.

Re: MongoDB Releases Queryable Encryption Preview

#40

Post by throwaway2016a »

hapiri wrote: post #36
throwaway2016a wrote: post #35

Help me understand this... It says it will support prefix search, substring search, and the like. Can anyone point me in the right direction on what the algorithm may be here? I don't get how you could do those things without making the encryption less secure and/or decrypting every record the fly. Another interesting use case I found that isn't mentioned here is sort. I've had customers ask me to be able to sort the…

It is less secure than your standard symmetric encryption. I guess they would use deterministic encryption in which 2 entries with same email address will have the same record string ( this leaks information to attacker ). Prefix search & sort can be achieved by using order preserving encryption. Not really sure about sub-string though.

I've researched order preserving encryption before but the tradeoffs (mainly that the attacker can tell the order and use that to narrow the search space) always seemed like high risk.
Post reply on HN