3 ms·

Ask HN: How do newly launched YC startups encrypt data in their db's?

1 points by santy-gegen 3y ago

Do recently launched startups of YC encrypt their data, say for example using Client Side Field Level Encryption in MongoDB (or similar)?

wmf 3y ago
Database encryption? YAGNI
- santy-gegen 3y ago
  why so? i agree that most users probably don't care but i personally care and that's why i'm interested
  - wmf 3y ago
    That's kind of the point of YAGNI. There are a lot of things developers care about that the product doesn't need. Would customers literally leave if you don't have encryption? No.
    - santy-gegen 3y ago
      that's a fair point and a useful heuristic
yuppie_scum 3y ago
The more you can encrypt up front, the less hassle from SOC et al next year. Minutes now will save days later.
- santy-gegen 3y ago
  It seems reasonable. That's why I'm trying to figure out how the best startups (YC ones are probably among the best) do their encryption and how they think about it. Tbh I couldn't find much info online so that's why I'm asking here
the_common_man 3y ago
It's dangerous to encrypt without a real need or understanding
- santy-gegen 3y ago
  interesting take, what i'm trying to learn is how do startups decide which fields of their db's to encrypt (maybe all of them?). Also, what do you think is the danger of encrypting stuff? It looks safer but I might be wrong (eager to learn more)
hodgesrm 3y ago
There are multiple levels of encryption. Server side encryption of cloud block storage and object storage are simple to enable or even defaults in public clouds. (Well for sure in AWS and GCP.) I would do these because they are simple. On the other hand if somebody gets access to a database account or gets root access to cloud VMs they can usually read your data anyway even if it's encrypted at rest. I would worry about that before implementing more complex client side encryption schemes. Besides the question of where you spend time it's possible to make a mistake and end up locked out of your data. If users explicitly ask for encryption that's a different matter. However, many enterprise users don't really care what you do as they avoid liability if you mess up. In this sense contractual terms like the scope of limitations of liability or indemnification are the user-visible product "features." You should at least think of them that way and price accordingly. You might encrypt in that case to make them cheaper to implement.
- santy-gegen 3y ago
  This is a very thoughtful and detailed take. Thank you. I was thinking of doing something like client side field level encryption because I personally think the product will be better that way. This type of encryption would protect against data theft even if someone got hold of db access, since they would only see encrypted strings and binary buffers. It's a good idea to point out to be careful, since getting locked out of your own data would certainly be annoying.

1 points by santy-gegen 3y ago

Do recently launched startups of YC encrypt their data, say for example using Client Side Field Level Encryption in MongoDB (or similar)?

wmf 3y ago

Database encryption? YAGNI

santy-gegen 3y ago
why so? i agree that most users probably don't care but i personally care and that's why i'm interested
- wmf 3y ago
  That's kind of the point of YAGNI. There are a lot of things developers care about that the product doesn't need. Would customers literally leave if you don't have encryption? No.
  - santy-gegen 3y ago
    that's a fair point and a useful heuristic

yuppie_scum 3y ago

The more you can encrypt up front, the less hassle from SOC et al next year. Minutes now will save days later.

santy-gegen 3y ago
It seems reasonable. That's why I'm trying to figure out how the best startups (YC ones are probably among the best) do their encryption and how they think about it. Tbh I couldn't find much info online so that's why I'm asking here

the_common_man 3y ago

It's dangerous to encrypt without a real need or understanding

santy-gegen 3y ago
interesting take, what i'm trying to learn is how do startups decide which fields of their db's to encrypt (maybe all of them?). Also, what do you think is the danger of encrypting stuff? It looks safer but I might be wrong (eager to learn more)

hodgesrm 3y ago

There are multiple levels of encryption. Server side encryption of cloud block storage and object storage are simple to enable or even defaults in public clouds. (Well for sure in AWS and GCP.) I would do these because they are simple. On the other hand if somebody gets access to a database account or gets root access to cloud VMs they can usually read your data anyway even if it's encrypted at rest. I would worry about that before implementing more complex client side encryption schemes. Besides the question of where you spend time it's possible to make a mistake and end up locked out of your data. If users explicitly ask for encryption that's a different matter. However, many enterprise users don't really care what you do as they avoid liability if you mess up. In this sense contractual terms like the scope of limitations of liability or indemnification are the user-visible product "features." You should at least think of them that way and price accordingly. You might encrypt in that case to make them cheaper to implement.

santy-gegen 3y ago
This is a very thoughtful and detailed take. Thank you. I was thinking of doing something like client side field level encryption because I personally think the product will be better that way. This type of encryption would protect against data theft even if someone got hold of db access, since they would only see encrypted strings and binary buffers. It's a good idea to point out to be careful, since getting locked out of your own data would certainly be annoying.