-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> Is Vault something that can handle this without getting into my app code? Basically, if i gave a someone root access to my supabase instance is that encrypted data safe?
The answer is slightly offset from your question, so let me start by pointing out that the Vault is about Encrypted Data At Rest. This is mentioned in the docs and in the blog and video, but it's something that I like to always mention first in discussions. The main purpose of the Vault is to store your data encrypted, so that it's encrypted on disk, and in backups. In SQL the decrypted secrets are available to you, because that's where you are using them and encrypted data must be decrypted to be useful.
If someone roots access to your database, then yes they can access the decrypted secrets through the view. This is by design, the secrets must be decrypted to be useful in query code. This risk is similar to someone rooting your application code, they will see decrypted secrets via your environment key, so no it won't protect you against anyone rooting processes in your stack that need useful access to secrets and it's not meant to. Like all security you must take a layered approach, the Vault is just one storage level layer strategy.
One big difference from the env var approach though is that the key Supabase uses to encrypt your secrets with the Vault is stored outside the database, it is inaccessible to SQL, which is an enhancement over sticking the raw key into an environment variable or a table that is accessible to your application. Instead of revealing the raw key, pgsodium has a feature called [Server Key Management](https://github.com/michelp/pgsodium#server-key-management) where you do not have access to the raw key, but instead reference keys by an key identifier. It is safe to store this identifier alongside the data it encrypts. The raw key itself is never stored. I'm very intentionally overusing the word "store" here, because that's specifically the layer of security that the Vault provides.
yes - it's open source here: https://github.com/supabase/vault
This wraps pgsodium (https://github.com/michelp/pgsodium), which wraps libsodium (https://doc.libsodium.org/).
> I'm using Postgresql for a service and I'd love to use this feature. Maybe I should just use supabase as my backend...
We'll try to get the other big clouds to adopt some of these extensions we're developing (including pg_graphql). Vault is still in beta, but once it's stable I think it's a no-brainer for them. it can work with secure-enclaves, so it ties in nicely with their other offerings (read: more economically interesting for them)
You've hit the nail right on the head with this question on how hard group encryption is, and we don't have all the answers yet as we are still working the use cases around it. We are hoping to reach a level of security that you mention in your SE question using something similar to the excellent accepted answer, distributed private key sharing among trusted participants.
The basis we are exploring is using an algorithm called Signcryption (https://github.com/jedisct1/libsodium-signcryption) that is already included in pgsodium. This doesn't solve any of the shared private key issues you mention above, but it is a useful foundation for distributing encrypted messages that separate out sender and receiver identifiers from their keys, a sort of lower level foundation on top of which distributed key sharing can occur.
I also think signcryption is a great foundation for a better token format than JWT or PASETO, as it covers all of their use cases without algorithm confusion attacks (despite PASETO's insistence on "Algorithm Lucidity") and supports more features such as third party verification and streaming shared key generation from any token without having to exchange the key, we hope to use these tokens so that end-to-end peers can exchange tokens, derive streaming shared keys, and then do direct point-to-point message exchange using libsodium crypto_secretstream API which supports key ratcheting for forward secrecy.
Would love to discuss more about your research with you and include it with attribution into our future work, send me an intro at [email protected] when any other ideas or resources you'd like us to see!
I'm building the "in-use" part of this right now...what if you could encrypt your data with an encryption key (at-rest), _but also_ to a set of code that is allowed to decrypt it (in-use). If that code is identified cryptographically, its identity can't be spoofed or stolen.
We're exploring secure enclaves as the protected runtime env and the code attestation generation: https://github.com/edgebitio/enclaver
I think it’s great too. I wish they would shore up some of their existing releases though. Probably most notably, the ability to query aggregates via the officially supported route is missing: https://github.com/supabase/postgrest-js/issues/206
The workarounds suggested are not ergonomic for most use cases and it feels pretty out of place for such basic functionality to be missing in what otherwise feels like a pretty full featured product.
Their Realtime product is another example of something that languishes while new features get launched.